JP2016062174A - 情報処理装置、制御方法、およびプログラム - Google Patents

Abstract

【課題】ユーザの余暇時間を推定し、適切なタイミングでユーザへの情報提供を行うことが可能な情報処理装置、制御方法、およびプログラムを提供する。
【解決手段】インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、前記ユーザの余暇時間を推定する推定部と、前記推定した余暇時間に所定の通知を行うよう制御する通知制御部と、を備える、情報処理装置。
【選択図】図２

Description

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

昨今の通信技術の発達により、スマートフォン、タブレット端末等のモバイル端末が普及し、ユーザはどこにいてもいつでも情報を入手することができるようになった。しかし、インターネットの情報は膨大であり、情報検索にはそれなりの手間とコツが必要であった。そのため、ユーザによる能動的な情報取得には限界があると考えられ、今後は、ユーザの手間が必要ない、所謂受動的な情報提供が望まれる傾向にある。

適切な時間に、適切な場所で、適切なユーザに向けたサービスを提供する場合、ユーザを知ることが競争を行う業者にとって究極の課題であるが、例えば下記特許文献１では、ユーザの過去の行動に基づいてユーザの将来の行動を予測するユーザ行動予測方法が提案されている。これにより、サービス提供者は、予測されたユーザ行動に応じて適切なサービス提供（例えば双方向テレビジョンサービス）を行うことができる。

一方、近年、ＳＮＳ（ソーシャル・ネットワーク・サービス）の利用が急速に普及している。ＳＮＳは、一対一のコミュニケーションである通話やメールと異なり、一度に多くの特定・不特定のユーザに情報を発信することができるので、特定の誰かに伝えるほど重要ではない情報であっても手軽に発信され、電話やメールよりも利用頻度が高くなっている。また、ユーザは、通勤・通学時間や休憩時間、家に居る時等、暇な時間にＳＮＳへの書き込み等を行っていた。

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

ここで、スマートフォンやタブレット端末等のモバイル端末で受動的な情報提供を実施する際、通常、サービス提供者から情報提供があったタイミングでモバイル端末においてユーザへの通知が行われる。ユーザはモバイル端末をほぼ一日中持ち歩いているため、通知が来た際にすぐに情報を享受することができる。

しかしながら、ユーザが仕事中であったり、誰かと食事中であったり、家事をしていたりする場合等、他の作業で忙しい場合、モバイル端末で提供された情報をすぐに確認することができず、十分に情報提供を行うことができなかった。また、かかる通知により他の作業が中断されてしまい、却って通知が煩わしいこともあった。

そこで、本開示では、ユーザの余暇時間を推定し、適切なタイミングでユーザへの情報提供を行うことが可能な情報処理装置、制御方法、およびプログラムを提案する。

本開示によれば、インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、前記ユーザの余暇時間を推定する推定部と、前記推定した余暇時間に所定の通知を行うよう制御する通知制御部と、を備える情報処理装置を提案する。

本開示によれば、インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、前記ユーザの余暇時間を推定することと、前記推定した余暇時間に所定の通知を行うよう制御することと、を含む制御方法を提案する。

本開示によれば、コンピュータを、インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、前記ユーザの余暇時間を推定する推定部と、前記推定した余暇時間に所定の通知を行うよう制御する通知制御部と、として機能させるための、プログラムを提案する。

以上説明したように本開示によれば、ユーザの余暇時間を推定し、適切なタイミングでユーザへの情報提供を行うことが可能となる。

なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

本開示の一実施形態による情報処理システムの概要を説明する図である。 本実施形態による情報処理システムによるユーザへの通知制御を説明する図である。 本実施形態によるサーバ（情報処理装置）の構成の一例を示すブロック図である。 本実施形態による余暇時間の推定について説明する図である。 クライアントの表示画面における所定の通知領域の一例を説明する図である。 本実施形態による余暇時間中の通知に対するユーザ操作のフィードバックについて説明する図である。 本実施形態による余暇時間の推定処理を示すフローチャートである。 本実施形態による余暇時間に応じた通知制御処理を示すフローチャートである。 本実施形態によるフレンド申請の通知および確認画面の一例を示す図である。 本実施形態による予定の確認の通知および確認画面の一例を示す図である。 本実施形態によるアンケートの通知および確認画面の一例を示す図である。 本実施形態による広告の通知および確認画面の一例を示す図である。 本実施形態による複数の通知の表示例を示す図である。 本実施形態によるＴＯＤＯリストの通知制御処理を示すフローチャートである。 ＴＯＤＯリストの登録について説明する図である。 本実施形態によるＴＯＤＯリストの通知および確認画面の一例を示す図である。 本実施形態による状態情報提示処理を示すフローチャートである。 本実施形態による状態情報の表示例を示す図である。 本実施形態による状態情報の他の表示例を示す図である。 本実施形態による状態情報の他の表示例を示す図である。 本実施形態による状態情報提示処理を示すフローチャートである。 本実施形態による状態情報の表示例を示す図である。

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

また、説明は以下の順序で行うものとする。
１．本開示の一実施形態による情報処理システムの概要
２．基本構成
３．動作処理
３−１．余暇時間の推定処理
３−２．余暇時間に応じた通知制御処理
３−３．余暇時間に基づく状態提示処理
４．まとめ

＜＜１．本開示の一実施形態による情報処理システムの概要＞＞
まず、本開示の一実施形態による情報処理システムの概要を図１に示して説明する。図１に示すように、本実施形態による情報処理システムは、ユーザＡが所持するユーザ端末であるクライアント２Ａと、ユーザＡの余暇時間を推定する情報処理装置であるサーバ１とを含む。図１では、一例としてユーザＡが所持するクライアント２Ａとサーバ１が接続するシステムを示したが、本開示による情報処理システムはこれに限定されず、サーバ１は、複数のクライアント（不図示）と接続し得る。

クライアント２Ａとしては、例えばスマートフォンが用いられる。ユーザＡは、クライアント２Ａでインターネットに接続し、ソーシャルメディア３への書き込みやメールの送信を行うことができる。ソーシャルメディア３は、例えば短文投稿サイトや、記事投稿サイト、ソーシャルニュースサイト、ソーシャルゲーム等であって、各サイトにおいて登録された他ユーザと交流を図ることが可能である。ユーザＡは、空いている時間にソーシャルメディア３やメールへの書き込みを行う。

サーバ１は、ユーザによるソーシャルメディア３やメールへの書き込みログ（履歴）を取得し、書き込んでいる時間は暇な時間（仕事や家事、学校等、他の作業を優先する時間ではない）とみなして、ユーザの余暇時間を推定する。より具体的には、サーバ１は、所定期間、例えば１週間の書き込みサイクルを抽出することで、例えば平日の１２時半から１３時と１９時〜２１時、および休日の１０時から１２時と１６時から１８時は余暇時間である、と推定することができる。

ユーザによるソーシャルメディア３やメールへの書き込みログは、図１に示すように、クライアント２Ａからプロトコル監視によってログ化されたものが送信されるようにしてもよいし、サーバ１がソーシャルメディア３に書き込み情報を問い合わせて取得してもよい。

このようにして、本実施形態による情報処理システムは、ソーシャルメディア３やメールへの書き込み情報に基づいて、ユーザの余暇時間を推定することができる。そして、サーバ１は、推定した余暇時間を考慮して適切なタイミングでユーザへの通知を行うことができる。以下、図２を参照して余暇時間に応じた通知制御について説明する。

図２は、本実施形態による情報処理システムによるユーザへの通知制御を説明する図である。図２に示すように、例えばユーザＢが所持する情報処理装置であるクライアント２Ｂがサーバ１と接続し、ユーザＢからユーザＡに対するタスクリクエスト（要返信メッセージなど）が、サーバ１を介してクライアント２Ｂからクライアント２Ａに送られる場合、サーバ１は、クライアント２Ｂから送信されたタスクリクエストのクライアント２Ａへの通知タイミングを制御する。

具体的には、サーバ１は、クライアント２Ｂからタスクリクエストを受信した時点でユーザＡが余暇時間中であればクライアント２Ａに通知し、ユーザＡが余暇時間外であれば当該タスクリクエストを蓄積してユーザＡの余暇時間が到来した際に通知するよう制御する。

余暇時間に通知されることで、ユーザＡは他の優先すべき作業が中断されるといったことが無くなり、また、即座に情報内容を確認することができるので、ユーザへの十分な情報提供を実現することができる。

また、サーバ１は、ユーザＡが余暇時間中か否かといった状態情報をユーザＢに提示してもよい。この場合、ユーザＢは、ユーザＡがタスクリクエストをすぐに確認できる状況にあるのか否かを、タスクリクエストを送信する前に把握することができる。

以上、本開示の一実施形態による情報処理システムの概要について説明した。なお、図１、図２に示す例では、余暇時間の推定を行うことと余暇時間を考慮した通知制御を行うことがいずれもサーバ１で行われているが、本実施形態はこれに限定されず、余暇時間の推定と余暇時間を考慮した通知制御が別々の情報処理装置で行われてもよい。また、クライアント２は、図１、図２に示すようなスマートフォンに限定されず、タブレット端末、携帯電話端末、ＰＤＡ（Personal Digital Assistant）、ＰＣ（Personal Computer）、携帯用音楽プレーヤー、携帯用ゲーム機、またはウェアラブル端末（ＨＭＤ（ヘッドマウントディスプレイ）、メガネ型ＨＭＤ、時計型端末、バンド型端末等）であってもよい。続いて、本実施形態の情報処理システムに含まれるサーバ１の基本構成について説明する。

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

（制御部１０）
制御部１０は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、不揮発性メモリ、インターフェース部を備えたマイクロコンピュータにより構成され、サーバ１の各構成を制御する。具体的には、本実施形態による制御部１０は、図３に示すように、推定部１０ａ、通知制御部１０ｂ、状態提示部１０ｃ、およびフィードバック部１０ｄとして機能する。

・推定部
推定部１０ａは、インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、ユーザの余暇時間を推定する。より具体的には、推定部１０ａは、例えば１週間のソーシャルメディア３または電子メールへの書き込み操作履歴に基づいて、１週間の入力サイクルを抽出し、当該書き込み操作が行われている時間帯を余暇時間と推定する。書き込み操作履歴は、クライアント２またはソーシャルメディア３から取得され、操作履歴ＤＢ１２ａに格納されている。本実施形態による余暇時間の推定について、以下、図４を参照して説明する。

図４は、本実施形態による余暇時間の推定について説明する図である。図４に示すように、推定部１０ａは、ユーザの月曜日の操作履歴１００ｍ・・・水曜日の操作履歴１００ｗ・・・というように１週間の操作履歴１００を参照し、情報入力操作が行われている操作時間帯Ｏ１、Ｏ２、・・・Ｏ４、Ｏ５を抽出する。図４上に示す操作履歴１００ｍでは、９時前後にソーシャルメディアａへの書き込みが行われ（操作時間帯Ｏ１）、１４時〜１５時にソーシャルメディアｂへの書き込みが行われている（操作時間帯Ｏ２）。推定部１０ａは、ソーシャルメディアの種類に関わらず、全てのソーシャルメディアを対象として書き込み操作の時間帯を抽出する。また、推定部１０ａは、他の曜日の操作履歴１００に対しても同様にソーシャルメディアへの書き込み時間帯を抽出する。

そして、推定部１０ａは、図４下に示すように、ユーザの１週間の余暇時間データ１１０を推定する。図４に示すように、本実施形態では、ソーシャルメディア等への書き込み操作時間帯Ｏ１〜Ｏ５が、余暇時間Ｔ１〜Ｔ５とみなされている。このような推定の根拠は、通常、ユーザが所持する個人のクライアント２を用いたソーシャルメディア３への書き込みやメールの作成・送信が、ユーザが他に優先すべき作業のない暇な時間に行われるものであると想定されるためである。

推定部１０ａにより推定された余暇時間データは、余暇時間ＤＢ１２ｂに格納される。

なお、図４を参照して説明した例では、ソーシャルメディア等への書き込み時間のみを要素として余暇時間を推定しているが、本実施形態による余暇時間の推定はこれに限定されない。例えば、推定部１０ａは、ソーシャルメディア等への書き込み時間のサイクルを抽出した後、さらに当該書き込み時間におけるクライアント２の位置情報（緯度・経度）、近くにいる他ユーザ、および該当時間のスケジュール登録の少なくともいずれかを関連付けて余暇時間のモデルを生成してもよい。これにより、推定部１０ａは、余暇時間の推定を行う際、時間の他、ユーザが居る場所、一緒に居た人、または登録されている予定を、ユーザが余暇状態であるか否かの要素として用いることができる。

また、推定部１０ａは、書き込み内容の解析結果に基づいて余暇時間を推定してもよい。より具体的には、推定部１０ａは、ソーシャルメディア３等への書き込み内容をテキスト解析し、仕事の一環として行われていると判断できた場合は余暇時間から除外する。または、推定部１０ａは、メールの宛先から仕事中であるか否かを判断してもよい。

・通知制御部
通知制御部１０ｂは、推定部１０ａにより推定されたユーザの余暇時間にユーザへの所定の通知を行うよう制御する。より具体的には、例えば他ユーザからの要返信メッセージ、広告、アンケート、ユーザが自身で登録したＴＯＤＯリストなどのタスクリクエストの通知が行われる。通知制御部１０ｂは、ユーザの余暇時間外に他ユーザから要返信メッセージや広告情報を受信した場合はこれを一時的に蓄積し、ユーザの余暇時間が到来した際にまとめて通知を行う。このように、ユーザの余暇時間に通知（情報提供）が行われるため、ユーザは通知に応じてすぐに情報を享受することができる。

また、通知制御部１０ｂは、クライアント２の表示画面の端部に設定された所定の通知領域に通知表示を行うよう制御する。ここで、図５を参照して本実施形態によるクライアント２における通知領域の一例について説明する。図５左に示すように、例えばスマートフォンにより実現されるクライアント２Ａ−１の表示部２２Ａ−１において、画面全体がアプリケーションの実行領域として用いられている際に、表示部２２Ａ−１の上端部を通知領域Ｓ１として設定し、通知があった場合に通知領域Ｓ１に表示されるようにしてもよい。また、図５右に示すように、例えばタブレット端末により実現されるクライアント２Ａ−２の表示部２２Ａ−２において、画面全体がアプリケーションの実行領域として用いられている際に、表示部２２Ａ−２の上端部を通知領域Ｓ２として設定し、通知があった場合に通知領域Ｓ２に表示されるようにしてもよい。

そして、通知領域に表示された通知をユーザが選択すると（例えば通知領域をタップする等）、クライアント２の表示部２２において、通知内容と当該通知への対応可否を選択する表示を含む確認画面が表示される。このようなクライアント２における通知表示例および確認画面表示例については、図８〜図１５を参照して後述する。

・状態提示部
状態提示部１０ｃは、余暇時間ＤＢ１２ｂを参照して、対象ユーザが現在余暇時間中か否かを示す状態情報を、要求元ユーザに提示する。例えばユーザＢのクライアント２Ｂにおいて、ソーシャルメディアのアプリケーションが立ち上げられ、メンバーへの要返信メッセージを送る画面や、新規メンバーの登録画面が表示される際、クライアント２Ｂは、対象ユーザの状態情報をサーバ１に問い合わせる。これに対し、サーバ１の状態提示部１０ｃは、クライアント２Ｂからの問い合わせに応じて、対象ユーザが現在余暇時間中か否かを示す状態情報をクライアント２Ｂに返信する。クライアント２Ｂでは、サーバ１から受信した状態情報として対象ユーザが現在余暇時間中か否かが示されるので、ユーザＢは、対象ユーザへの要返信メッセージを送信した場合に対象ユーザがすぐに確認できる状態か否かを把握することができる。このようなクライアント２における対象ユーザの状態情報表示画面例については、図１７〜図１９、図２１を参照して後述する。

・フィードバック部
フィードバック部１０ｄは、ユーザへの余暇時間中の通知に対するユーザ操作（フィードバック）を取得し、余暇時間ＤＢ１２ｂに格納されているユーザの余暇時間データに反映させる。すなわち、本実施形態ではソーシャルメディア等への書き込み時間を余暇時間と推定しているが、例外的にソーシャルメディア等への書き込みが仕事の一環として行われていたり、ソーシャルメディア等への書き込みの方が通知内容の確認よりも優先度が高かったりする場合がある。そこで、本実施形態では、ユーザ毎またはユーザ属性毎（年齢（年代）、性別、職種等）に、余暇時間中の通知に対するユーザ操作（後述するポジティブ／ネガティブフィードバック）に応じて余暇時間データの調整を行うようにしてもよい。以下、図６を参照して具体的に説明する。

図６は、本実施形態による余暇時間中の通知に対するユーザ操作のフィードバックについて説明する図である。図６に示すように、例えばソーシャルメディアへの書き込みやメール送信といったインターネットへの情報入力操作に基づいて、月曜日における余暇時間Ｔ１０、Ｔ１１、Ｔ１２、Ｔ１３が推定部１０ａにより推定される。

その後、通知制御部１０ｂは、推定部１０ａにより推定された余暇時間帯に、要返信メッセージ、アンケート、広告、またはＴＯＤＯリストといったタスクリクエストの通知を行う。フィードバック部１０ｄは、かかる通知に対してユーザにより実質的な対応が行われた場合はポジティブフィードバックと判断し、実質的な対応が行われなかった場合はネガティブフィードバックと判断する。これにより、どの余暇時間帯でどのような通知が受け入れやすいかが学習されるので、通知制御部１０ｂは、ユーザ操作がフィードバックされた余暇時間データに基づいて、受け入れやすい余暇時間帯に所定の通知を行うよう制御することができる。

図６に示す例では、例えば「要返信メッセージ」の通知に対するユーザのポジティブ／ネガティブバックを参照すると、余暇時間Ｔ１０、Ｔ１１、Ｔ１３では当該通知を受け入れやすく、余暇時間Ｔ１２では受け入れ難いことが示されている。また、「アンケート／広告」の通知に対するユーザのポジティブ／ネガティブバックを参照すると、余暇時間Ｔ１０、Ｔ１１、Ｔ１２では当該通知を受け入れ難く、余暇時間Ｔ１３では受け入れ易いことが示されている。また、「ＴＯＤＯリスト」の通知に対するユーザのポジティブ／ネガティブバックを参照すると、余暇時間Ｔ１０、Ｔ１１、Ｔ１２では当該通知を受け入れ難く、余暇時間Ｔ１３では受け入れ易いことが示されている。

この場合、通知制御部１０ｂは、余暇時間Ｔ１０、Ｔ１１では「要返信メッセージ」を優先して通知し、余暇時間Ｔ１２ではいずれの通知も行わない。また、余暇時間Ｔ１３では、「要返信メッセージ」の通知も受け入れ易いが、当該通知は他の余暇時間（余暇時間Ｔ１０、Ｔ１１）でも受け入れ易いため、余暇時間Ｔ１３では「アンケート／広告」および「ＴＯＤＯリスト」を優先して通知する。

また、状態提示部１０ｃは、図６に示すフィードバックに基づいて、「要返信メッセージ」を送信しようとしているユーザに対しては対象ユーザの余暇時間Ｔ１０、Ｔ１１に送信することを薦め、「アンケート／広告」を送信しようとしている事業者に対しては対象ユーザ（または対象ユーザ属性）の余暇時間Ｔ１３に送信することを薦めることもできる。

（通信部１１）
通信部１１は、無線／有線により外部装置と接続し、データの送受信を行う機能を有する。本実施形態による通信部１１は、例えばクライアント２と接続し、通知制御部１０ｂの制御によりユーザの余暇時間中にタスクリクエストを送信したり、状態提示部１０ｃの制御により対象ユーザの状態情報を要求元ユーザに送信したりする。

（記憶部１２）
記憶部１２は、様々なデータを記憶し、例えば制御部１０の各処理を実行するためのプログラムを記憶する。また、本実施形態による記憶部１２は、操作履歴ＤＢ（データベース）１２ａおよび余暇時間ＤＢ１２ｂを有する。

操作履歴ＤＢ１２ａは、ユーザによるソーシャルメディアへの書き込みやメールの作成・送信操作等の操作ログを格納する。また、操作履歴ＤＢ１２ａに格納された操作ログは、推定部１０ａが余暇時間の推定を行う際に用いられる。余暇時間ＤＢ１２ｂは、推定部１０ａにより推定された余暇時間データを格納する。また、余暇時間ＤＢ１２ｂに格納された余暇時間データは、通知制御部１０ｂがタスクリクエストを通知する際や、状態提示部１０ｃが対象ユーザの状態情報を提示する際に用いられる。

以上、本実施形態によるサーバ１の具体的な構成について説明した。なお図３に示すサーバ１の構成は全て必須ではなく、例えばフィードバック部１０ｄを有しない構成であってもよい。また、図３に示す例では、操作履歴ＤＢ１２ａおよび余暇時間ＤＢ１２ｂがサーバ１の内部メモリである記憶部１２に格納されているが、本実施形態はこれに限定されず、外部メモリに格納されていてもよい。また、図３に示すサーバ１の一部または全ての構成がクライアント２に設けられていてもよい。

＜＜３．動作処理＞＞
続いて、本実施形態による情報処理システムの動作処理について、図７〜図２２を参照して具体的に説明する。

＜３−１．余暇時間の推定処理＞
図７は、本実施形態による余暇時間の推定処理を示すフローチャートである。図７に示すように、まず、ステップＳ５３において、サーバ１は、ユーザの操作ログを取得する。より具体的には、サーバ１はソーシャルメディア等への書き込み操作履歴を取得する。取得された書き込み操作履歴は、操作履歴ＤＢ１２ａに格納される。

次に、ステップＳ５６において、サーバ１の推定部１０ａは、操作履歴ＤＢ１２ａに格納された書き込み操作履歴を参照してユーザの余暇時間を推定する。より具体的には、推定部１０ａは、例えば１週間の書き込み操作履歴に基づいて書き込みサイクルを抽出し、書き込み時間帯を余暇時間とみなして１週間の余暇時間を推定する。推定された余暇時間データは、余暇時間ＤＢ１２ｂに格納される（ステップＳ５９）。

次いで、ステップＳ６２において、通知制御部１０ｂにより、余暇時間データを参照した通知制御処理が行われる。通知制御処理については、図８を参照して後述する。

続いて、通知に対するユーザ操作をフィードバックとして取得した場合（ステップＳ６５／Ｙｅｓ）、ステップＳ６８において、フィードバック部１０ｄは、取得したポジティブ／ネガティブフィードバックに応じて余暇時間データの更新を行う。

そして、上述したフィードバックの取得および余暇時間データの更新（ステップＳ６５、Ｓ６８）は、本処理が終了するまで繰り返される（ステップＳ７１）。

＜３−２．余暇時間に応じた通知制御処理＞
次に、上記ステップＳ６２で言及した通知制御処理について図８を参照して説明する。図８は、本実施形態による余暇時間に応じた通知制御処理を示すフローチャートである。

図８に示すように、まず、ステップＳ１０３において、サーバ１は、タスクリクエストを受信する。本実施形態において、タスクリクエストは、例えば要返信メッセージ（フレンド申請、予定の確認等）、アンケート、広告等が想定される。

次に、ステップＳ１０６において、通知制御部１０ｂは、タスクリクエストの送信先である対象ユーザが現在余暇時間中であるか否かを、余暇時間ＤＢ１２ｂに格納されている余暇時間データを参照して判断する。

次いで、余暇時間中ではないと判断した場合（Ｓ１０６／Ｎｏ）、ステップＳ１０９において、通知制御部１０ｂは次の余暇時間が到来するまで待機する。

一方、余暇時間中であると判断した場合（Ｓ１０６／Ｙｅｓ）、または上記Ｓ１０９で余暇時間が到来するまで待機した場合、ステップＳ１１２において、通知制御部１０ｂは、リクエスト先の端末（クライアント２）の所定の通知領域にタスクリクエストを通知するよう制御する。このように、本実施形態では、対象ユーザの余暇時間中にタスクリクエストの通知を行うことができる。

次に、クライアント２において通知領域がユーザにタップされた場合（ステップＳ１１５／Ｙｅｓ）、ステップＳ１１８において、通知制御部１０ｂは、通知内容と当該通知への対応可否を選択する表示を含む確認画面を表示する。ここで、クライアント２における通知および確認画面の表示例について図９〜図１２を参照して説明する。図９〜図１２では、一例としてクライアント２Ａの表示部２２Ａに通知および確認画面が表示される場合について説明する。

図９は、本実施形態によるフレンド申請の通知および確認画面の一例を示す図である。図９左に示すように、クライアント２Ａの表示部２２Ａの端部（図５に示す通知領域Ｓ１参照）において、フレンド申請通知Ｎ１が表示される。フレンドとは、ソーシャルメディアを利用しているユーザ間で申請・承認が行われることで成立するものであって、フレンド登録されたユーザ間では互いの情報が提示されたりメッセージを交換したりすることができ、ソーシャルメディアを介して交流を図ることができる。

ユーザが指４でフレンド申請通知Ｎ１をタップすると、図９右に示すように、確認画面２２１が表示部２２Ａにポップアップ表示される。確認画面２２１は、「○○さんからフレンド申請です」といった通知内容を示す表示と、フレンド申請を承認する「承認」ボタン２２１ａ、フレンド申請の承認／拒否を後で判断するため次の余暇時間に再通知させる「再通知」ボタン２２１ｂ、フレンド申請を拒否する「拒否」ボタン２２１ｃを含む。ユーザがいずれかのボタンをタップすると、確認画面２２１は非表示となり、元のアプリケーション実行画面に戻る。なお図９に示す例では、確認画面２２１がポップアップ表示されているが、本実施形態はこれに限定されず、例えば画面全体が確認画面２２１に遷移してもよい。この場合も、確認画面２２１のいずれかのボタンがタップされると元のアプリケーション実行画面に戻る。

図１０は、本実施形態による予定の確認の通知および確認画面の一例を示す図である。図１０左に示すように、クライアント２Ａの表示部２２Ａの端部において、予定の確認通知Ｎ２が表示される。例えばソーシャルメディアを利用しているユーザ間でスケジュール調整を行う際、スケジュールの確認・承認が行われることでイベントの参加可否を登録することが可能である。

ユーザが指４で予定の確認通知Ｎ２をタップすると、図１０右に示すように、確認画面２２２が表示部２２Ａにポップアップ表示される。確認画面２２２は、「２０１０年入社同期会が２０１４年７月２７日（日）１８時からあります」といった通知内容を示す表示と、予定を承認する（出席する）「承認」ボタン２２２ａ、予定確認の承認／拒否を後で判断するため次の余暇時間に再通知させる「再通知」ボタン２２２ｂ、予定を拒否する（欠席する）「拒否」ボタン２２２ｃを含む。ユーザがいずれかのボタンをタップすると、確認画面２２２は非表示となり、元のアプリケーション実行画面に戻る。

図１１は、本実施形態によるアンケートの通知および確認画面の一例を示す図である。図１１左に示すように、クライアント２Ａの表示部２２Ａの端部において、アンケートの通知Ｎ３が表示される。アンケートは、例えば事業主から、登録済みのユーザのうち所定の属性のユーザ宛に送信され得る。

ユーザが指４でアンケートの通知Ｎ３をタップすると、図１１右に示すように、確認画面２２３が表示部２２Ａにポップアップ表示される。確認画面２２３は、「アンケートが届いています。お答えいただくと２００ｐｔ！」といった通知内容を示す表示と、アンケートに回答する「回答」ボタン２２３ａ、アンケートの回答／拒否を後で判断するため次の余暇時間に再通知させる「再通知」ボタン２２３ｂ、アンケートの回答を拒否する「拒否」ボタン２２３ｃを含む。ユーザが「回答」ボタン２２３ａをタップすると、アンケート画面に遷移し、アンケートの回答が終了すると元のアプリケーション実行画面に戻る。一方、ユーザが「再通知」ボタン２２３ｂまたは「拒否」ボタン２２３ｃをタップした場合は、確認画面２２３は非表示となり、元のアプリケーション実行画面に戻る。

図１２は、本実施形態による広告の通知および確認画面の一例を示す図である。図１２左に示すように、クライアント２Ａの表示部２２Ａの端部において、広告通知Ｎ４が表示される。広告は、例えば事業主から、登録済みのユーザのうち所定の属性のユーザ宛に送信され得る。

ユーザが指４で広告通知Ｎ４をタップすると、図１１右に示すように、確認画面２２４が表示部２２Ａにポップアップ表示される。確認画面２２４は、「○○が待望の全国ツアー」といった広告内容を示す表示と、広告商品を購入する「購入」ボタン２２４ａ、広告商品の購入／拒否を後で判断するため次の余暇時間に再通知させる「再通知」ボタン２２４ｂ、広告商品の購入を拒否する「拒否」ボタン２２４ｃを含む。ユーザが「購入」ボタン２２４ａをタップすると、購入画面に遷移し、購入手続きが終了すると元のアプリケーション実行画面に戻る。一方、ユーザが「再通知」ボタン２２４ｂまたは「拒否」ボタン２２４ｃをタップした場合は、確認画面２２４は非表示となり、元のアプリケーション実行画面に戻る。

以上、通知と確認画面の具体的な表示例について説明した。

次いで、図８に戻り、表示された確認画面に含まれる「再通知」ボタンが選択された場合（Ｓ１２１／Ｙｅｓ）、ステップＳ１２４において、サーバ１のフィードバック部１０ｄは、「再通知」ボタンはユーザが現在通知に対する実質的な対応が出来ないために後で再度通知することを指示するものであるため、ネガティブフィードバックと判断し、余暇時間データに反映させる（図６参照）。また、上記ステップＳ１１５において通知領域がタップされなかった場合も（ステップＳ１１５／Ｎｏ）、ステップＳ１２４において、フィードバック部１０ｄは、ネガティブフィードバックと判断して余暇時間データに反映させる。このようなネガティブフィードバックを反映させた後、ステップＳ１０９において、通知制御部１０ｂは次の余暇時間が到来するまで待機し、次の余暇時間が到来した際に、「再通知」が指示された通知や、何ら対応がなされなかった通知を、再度クライアント２に通知するよう制御する。ここで、複数の通知が溜まった場合におけるクライアント２における通知表示例について図１３を参照して説明する。

図１３は、本実施形態による複数の通知の表示例を示す図である。図１３左に示すように、クライアント２Ａの表示部２２Ａの端部において、複数まとめた通知Ｎ５が表示される。ユーザが指４で通知Ｎ５をタップすると、図１３右に示すように、通知内容画面２２５が表示部２２Ａにポップアップ表示される。通知内容画面２２５は、各通知Ｎ２、Ｎ３、Ｎ４を含み、ユーザがいずれかの通知Ｎをタップすると、対応する確認画面（図９〜図１２参照）が表示される。

一方、表示された確認画面に含まれる「再通知」以外のボタンが選択された場合（Ｓ１２１／Ｎｏ）、ステップＳ１２７において、フィードバック部１０ｄは、ユーザが通知に対して承認・回答／拒否といった実質的な対応を行ったためポジティブフィードバックと判断し、余暇時間データに反映させる（図６参照）。また、フィードバック部１０ｄは、「承認・回答」の場合にはポジティブフィードバック、「拒否」の場合にはネガティブフィードバックとするユーザ嗜好学習を行ってもよい。

そして、ステップＳ１３０において、サーバ１の制御部１０は、ユーザの選択に従ってタスク実行／削除の処理を行う。より具体的には、承認／回答ボタンが選択された場合はタスクリクエストの実行処理（例えば承認通知、アンケート画面／広告商品購入画面の表示等）を行い、拒否ボタンが選択された場合はタスクリクエストを削除する。

以上、本実施形態による通知制御処理について説明した。なお上述した例では、フレンド申請、予定の確認、広告、アンケート等、他者からのタスクリクエストを受信した場合における通知制御処理を説明したが、本実施形態はこれに限定されず、例えばユーザが自身で登録したＴＯＤＯリストをユーザに通知する場合に、ユーザの余暇時間を考慮した通知制御を行うことも可能である。以下、図１４〜図１６を参照して具体的に説明する。

（ＴＯＤＯリストの通知制御処理）
図１４は、本実施形態によるＴＯＤＯリストの通知制御処理を示すフローチャートである。図１４に示すように、まず、ステップＳ１４３において、ユーザによりＴＯＤＯリストの登録が行われる。ＴＯＤＯリストの登録は、例えば図１５に示すような画面において行われ得る。

図１５は、ＴＯＤＯリストの登録について説明する図である。図１５に示すように、例えばクライアント２Ａの表示部２２Ａにおいて、Ａさんへメール返信（リストＬ０）、仕事Ｂの方針捻出（リストＬ１）、仕事Ｃの書類作成（リストＬ２）、子ども費の申請（リストＬ３）、・・・議事録を書く（リストＬｎ−１）といったＴＯＤＯリストが入力され、確定ボタン２３０がタップされることにより登録される。

次に、ステップＳ１４６において、通知制御部１０ｂは、ユーザが現在余暇時間中であるか否かを、余暇時間ＤＢ１２ｂに格納されている余暇時間データを参照して判断する。

次いで、余暇時間中ではないと判断した場合（Ｓ１４６／Ｎｏ）、ステップＳ１４９において、通知制御部１０ｂは次の余暇時間が到来するまで待機する。

一方、余暇時間中であると判断した場合（Ｓ１４６／Ｙｅｓ）、または上記Ｓ１４９で余暇時間が到来するまで待機した場合、ステップＳ１５２において、通知制御部１０ｂは、「０→Ｎ」として初期値の挿入を行う。

次に、ステップＳ１５５において、通知制御部１０ｂは、リクエスト先の端末（クライアント２）の所定の通知領域にＴＯＤＯリスト“Ｎ”を通知するよう制御する。「０→Ｎ」の場合、通知制御部１０ｂは、ＴＯＤＯリストＬ０（図１５参照）を通知するよう制御する。このように、本実施形態では、ユーザの余暇時間中にＴＯＤＯリストの通知を行うことができる。

次いで、クライアント２において通知領域がユーザにタップされた場合（ステップＳ１５８／Ｙｅｓ）、ステップＳ１６１において、通知制御部１０ｂは、通知内容と当該通知への対応可否を選択する表示を含む確認画面を表示する。ここで、クライアント２における通知および確認画面の表示例について図１６を参照して説明する。図１６では、一例としてクライアント２Ａの表示部２２Ａに通知および確認画面が表示される場合について説明する。

図１６は、本実施形態によるＴＯＤＯリストの通知および確認画面の一例を示す図である。図１６左に示すように、クライアント２Ａの表示部２２Ａの端部（図５に示す通知領域Ｓ１参照）において、ＴＯＤＯリスト通知Ｎ６が表示される。

ユーザが指４でフレンドＴＯＤＯリスト通知Ｎ６をタップすると、図１６右に示すように、確認画面２２６が表示部２２Ａにポップアップ表示される。確認画面２２６は、「ＴＯＤＯリストに『議事録を書く』が登録されています」といった通知内容を示す表示と、ＴＯＤＯリストを実行する「実行」ボタン２２６ａ、ＴＯＤＯリストの実行／キャンセルを後で判断するため次の余暇時間に再通知させる「再通知」ボタン２２６ｂ、ＴＯＤＯリストの実行を取り止める「キャンセル」ボタン２２６ｃを含む。ユーザがいずれかのボタンをタップすると、確認画面２２６は非表示となり、元のアプリケーション実行画面に戻る。なお図１６に示す例では、確認画面２２６がポップアップ表示されているが、本実施形態はこれに限定されず、例えば画面全体が確認画面２２６に遷移してもよい。この場合も、確認画面２２６のいずれかのボタンがタップされると元のアプリケーション実行画面に戻る。

以上、ＴＯＤＯリストの通知と確認画面の具体的な表示例について説明した。

続いて、図１４に戻り、表示された確認画面に含まれる「再通知」ボタン２２６ｂが選択された場合（Ｓ１６４／Ｙｅｓ）、ステップＳ１６７において、サーバ１のフィードバック部１０ｄは、「再通知」ボタンはユーザが現在通知に対する実質的な対応が出来ないために後で再度通知することを指示するものであるため、ネガティブフィードバックと判断し、余暇時間データに反映させる（図６参照）。また、上記ステップＳ１５８において通知領域がタップされなかった場合も（ステップＳ１５８／Ｎｏ）、ステップＳ１６７において、フィードバック部１０ｄは、ネガティブフィードバックと判断して余暇時間データに反映させる。このようなネガティブフィードバックを反映させた後、ステップＳ１６８において、通知制御部１０ｂは次の余暇時間が到来するまで待機し、次の余暇時間が到来した際に、ステップＳ１５５に戻り、再度クライアント２に通知するよう制御する。

一方、表示された確認画面に含まれる「再通知」以外のボタンが選択された場合（Ｓ１６４／Ｎｏ）、ステップＳ１７０において、フィードバック部１０ｄは、ユーザが通知に対して実行／キャンセルといった実質的な対応を行ったためポジティブフィードバックと判断し、余暇時間データに反映させる（図６参照）。

そして、ステップＳ１７３において、サーバ１の制御部１０は、ユーザの選択に従ってＴＯＤＯリスト“Ｎ”の実行／キャンセル処理を行う。より具体的には、「実行」ボタン２２６ａが選択された場合はＴＯＤＯリスト“Ｎ”の実行処理（例えば図１５に示すＴＯＤＯリスト一覧においてＴＯＤＯリスト“Ｎ”のチェックボックスにチェックを入れる等）を行い、「キャンセル」ボタン２２６ｃが選択された場合はＴＯＤＯリスト“Ｎ”を削除する。

続いて、ステップＳ１７６において、通知制御部１０ｂは、「Ｎ＋１→Ｎ」とする。

次いで、ステップＳ１７９において、「Ｎ＞ｎ−１」であるか否かを判断し、「Ｎｏ」の場合はステップＳ１５５に戻り、ＴＯＤＯリスト“Ｎ”の通知を繰り返すことで、ＴＯＤＯリストＬ０〜Ｌｎ−１を通知する。一方、「Ｙｅｓ」の場合はＴＯＤＯリスト通知の処理が終了する。

＜３−３．余暇時間に基づく状態情報提示処理＞
上述した実施形態では、サーバ１がユーザの余暇時間にタスクリクエストを通知するよう制御し、余暇時間外に受信したタスクリクエストは蓄積して次の余暇時間まで待機することで、ユーザに対して十分な情報提供を行うことができた。一方、タスクリクエストを送信した側のユーザ（要求元ユーザとも称す）は、相手ユーザ（対象ユーザとも称す）の状態が分からないため、送信したタスクリクエストがいつ確認されるのかを把握することができなかった。また、すぐに返信して欲しいタスクリクエストの場合は、対象ユーザが余暇時間中に要求元ユーザから送信することが望まれる。

そこで、本実施形態では、サーバ１が、余暇時間データに基づく対象ユーザの状態を示す情報を要求元ユーザに提示するよう制御する。これにより、要求元ユーザは、タスクリクエストを送信する前に、対象ユーザがすぐに対応できる状態か否か（余暇時間中か否か）を把握することができる。このような本実施形態による状態情報提示処理について、以下、図１７を参照して説明する。図１７に示す例では、要求元ユーザであるユーザＢが、クライアント２Ｂを用いて、タスクリクエストとして「フレンド申請」を送信する場合を想定する。

図１７は、本実施形態による状態情報提示処理を示すフローチャートである。図１７に示すように、まず、ステップＳ２０３において、クライアント２Ｂでは、ユーザ操作に応じてフレンド申請アプリケーションが起動される。

次に、ステップＳ２０６において、クライアント２Ｂは「０→Ｎ」として初期値を挿入する。

次いで、ステップＳ２０９において、クライアント２Ｂはフレンド候補“Ｎ”の状態情報をサーバ１から取得する。サーバ１は、クライアント２Ｂからの要求に応じて、フレンド候補“Ｎ”の余暇時間データを余暇時間ＤＢ１２ｂから抽出し、余暇時間中であれば「対応可」、余暇時間外であれば「対応不可」といった対応可否を状態情報として返信する。

次に、ステップＳ２１２において、クライアント２Ｂは、フレンド候補“Ｎ”の状態（対応可否）を表示する。これにより、ユーザＢは、フレンド申請を行う際に、相手ユーザの現在の状態を把握することができる。

次いで、ステップＳ２１５において、クライアント２Ｂは、「Ｎ＋１→Ｎ」とする。

続いて、ステップＳ２１８において、クライアント２Ｂは、「Ｎ＞ｎ−１」が「Ｙｅｓ」になるまで上記Ｓ２０９〜Ｓ２１５を繰り返すことで、フレンド候補Ｆ０〜Ｆｎ−１の状態情報を表示する。ここで、クライアント２Ｂにおける状態情報の具体的な表示例について図１８〜図２０を参照して説明する。

図１８は、本実施形態による状態情報の表示例を示す図である。図１８に示すように、クライアント２Ｂの表示部２２Ｂには、フレンド申請画面が表示され、当該フレンド申請画面は、複数のフレンド候補Ｆ０〜Ｆｎ−１の表示により構成されている。各フレンド候補Ｆ０〜Ｆｎ−１には、フレンド候補の名前、画像、およびフレンド申請ボタンと共に、当該フレンド候補の状態情報が表示されている。フレンド候補の状態情報は、各フレンド候補の現在の対応可否状況を示すものであって、図１８に示すように、例えば「即時対応不可」または「即時対応可」と表示される。また、対応不可であれば赤色、対応可であれば青色、というように、状態情報が状態に応じて異なる色で表示されてもよい。

これにより、ユーザＢは、各フレンド候補の現在の状態（現在の即時対応の可否）を把握することができ、フレンド申請に対してすぐに返信して欲しい場合は、「即時対応可」の状態情報が提示されているフレンド候補Ｆ１やフレンド候補Ｆｎ−１にフレンド申請を行うことができる。なお、即時対応は期待できないが、即時対応不可となっているフレンド候補に対してもフレンド申請を行うことは可能である。

状態情報の表示例は、図１８に示す例に限定されず、例えば図１９、図２０に示すような表示方法であってもよい。

図１９は、本実施形態による状態情報の他の表示例を示す図である。図１９に示す例では、フレンド申請画面において、即時対応可のフレンド候補Ｆ１、Ｆｎ−１・・・を上位に表示し、即時対応不可のフレンド候補Ｆ０が下位に表示されている。このように、即時対応可のフレンド候補Ｆを優先的に表示することで、ユーザＢは、フレンド申請画面をスクロールして即時対応可のフレンド候補を探す手間が省ける。

また、図２０は、本実施形態による状態情報の他の表示例を示す図である。図２０に示す例では、フレンド申請画面に表示される即時対応不可のフレンド候補Ｆ０において、「即時対応不可」という現在の対応可否を示す情報と、「２１時〜２２時は対応可」という直近の余暇時間（即時対応可能な時間帯）を示す情報が表示されている。このように、状態情報として現在の対応可否だけではなく、直近の（すなわち、次に到来する）対応可能な時間帯を示す情報も表示してもよい。

次に、図１７に戻り、ステップＳ２２１において、ユーザＢによるフレンド“Ｎ”の申請ボタンが選択されると、続くステップＳ２２４において、クライアント２Ｂは、フレンド“Ｎ”申請リクエストをサーバ１に送信する。サーバ１は、クライアント２Ｂからフレンド申請を受信した時点で対象ユーザに通知してもよいし、対象ユーザの余暇時間中であれば通知して余暇時間外であれば蓄積して余暇時間到来時に通知するようにしてもよい。

以上、本実施形態による状態提示制御処理について説明した。なお、図１７では、タスクリクエストとしてフレンド申請を用いたが、タスクリクエストはフレンド申請に限定されず、例えば予定の確認であってもよい。以下、タスクリクエストが予定の確認である場合の対象ユーザ（予定の確認先ユーザ）の状態情報提示処理について図２１を参照して説明する。

（予定の確認における状態情報提示処理）
図２１は、本実施形態による状態情報提示処理を示すフローチャートである。図２１に示すように、まず、ステップＳ２４３において、クライアント２Ｂでは、ユーザ操作に応じてスケジュール確認アプリケーションが起動される。

次に、ステップＳ２４６において、クライアント２Ｂは「０→Ｎ」として初期値を挿入する。

次いで、ステップＳ２４９において、クライアント２Ｂは予定の確認先ユーザ“Ｎ”の状態情報をサーバ１から取得する。サーバ１は、クライアント２Ｂからの要求に応じて、確認先ユーザ“Ｎ”の余暇時間データを余暇時間ＤＢ１２ｂから抽出し、余暇時間中であれば「対応可」、余暇時間外であれば「対応不可」といった対応可否を状態情報として返信する。

次に、ステップＳ２５２において、クライアント２Ｂは、確認先ユーザ“Ｎ”の状態（対応可否）を表示する。これにより、ユーザＢは、予定の確認リクエストを行う際に、相手ユーザの現在の状態を把握することができる。

次いで、ステップＳ２５５において、クライアント２Ｂは、「Ｎ＋１→Ｎ」とする。

続いて、ステップＳ２５８において、クライアント２Ｂは、「Ｎ＞ｎ−１」が「Ｙｅｓ」になるまで上記Ｓ２４９〜Ｓ２５５を繰り返すことで、予定の確認先ユーザＣ０〜Ｃｎ−１の状態情報を表示する。ここで、クライアント２Ｂにおける状態情報の具体的な表示例について図２２を参照して説明する。

図２２は、本実施形態による状態情報の表示例を示す図である。図２２に示すように、クライアント２Ｂの表示部２２Ｂには、スケジュール確認画面が表示され、当該スケジュール確認画面は、スケジュール内容と、複数の確認先ユーザＣ０、Ｃ１の表示と、複数ユーザの対応可能時間の比較表示３００により構成されている。

図２２に示すように、例えばスケジュール内容は、ユーザＢにより「２０１０年入社同期会、日時：２０１４年７月２７日１８：００、場所：ｘｘｘ」と設定されている。参加者追加ボタンは、当該予定への参加ユーザ（予定の確認先ユーザ）を追加する際にタップするものであって、ユーザＢは、参加者追加ボタンをタップしてフレンド一覧画面から追加する参加ユーザを選択することができる。

各確認先ユーザＣ０、Ｃ１には、予定の確認先ユーザの名前、画像、および予定確認ボタンと共に、当該ユーザの状態情報が表示されている。予定の確認先ユーザの状態情報は、図２２に示すように、例えば「即時対応不可」または「即時対応可」と表示される。なお、対応不可であれば赤色、対応可であれば青色と、異なる色で表示されてもよい。

これにより、ユーザＢは、各確認先ユーザの現在の状態（即時対応の可否）を把握することができ、予定の確認リクエストに対してすぐに返信して欲しい場合は、「即時対応可」の状態情報が提示されている確認先ユーザＣ０に確認リクエストを行うことができる。なお、即時対応は期待できないが、即時対応不可となっている確認先ユーザに対しても確認リクエストを行うことは可能である。

また、複数人でスケジュール調整を行う際は、全員の予定確認を同時に行った方が効率がよいため、全ての確認先ユーザが即時対応可の場合に予定確認リクエストを行うことが求められる。このため、例えば図２２に示すように、複数ユーザの対応可能時間の比較表示３００を状態情報の一つとして提示することで、ユーザＢは、全てのユーザが即時対応可能な時間帯を把握することができる。図２２に示す例では、１８時頃に予定の確認リクエストを全てのユーザに送ることで、スケジュール調整を効率よく行うことができる。

次に、図２１に戻り、ステップＳ２６１において、ユーザＢによる確認先ユーザ“Ｎ”の予定確認ボタンが選択されると、続くステップＳ２６４において、クライアント２Ｂは、確認先ユーザ“Ｎ”への予定確認リクエストをサーバ１に送信する。サーバ１は、予定確認リクエストを受信した時点で対象ユーザに通知してもよいし、対象ユーザの余暇時間中であれば通知して余暇時間外であれば蓄積して余暇時間到来時に通知するようにしてもよい。

＜＜４．まとめ＞＞
上述したように、本開示の実施形態による情報処理システムでは、ユーザの余暇時間を推定し、適切なタイミングでユーザへの情報提供を行うことを可能とする。

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

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

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

なお、本技術は以下のような構成も取ることができる。
（１）
インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、前記ユーザの余暇時間を推定する推定部と、
前記推定した余暇時間に所定の通知を行うよう制御する通知制御部と、
を備える、情報処理装置。
（２）
前記通知制御部は、余暇時間外に受信したユーザへの通知を蓄積し、余暇時間が到来した際に蓄積したユーザへの通知を行うよう制御する、前記（１）に記載の情報処理装置。
（３）
前記推定部は、前記情報入力操作の履歴に基づいて、ソーシャルメディアまたは電子メールへの情報入力操作が行われている時間を余暇時間と推定する、前記（１）または（２）に記載の情報処理装置。
（４）
前記推定部は、前記ソーシャルメディアまたは電子メールへの情報入力内容の解析結果に応じて余暇時間を推定する、前記（３）に記載の情報処理装置。
（５）
前記通知制御部は、ユーザ端末の表示画面における所定の通知領域に通知表示を行うよう制御する、前記（１）〜（４）のいずれか１項に記載の情報処理装置。
（６）
前記通知制御部は、前記通知領域に表示された通知がユーザに選択されると、通知内容と当該通知への対応可否を選択する表示を含む確認画面を表示するよう制御する、前記（５）に記載の情報処理装置。
（７）
前記情報処理装置は、
対象ユーザが余暇時間帯か否かを示す状態情報を要求元ユーザに提示する状態提示部をさらに備える、前記（１）〜（６）のいずれか１項に記載の情報処理装置。
（８）
前記状態提示部は、前記状態情報に基づき、要求元ユーザ端末の表示画面において、１以上の対象ユーザがそれぞれ現在余暇時間中であるか否かを表示するよう制御する、前記（７）に記載の情報処理装置。
（９）
前記状態提示部は、前記状態情報に基づき、要求元ユーザ端末の表示画面において、１以上の対象ユーザのうち現在余暇時間中であるユーザを優先的に表示するよう制御する、前記（７）に記載の情報処理装置。
（１０）
前記状態提示部は、前記状態情報に基づき、要求元ユーザ端末の表示画面において、１以上の対象ユーザの余暇時間帯を比較表示するよう制御する、前記（７）に記載の情報処理装置。
（１１）
前記状態提示部は、前記状態情報に基づき、要求元ユーザ端末の表示画面において、対象ユーザが現在余暇時間外である場合は次に到来する余暇時間を表示するよう制御する、前記（７）に記載の情報処理装置。
（１２）
前記情報処理装置は、
前記通知に対してユーザにより実質的な対応が行われたか否かに基づいて、前記推定部により推定された余暇時間を調整するフィードバック部をさらに備える、前記（１）〜（１１）のいずれか１項に記載の情報処理装置。
（１３）
インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、前記ユーザの余暇時間を推定することと、
前記推定した余暇時間に所定の通知を行うよう制御することと、
を含む、制御方法。
（１４）
コンピュータを、
インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、前記ユーザの余暇時間を推定する推定部と、
前記推定した余暇時間に所定の通知を行うよう制御する通知制御部と、
として機能させるための、プログラム。

１ サーバ
１０ 制御部
１０ａ 推定部
１０ｂ 通知制御部
１０ｃ 状態提示部
１０ｄ フィードバック部
１１ 通信部
１２ 記憶部
１２ａ 操作履歴ＤＢ
１２ｂ 余暇時間ＤＢ
３ ソーシャルメディア

Claims (14)

1. インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、前記ユーザの余暇時間を推定する推定部と、
   前記推定した余暇時間に所定の通知を行うよう制御する通知制御部と、
   を備える、情報処理装置。
2. 前記通知制御部は、余暇時間外に受信したユーザへの通知を蓄積し、余暇時間が到来した際に蓄積したユーザへの通知を行うよう制御する、請求項１に記載の情報処理装置。
3. 前記推定部は、前記情報入力操作の履歴に基づいて、ソーシャルメディアまたは電子メールへの情報入力操作が行われている時間を余暇時間と推定する、請求項１に記載の情報処理装置。
4. 前記推定部は、前記ソーシャルメディアまたは電子メールへの情報入力内容の解析結果に応じて余暇時間を推定する、請求項３に記載の情報処理装置。
5. 前記通知制御部は、ユーザ端末の表示画面における所定の通知領域に通知表示を行うよう制御する、請求項１に記載の情報処理装置。
6. 前記通知制御部は、前記通知領域に表示された通知がユーザに選択されると、通知内容と当該通知への対応可否を選択する表示を含む確認画面を表示するよう制御する、請求項５に記載の情報処理装置。
7. 前記情報処理装置は、
   対象ユーザが余暇時間帯か否かを示す状態情報を要求元ユーザに提示する状態提示部をさらに備える、請求項１に記載の情報処理装置。
8. 前記状態提示部は、前記状態情報に基づき、要求元ユーザ端末の表示画面において、１以上の対象ユーザがそれぞれ現在余暇時間中であるか否かを表示するよう制御する、請求項７に記載の情報処理装置。
9. 前記状態提示部は、前記状態情報に基づき、要求元ユーザ端末の表示画面において、１以上の対象ユーザのうち現在余暇時間中であるユーザを優先的に表示するよう制御する、請求項７に記載の情報処理装置。
10. 前記状態提示部は、前記状態情報に基づき、要求元ユーザ端末の表示画面において、１以上の対象ユーザの余暇時間帯を比較表示するよう制御する、請求項７に記載の情報処理装置。
11. 前記状態提示部は、前記状態情報に基づき、要求元ユーザ端末の表示画面において、対象ユーザが現在余暇時間外である場合は次に到来する余暇時間を表示するよう制御する、請求項７に記載の情報処理装置。
12. 前記情報処理装置は、
    前記通知に対してユーザにより実質的な対応が行われたか否かに基づいて、前記推定部により推定された余暇時間を調整するフィードバック部をさらに備える、請求項１に記載の情報処理装置。
13. インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、前記ユーザの余暇時間を推定することと、
    前記推定した余暇時間に所定の通知を行うよう制御することと、
    を含む、制御方法。
14. コンピュータを、
    インターネットへのユーザによる情報入力操作の履歴に基づいて、所定期間内の情報入力サイクルを抽出し、前記ユーザの余暇時間を推定する推定部と、
    前記推定した余暇時間に所定の通知を行うよう制御する通知制御部と、
    として機能させるための、プログラム。
    

Images