特許 6533355 情報処理装置、情報処理方法、プログラム、記憶媒体

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

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

(11)【特許番号】6533355

(24)【登録日】2019年5月31日

(45)【発行日】2019年6月19日

(54)【発明の名称】情報処理装置、情報処理方法、プログラム、記憶媒体

(51)【国際特許分類】

   G06F 13/00 20060101AFI20190610BHJP

【ＦＩ】

   G06F13/00 353C

【請求項の数】13

【全頁数】29

(21)【出願番号】特願2019-510720(P2019-510720)

(86)(22)【出願日】2018年5月31日

(86)【国際出願番号】JP2018020979

【審査請求日】2019年2月21日

【早期審査対象出願】

(73)【特許権者】

【識別番号】399037405

【氏名又は名称】楽天株式会社

(74)【代理人】

【識別番号】100116942

【弁理士】

【氏名又は名称】岩田 雅信

(74)【代理人】

【識別番号】100167704

【弁理士】

【氏名又は名称】中川 裕人

(72)【発明者】

【氏名】内田 有紀

【審査官】 小林 義晴

(56)【参考文献】

【文献】 特開平１０−６３６３８（ＪＰ，Ａ）

【文献】 特開２０１７−１２０５２６（ＪＰ，Ａ）

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

Ｇ０６Ｆ １３／００

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

【請求項1】

端末装置と仲介部の通信セッションが確立されている状態で、情報処理装置が、前記端末装置の入力データに基づいて前記仲介部が生成した処理要求に応じて情報送信を行うことで、送信した情報に基づく出力が前記端末装置で行われるシステムにおける前記情報処理装置であって、
前記仲介部から前記処理要求を受信する要求データ受信部と、
前記処理要求に応じて複数の行程情報を有するガイド情報を取得するガイド情報取得部と、
前記複数の行程情報を間欠的に順次送信するとともに、前記ガイド情報における全ての行程情報の送信が完了する前に前記通信セッションが切断された場合、該通信セッションが切断された際の前記複数の行程情報の送信状況に応じた出力を実行させるための情報を前記端末装置へ送信する情報送信部と、を備える
情報処理装置。

【請求項2】

前記情報送信部は、前記通信セッションが確立されている状態において、前記複数の行程情報を間欠的に順次前記仲介部に送信する
請求項１に記載の情報処理装置。

【請求項3】

前記出力を実行させるための情報は行程情報であり、
前記情報送信部は送信した行程情報における想定時間が経過すると、次の行程情報を、前記通信セッションが確立されている状態においては、前記仲介部に送信し、前記通信セッションが切断された状態においては前記端末装置へ送信する
請求項１又は請求項２に記載の情報処理装置。

【請求項4】

前記情報送信部は、前記通信セッションが切断された状態において、行程情報を前記端末装置にプッシュ通知として送信する
請求項３に記載の情報処理装置。

【請求項5】

前記情報送信部は、前記端末装置に前記出力を実行させるための情報を音声により出力可能な情報として送信する
請求項１乃至請求項４の何れかに記載の情報処理装置。

【請求項6】

前記出力を実行させるための情報は、前記端末装置の起動要求情報である
請求項１乃至請求項５の何れかに記載の情報処理装置。

【請求項7】

前記出力を実行させるための情報はアラーム情報であり、
前記情報送信部は、前記通信セッションが確立されている状態において送信した行程情報における想定時間が経過した際に、前記通信セッションが切断された状態である場合、アラーム情報を前記端末装置へ送信する
請求項６に記載の情報処理装置。

【請求項8】

前記情報送信部は、アラーム情報を前記端末装置へ送信してから所定時間が経過後に前記通信セッションが切断された状態である場合、アラーム情報を再度前記端末装置へ送信する
請求項７に記載の情報処理装置。

【請求項9】

前記情報送信部は、アラーム情報の前記端末装置への送信回数の増加に応じて、より大きい音を鳴らせるようなアラーム情報を前記端末装置に送信する
請求項７又は請求項８に記載の情報処理装置。

【請求項10】

前記情報送信部は、前記仲介部への行程情報の送信が成功したか否かに応じて、前記通信セッションの状態を判定する
請求項１乃至請求項９の何れかに記載の情報処理装置。

【請求項11】

端末装置と仲介部の通信セッションが確立されている状態で、情報処理装置が、前記端末装置の入力データに基づいて前記仲介部が生成した処理要求に応じて情報送信を行うことで、送信した情報に基づく出力が前記端末装置で行われるシステムにおける前記情報処理装置であって、
前記仲介部から前記処理要求を受信する要求データ受信ステップと、
前記処理要求に応じて複数の行程情報を有するガイド情報を取得するガイド情報取得ステップと、
前記複数の行程情報を間欠的に順次送信するとともに、前記ガイド情報における全ての行程情報の送信が完了する前に前記通信セッションが切断された場合、該通信セッションが切断された際の前記複数の行程情報の送信状況に応じた出力を実行させるための情報を前記端末装置へ送信する情報送信ステップと、
を情報処理装置が実行する情報処理方法。

【請求項12】

端末装置と仲介部の通信セッションが確立されている状態で、情報処理装置が、前記端末装置の入力データに基づいて前記仲介部が生成した処理要求に応じて情報送信を行うことで、送信した情報に基づく出力が前記端末装置で行われるシステムにおける前記情報処理装置であって、
前記仲介部から前記処理要求を受信する要求データ受信機能と、
前記処理要求に応じて複数の行程情報を有するガイド情報を取得するガイド情報取得機能と、
前記複数の行程情報を間欠的に順次送信するとともに、前記ガイド情報における全ての行程情報の送信が完了する前に前記通信セッションが切断された場合、該通信セッションが切断された際の前記複数の行程情報の送信状況に応じた出力を実行させるための情報を前記端末装置へ送信する情報送信機能と、
を情報処理装置に実行させるプログラム。

【請求項13】

端末装置と仲介部の通信セッションが確立されている状態で、情報処理装置が、前記端末装置の入力データに基づいて前記仲介部が生成した処理要求に応じて情報送信を行うことで、送信した情報に基づく出力が前記端末装置で行われるシステムにおける前記情報処理装置であって、
前記仲介部から前記処理要求を受信する要求データ受信機能と、
前記処理要求に応じて複数の行程情報を有するガイド情報を取得するガイド情報取得機能と、
前記複数の行程情報を間欠的に順次送信するとともに、前記ガイド情報における全ての行程情報の送信が完了する前に前記通信セッションが切断された場合、該通信セッションが切断された際の前記複数の行程情報の送信状況に応じた出力を実行させるための情報を前記端末装置へ送信する情報送信機能と、
を情報処理装置に実行させるプログラムを記録するコンピュータで読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は情報処理装置、情報処理方法、プログラム、記憶媒体であって、特にユーザの作業を支援するための情報提供についての技術分野に関する。

【背景技術】

【0002】

近年、音声入力により操作可能なアシスタント機能を有するアプリケーション（以下、支援アプリとも表記する。）が存在する。ユーザは、支援アプリを備える端末装置に音声などによる入力操作を行うことで、当該アプリから様々な情報を取得することができる。
特許文献１には、ユーザのメニューの選択に応じて、当該メニューに応じたレシピ情報、調理機器の情報等の調理作業支援のために有効なアドバイスデータを提示する認識装置が開示されている。当該アドバイスデータは、動画、文字情報、文字情報を音声で読み上げる音声情報により提示される。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００８−２６９５８８号公報

【発明の概要】

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

【0004】

このような支援アプリでは、起動時に当該アプリを支援する支援サーバとの間にセッションが確立される。支援アプリは、支援サーバを介して、ユーザにとって必要な情報を有する提供サーバとの通信を行うことができる。
ここで、支援アプリを備える端末装置は、省電力等の観点から、一定時間経過するとスリープ状態となるように設定されていることが多々見受けられる。このとき、端末装置は防犯の観点から、ロック状態となるように設定されている。
端末装置がスリープ状態となると支援アプリの処理が中断され、当該アプリと支援サーバの通信セッションが切断されることになる。そのため、端末装置は、支援サーバを介して提供サーバから情報を受信することができなくなる。
そこで本発明は、端末装置がスリープ状態に移行することでロック状態になった場合であっても、提供サーバから提供される所定の情報を継続してユーザに提供することを目的とする。

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

【0005】

本発明に係る情報処理装置は、端末装置と仲介部の通信セッションが確立されている状態で、情報処理装置が、前記端末装置の入力データに基づいて前記仲介部が生成した処理要求に応じて情報送信を行うことで、送信した情報に基づく出力が前記端末装置で行われるシステムにおける情報処理装置であって、前記仲介部から前記処理要求を受信する要求データ受信部と、前記処理要求に応じて複数の行程情報を有するガイド情報を取得するガイド情報取得部と、前記複数の行程情報を間欠的に順次送信するとともに、前記ガイド情報における全ての行程情報の送信が完了する前に前記通信セッションが切断された場合、該通信セッションが切断された際の前記複数の行程情報の送信状況に応じた出力を実行させるための情報を前記端末装置へ送信する情報送信部と、を備えるものである。
これにより、行程情報の送信中に端末装置と仲介部との通信セッションが途中で切断された場合であっても、情報処理装置から端末装置への情報の送信が行われる。

【0006】

上記した情報処理装置において、前記情報送信部は、前記通信セッションが確立されている状態において、前記複数の行程情報を間欠的に順次前記仲介部に送信することが考えられる。
これにより、端末装置と仲介部との通信セッションが確立されている状態において、情報処理装置は、仲介部を介して端末装置に行程情報を送信する。

【0007】

上記した情報処理装置において、前記出力を実行させるための情報は行程情報であり、前記情報送信部は送信した行程情報における想定時間が経過すると、次の行程情報を、前記通信セッションが確立されている状態においては、前記仲介部に送信し、前記通信セッションが切断された状態においては前記端末装置へ送信することが考えられる。
これにより、端末装置と仲介部との通信セッションが途中で切断された場合であっても、情報処理装置から端末装置へ行程情報を継続して送信することができる。

【0008】

上記した情報処理装置において、前記情報送信部は、前記通信セッションが切断された状態において、行程情報を前記端末装置にプッシュ通知として送信することが考えられる。
これにより、端末装置がロック画面等であった場合にも行程情報を提示することができる。

【0009】

上記した情報処理装置において、前記情報送信部は、前記端末装置に前記出力を実行させるための情報を音声により出力可能な情報として送信することが考えられる。
これにより、端末装置の提示画面へ所定の情報を提示するか否かに関わらず、当該情報を通知することができる。

【0010】

上記した情報処理装置において、前記出力を実行させるための情報は、前記端末装置の起動要求情報であることが考えられる。
端末装置と仲介部との通信セッションが途中で切断された状態において、端末装置はスリープ状態となっていると考えられる。そこで情報処理装置から端末装置への情報送信の際に端末装置の起動要求情報を送信することで、スリープ状態を解除しつつ情報を受信することができる。

【0011】

上記した情報処理装置において、前記出力を実行させるための情報はアラーム情報であり、前記情報送信部は、前記通信セッションが確立されている状態において送信した行程情報における想定時間が経過した際に、前記通信セッションが切断された状態である場合、アラーム情報を前記端末装置へ送信することが考えられる。
これにより、行程情報における想定時間が経過したことを通知することで、端末装置のユーザに注意喚起を行う。ここで、想定時間とは、ユーザが当該行程情報に基づいて作業を行う場合に必要と想定される時間のことをいう。当該想定時間は、それぞれの行程情報ごとに設定されている。

【0012】

上記した情報処理装置において、前記情報送信部は、アラーム情報を前記端末装置へ送信してから所定時間が経過後に前記通信セッションが切断された状態である場合、アラーム情報を再度前記端末装置へ送信することが考えられる。
これにより、ユーザにアラームによる注意喚起を所定時間ごとに継続して行う。

【0013】

上記した情報処理装置において、前記情報送信部は、アラーム情報の前記端末装置への送信回数の増加に応じて、より大きい音を鳴らせるようなアラーム情報を前記端末装置に送信することが考えられる。
これにより、ユーザにアラーム音により端末装置の状況をより認識させやすくなる。

【0014】

上記した情報処理装置において、前記情報送信部は、前記仲介部への行程情報の送信が成功したか否かに応じて、前記通信セッションの状態を判定することが考えられる。
これにより、改めて通信セッションの状態を確認する処理を行うことなく、仲介部への行程情報の送信が成功したか否かにより、端末装置と仲介部の通信セッションの状態を判定することができる。

【0015】

本発明に係る情報処理方法は、端末装置と仲介部の通信セッションが確立されている状態で、情報処理装置が、前記端末装置の入力データに基づいて前記仲介部が生成した処理要求に応じて情報送信を行うことで、送信した情報に基づく出力が前記端末装置で行われるシステムにおける情報処理装置であって、前記仲介部から前記処理要求を受信する要求データ受信ステップと、前記処理要求に応じて複数の行程情報を有するガイド情報を取得するガイド情報取得ステップと、前記複数の行程情報を間欠的に順次送信するとともに、前記ガイド情報における全ての行程情報の送信が完了する前に前記通信セッションが切断された場合、該通信セッションが切断された際の前記複数の行程情報の送信状況に応じた出力を実行させるための情報を前記端末装置へ送信する情報送信ステップと、を情報処理装置が実行する情報処理方法である。

【0016】

本発明に係るプログラムは、上記情報処理方法の各処理を情報処理装置に実行させるプログラムである。
本発明に係る記憶媒体は、上記プログラムを記憶した記憶媒体である。
これらのプログラムや記憶媒体により上記の情報処理装置を実現する。

【発明の効果】

【0017】

本発明によれば、端末装置がスリープ状態となった場合であっても、所定の情報を継続してユーザに提供することができる。

【図面の簡単な説明】

【0018】

【図1】実施の形態のネットワークシステムの構成例の説明図である。

【図2】実施の形態のハードウエア構成の説明図である。

【図3】実施の形態のユーザデータベースの説明図である。

【図4】実施の形態のユーザ端末における提示画面の概要の説明図である。

【図5】実施の形態のユーザ端末における提示画面の概要の説明図である。

【図6】実施の形態のユーザ端末における提示画面の概要の説明図である。

【図7】実施の形態のユーザ端末における提示画面の概要の説明図である。

【図8】実施の形態のユーザ端末における提示画面の概要の説明図である。

【図9】第１の実施の形態のシステム全体の処理の流れの説明図である。

【図10】第１の実施の形態のシステム全体の処理の流れの説明図である。

【図11】第１の実施の形態の提供サーバの処理の流れの説明図である。

【図12】第１の実施の形態の提供サーバの処理の流れの説明図である。

【図13】第１の実施の形態の支援サーバの処理の流れの説明図である。

【図14】第１の実施の形態のユーザ端末の処理の流れの説明図である。

【図15】第１の実施の形態のユーザ端末の処理の流れの説明図である。

【図16】第２の実施の形態のシステム全体の処理の流れの説明図である。

【図17】第２の実施の形態の提供サーバの処理の流れの説明図である。

【図18】第２の実施の形態のユーザ端末の処理の流れの説明図である。

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

【0019】

＜１．全体構成＞
以下、実施の形態におけるネットワークシステムの全体構成について説明する。
図１に実施の形態のネットワークシステムの構成例を示す。この例では、当該ネットワークシステムは、ユーザの入力操作に応じて、ユーザの要求に応じた情報を提示するアシスタントシステムとして機能する。
実施の形態では、ユーザが調理作業を行うにあたり、これから調理を開始する料理の各行程情報の提示をアシスタントシステムにより行う例について説明する。

【0020】

図１における提供サーバ１が本発明請求項の情報処理装置に相当する。
図１に示すように、実施の形態に係るネットワークシステムは、提供サーバ１、１又は複数のユーザ端末２、支援サーバ３がネットワークＮにより相互に通信可能な状態で接続されている。また、提供サーバ１はコンテンツデータベース４にアクセス可能とされている。なお、以下ではデータベースをＤＢ（Database）とも表記する。

【0021】

ネットワークＮの構成は多様な例が想定される。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（VPN:Virtual Private Network）、電話回線網、移動体通
信網、衛星通信網などが想定される。
またネットワークＮの全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線などの有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも使用可能である。

【0022】

提供サーバ１は、ユーザ端末２に提示させる情報を有する情報処理装置である。実施の形態では一例として、提供サーバ１を、料理情報を有する情報処理装置として説明する。
料理情報には、料理の名称、料理に用いる食材、料理を作るための行程、各行程に想定される作業時間等の情報が含まれる。
提供サーバ１は、例えば料理に関するコンテンツ情報の提供会社等に据え置かれた通信機能を備えるコンピュータ装置などにより実現される。

【0023】

ユーザ端末２は、アシスタントシステムによるサービスをユーザに提供するための支援アプリを備える情報処理装置である。支援アプリとは、アシスタントシステムを実現させるための様々な処理をユーザ端末２に実行させるプログラムである。支援アプリの処理を、ユーザ端末２のＯＳ（Operating System）機能を用いて実行することで、実施の形態のアシスタントシステムが実現される。
ユーザは、ユーザ端末２を操作することで、ユーザの要求に応じた情報を支援アプリにより取得することができる。ユーザ端末２には、例えば通信機能を備えたフィーチャーフォンやＰＤＡ、或いはスマートフォンやタブレット端末などのスマートデバイスなどを想定している。なお、ユーザ端末２は、通信機能を備えたＰＣなどにより実現されてもよい。

【0024】

支援サーバ３は、ユーザ端末２からの要求に応じて、支援アプリとの通信セッションを確立する。支援サーバ３は、支援アプリとの通信セッションが確立された状態において、支援アプリを備えるユーザ端末２から受信したユーザの入力情報を解析し、当該解析した入力情報に応じた要求を提供サーバ１に送信する情報処理装置である。
提供サーバ１と支援サーバ３の通信セッションが確立されている状態で、提供サーバ１が、ユーザ端末２の入力データに基づいて支援サーバ３が生成した処理要求に応じて情報送信を行うことで、送信した情報に基づく出力がユーザ端末２で行われる。
支援サーバ３は、例えば支援アプリの提供会社等に据え置かれた通信機能を備えるコンピュータ装置などにより実現される。

【0025】

コンテンツＤＢ４は、提供サーバ１がコンテンツ情報を送信する処理を実行するために必要な情報が格納されたＤＢを示している。実施の形態では一例としてコンテンツＤＢ４について説明するが、ＤＢはコンテンツＤＢ４に限られることはなく、もちろんこれ以外にもインターネットの提供サーバ１として機能するために必要なＤＢを含んで構成されていてもよい。コンテンツＤＢ４の詳細については後述する。

【0026】

続いて、図１に示した提供サーバ１、ユーザ端末２、支援サーバ３、コンテンツＤＢ４を構成する情報処理装置のハードウエア構成を図２に示す。提供サーバ１、ユーザ端末２、支援サーバ３、コンテンツＤＢ４として示した各装置は、情報処理及び情報通信が可能な図２に示すようなコンピュータ装置として実現できる。

【0027】

図２において、コンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ( Read Only Memory)１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ( Random Access Memory )１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、及びＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
入出力インターフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力部１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力部１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、ネットワークＮを介しての通信処理や機器間通信を行う通信部１０９が接続されている。
入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

【0028】

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介してデータやプログラムを受け渡したりすることが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、提供サーバ１、ユーザ端末２、支援サーバ３、コンテンツＤＢ４としての必要な情報処理や通信が実行される。
なお、提供サーバ１、ユーザ端末２、支援サーバ３、コンテンツＤＢ４を構成する情報処理装置は、図２のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮ（Local Area Network）などによりシステム化されていてもよいし、インターネットなどを使用したＶＰＮ（Virtual Private Network）などにより遠隔地に通信可能な状態で配置されたものでもよい。複数の情報処理装置には、クラウドコンピューティングサービスによって利用可能なサーバ群（クラウド）としての情報処理装置が含まれてもよい。

【0029】

＜２．サーバ、ユーザ端末及びデータベースの機能＞
図１及び図３を用いて、提供サーバ１、ユーザ端末２、支援サーバ３、コンテンツＤＢ４の機能について説明する。
ここで、提供サーバ１、ユーザ端末２、支援サーバ３は、１又は複数の情報処理装置で構成される。提供サーバ１、ユーザ端末２、支援サーバ３の各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し、以下説明する全部又は一部の各構成の処理をハードウエアにより実現してもよい。
また各機能をソフトウエアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。また各機能は複数の情報処理装置に分散されていてもよい。さらに機能の一つが複数の情報処理装置によって実現されてもよい。

【0030】

図３に示すように、提供サーバ１は、要求データ受信部１１とガイド情報取得部１２と情報送信部１３とを有する。
要求データ受信部１１は、支援アプリを備えるユーザ端末２と支援サーバ３との通信セッションが確立された状態において、ユーザ端末２から受信した入力情報を解析する処理を実行する支援サーバ３から、該解析した入力情報に応じた要求を受信する。

【0031】

ガイド情報取得部１２は、要求データ受信部１１が支援サーバ３から受信した要求に応じて、複数の行程を有するガイド情報を取得する。ここでガイド情報とは、ユーザがある作業を行うために必要な複数の行程情報を有する情報をいう。実施の形態では一例として、料理情報をガイド情報としている。料理情報には、料理の名称や料理に用いる食材、料理を作るための各行程の行程情報、各行程に想定される想定時間情報が含まれている。

【0032】

情報送信部１３は、支援アプリによりユーザ端末２と支援サーバ３の通信セッションが確立された状態において、料理情報の各行程のタイミングごとに対応する行程情報を支援サーバ３に送信する。
また情報送信部１３は、ユーザ端末２と支援サーバ３の通信セッションが切断された状態において、料理情報に含まれる想定時間情報に基づく所定のタイミングごとに、所定の情報をユーザ端末２へ送信する。ユーザ端末２と支援サーバ３の通信セッションは、例えばユーザ端末２がスリープ状態となった場合に支援アプリが終了すること等で切断される。

【0033】

ここで所定のタイミングとは、例えば、ユーザがレシピ情報の各行程を行う際に、必要と想定される想定時間が経過したタイミングをいう。また、あらかじめ設定した一定時間が経過するタイミングとしてもよい。所定のタイミングは、上述したタイミングに限られず、様々な態様が想定される。
また所定の情報とは、例えばユーザが作業をするためのガイド情報に含まれる各行程の情報をいう。実施の形態では料理情報をいう。所定の情報は、上述した情報に限られず、例えばロック解除を要求する、アラーム音を通知する、ユーザ端末２を振動させるといった情報のように、ユーザに提示するための様々な情報が含まれる。

【0034】

ユーザ端末２は、起動操作を検知すると自身のＯＳ機能により当該支援アプリを起動する。ユーザ端末２は、起動した支援アプリにより支援サーバ３と通信セッションを確立する。その後、ユーザ端末２は支援アプリにより、ユーザの入力情報に応じた様々な要求を支援サーバ３に送信する。
またユーザ端末２は、支援サーバ３や提供サーバ１から受信した情報に応じた様々な処理を実行する。
ユーザ端末２は、設定により一定時間経過後にスリープ状態となる制御を行う。この場合、ユーザ端末２は、支援アプリを終了する処理を行う。またユーザ端末２は、スリープ状態になった際に、自身をロック状態とする制御を行う。

【0035】

支援アプリは、ユーザ端末２のＯＳ機能によりユーザからの様々な入力操作を検知すると、当該入力操作による入力情報を解析する。実施の形態では、ユーザの音声による入力操作として説明する。もちろん入力操作は音声によるものに限られず、ユーザの手動による端末操作やテキスト入力による操作等、様々な入力態様が考えられる。
支援アプリは、例えば入力された音声データをテキストデータに解析し、当該テキストデータを支援サーバ３に送信する。またユーザ端末２が支援サーバ３から受信した情報は、支援アプリによりユーザ端末２に様々な処理を実行させる。

【0036】

支援サーバ３は、支援アプリによりユーザ端末２から受信したテキストデータを解析し、解析した情報に応じた様々な要求を提供サーバ１に送信する。
また支援サーバ３は、提供サーバ１から受信した情報をユーザ端末２に送信する。

【0037】

次に、上記機能を備えた提供サーバ１が、ユーザ端末２からの支援サーバ３を介した要求に応じたガイド情報（料理情報）を取得するために用いるコンテンツＤＢ４について説明する。ＤＢは、もちろんコンテンツＤＢ４以外にもインターネットの提供サーバ１として機能するために必要な他のＤＢを含んで構成されていてもよい。

【0038】

コンテンツＤＢ４には、例えば図４に示すように、それぞれのコンテンツに関する作業にあたってのガイド情報が記憶されている。実施の形態では料理情報が記憶されている。例えば、各料理の識別情報であるＩＤ（Identification）に対して、料理情報には、料理の名称、料理に用いる食材、料理を作るための行程、各行程に想定される作業時間等の情報が紐付けられて記憶されている。

【0039】

またコンテンツＤＢ４には、本アシスタントシステムを構成する様々なウェブページデータが記憶されている。記憶されるウェブページデータとしては、例えば各行程の説明情報やレシピに用いる食材情報等が挙げられる。これらのウェブページデータは、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible Hyper Text Markup Language）などの構造化文書ファイルである。
提供サーバ１は、コンテンツＤＢ４から取得した画像やテキストを、支援サーバ３を介してユーザ端末２のブラウザ上で提示させる。

【0040】

以上のコンテンツＤＢ４等の各ＤＢは、提供サーバ１とは別のサーバコンピュータ内に構築されていてもよいし、提供サーバ１内に構築されていてもよい。
また図示及び説明の便宜上、コンテンツＤＢ４として示したが、当該ＤＢは、提供サーバ１がアクセス可能とされていればどのような形態で実現されていてもよい。例えば提供サーバ１と同一システム内の記憶部に当該ＤＢのすべてが形成されていてもよいし、当該ＤＢの一部又は全部が別体、遠隔地などのコンピュータシステムに設けられていてもよい。もちろん各ＤＢが一つの装置（例えば一つのＨＤＤなど）内に形成されている必要はない。また各ＤＢのそれぞれが、それぞれ１つのＤＢとして構成される必要もない。例えばコンテンツＤＢ４として記憶される情報が、複数のＤＢ（例えば食材情報に関するコンテンツＤＢと行程情報に関するコンテンツＤＢなど）により記憶管理されてもよいし、コンテンツＤＢ４として記憶される情報が、他のＤＢにより記憶管理されてもよい。実施の形態で説明する上記各ＤＢは、実施の形態の処理に関連する情報の記憶部を、それぞれ一つのＤＢの形態で例示したものに過ぎない。

【0041】

＜３．ユーザ端末における提示画面の概要＞
実施の形態におけるユーザ端末２における提示画面の概要を説明する。ユーザが本アシスタントシステムを利用する場合のユーザ端末２に提示される画面の一例について、図５乃至図８を用いて説明する。
図５Ａは、ユーザ端末２により提示される機能選択画面ＤＳ１である。ユーザは、ユーザ端末２のタッチパネル等で画面上の様々な機能を選択操作することによって、ユーザ端末２により様々な機能を実現する。機能選択画面ＤＳ１は、例えばＧＵＩ（Graphical User Interface）等により実現される。

【0042】

機能選択画面ＤＳ１には、アイコンａｐ１、ａｐ２、ａｐ３…が表示されている。ユーザは、それぞれのアイコンａｐを選択操作することで、各アイコンａｐに対応するアプリを起動することができる。実施の形態では、例えばユーザがアイコンａｐ１を選択することで、本アシスタントシステムを実現する支援アプリが起動する。

【0043】

当該支援アプリが起動すると、ユーザ端末２には、図５Ｂに示すようなアシスト画面ＤＳ２が表示される。
アシスト画面ＤＳ２には、まず支援アプリ側から、例えば「はい、どんなご用でしょう」といった文字を有する吹き出しＳＰ１が表示される。また、ユーザ端末２は、吹き出しＳＰ１を表示する際に、支援アプリによるＯＳ機能上の処理により表示された文字を読み上げて音声としてユーザに通知する。

【0044】

次にユーザは、例えば「オススメの料理を紹介して」といった情報の入力操作を行う。当該入力操作は、ユーザの音声による入力操作である。
これにより、図６Ａに示すように、ユーザの音声による入力操作に応じて、アシスト画面ＤＳ２に「オススメの料理を紹介して」といった文字を有する吹き出しＳＰ２が表示される。
なお、実施の形態では音声による入力操作の例として説明するが、ユーザは、ユーザ端末２にテキストを打ち込む操作を行うことで入力操作を行ってもよい。

【0045】

このような、ユーザのレシピ情報の要求に応じて、支援アプリ側は、提案する料理情報をアシスト画面ＤＳ２に表示する。ここでは、一例として提案する料理を「肉じゃが」とすると、図６Ｂに示すように、アシスト画面ＤＳ２に「肉じゃがはどうでしょう？」といった文字を有する吹き出しＳＰ３が表示される。また、ユーザ端末２は、吹き出しＳＰ３を表示する際に、表示された文字を読み上げて音声としてユーザに通知する。

【0046】

またこのとき支援アプリ側は、調理に必要な食材の情報をアシスト画面ＤＳ２に表示する。例えば、料理「肉じゃが」を作るための食材として例えば「じゃがいも３個、たまねぎ２分の１個、にんじん２分の１本、牛肉１００ｇ…」といった文字を有する吹き出しＳＰ４が表示される。
なお、吹き出しＳＰ４には、調理に必要な食材が表示されているウェブページへのリンク先のＵＲＬ（Uniform Resource Locator）を提示してもよい。また、支援アプリ側は吹き出しＳＰ４について、ユーザから食材の提示要求がされた際に表示することとしてもよい。
また図示しないが、支援アプリ側は料理を提案する際に、当該料理の料理情報における行程の概要をアシスト画面ＤＳ２に表示してもよいし、当該行程全体が表示されているウェブページへのリンク先のＵＲＬを提示してもよい。
このように、本アシスタントシステムでは、対話形式により支援アプリ側がユーザ側の要求に回答することとなる。

【0047】

吹き出しＳＰ３、ＳＰ４に提示された料理を閲覧したユーザが、当該料理を作ることを希望したとする。この場合、ユーザ側は食材を揃えた後、調理を開始する際に例えば「作り方を教えて」といった情報の入力操作を行う。これにより、ユーザ側は、支援アプリ側に希望した料理情報（ガイド情報）を要求する。
これにより、図７Ａに示すように、アシスト画面ＤＳ２に「作り方を教えて」といった文字を有する吹き出しＳＰ５が表示される。
なお、提示された料理以外の料理を選択したい場合は、ユーザ側は、その旨を音声入力等により支援アプリ側に要求することができる。これにより、支援アプリ側から他の料理が提案される。またユーザ側は、料理を要求する際に、料理ジャンル、用いる食材、何人前等、様々な条件を設定して要求してもよい。

【0048】

ユーザからのレシピ情報の要求に応じて、支援アプリ側はレシピについて行程毎に情報を提示する。
例えば、料理「肉じゃが」のレシピは「野菜や牛肉等を切る行程」と、「野菜や牛肉等を炒める行程」と、「だし汁を注ぎ煮込む行程」と、「火を止めて肉じゃがが完成する行程」とからなるものとする。
この場合に支援アプリ側は、図７Ｂに示すように、まず最初の「野菜や牛肉等を切る行程」が記載された吹き出しＳＰ６をアシスト画面ＤＳ２に表示させる。そして、当該表示から所定時間が経過すると「野菜や牛肉等を切る行程」が終了したとして、次の「野菜や牛肉等を炒める行程」を記載した吹き出しＳＰ７がアシスト画面ＤＳ２に表示される。
このように、支援アプリ側は、各行程に想定される作業時間としてあらかじめ設定された時間が経過すると、次の行程の情報をアシスト画面ＤＳ２に表示させる。

【0049】

こうして、各行程の作業時間経過ごとに、「だし汁を注ぎ煮込む行程」が吹き出しＳＰ８として表示され、「火を止めて肉じゃがが完成する行程」が吹き出しＳＰ９に表示される。そして、吹き出しＳＰ９のような「料理が完成する行程」が表示されることで、ユーザ側の行程毎の情報提示が終了する。

【0050】

このようなアシスタントシステムにおいて、例えば「肉じゃが」の行程の中で「だし汁を注ぎ煮込む行程」を表示してから「火を止めて肉じゃがが完成する行程」を表示するまでに、２０分といった比較的長い時間が設けられている場合がある。
ここで、ユーザ端末２は、設定により３０秒程でスリープ状態に移行する。またスリープ状態に移行すると、ユーザ端末２はロック状態となるように設定されている。

【0051】

ユーザ端末２がスリープ状態となることで支援アプリによる処理が中断され、支援アプリを有するユーザ端末２と支援サーバ３との通信セッションが切断されてしまう。そのため、料理の行程情報を提供サーバ１が支援サーバ３を介してユーザ端末２に送信することができなくなる。よって、ユーザに継続して料理の各行程情報を通知することができなくなってしまう。

【0052】

この場合、スリープ状態から復帰するとユーザ端末２のディスプレイには、例えば図８Ａに示すようなロック画面ＤＳ３が表示される。ユーザは、ユーザ端末２のロック状態を解除するため、ユーザ端末２に手動で解除操作を行う必要がある。そしてユーザ端末２をロック状態から回復させた後、支援アプリ等を起動させ、支援サーバ３との通信セッションを再度確立させることとなる。その後、作っていた料理のレシピ情報を支援アプリ側に再度要求する。
しかしながら、既に作りたい料理が決まっているにも関わらず、図５Ａに示すような支援アプリ側とのやり取りを再度行わなければならないことは、ユーザにとって不便である。

【0053】

また、料理を調理しているユーザにとっては、衛生面や端末を汚したくないといった観点から、スリープ解除やロック解除等の操作を行うにあたり、ユーザ端末２に触りたくないといった要望もある。

【0054】

そこで、実施の形態のアシスタントシステムは、スリープ状態になることでユーザ端末２がロック状態になっても、ユーザ端末２のロック画面ＤＳ３上に、継続して直前のアシスト画面ＤＳ２に表示されていた行程の続きの行程を表示することができることとした。

【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】

また支援サーバ３は、ステップＳ３０６において、提供サーバ１から所定の情報を受信すると、ステップＳ３０７に処理を進め、所定の情報を解析し、ユーザ端末２の支援アプリに応じたテキストデータへの変換を行う。
ここで所定の情報とは、各行程情報等の料理情報やアラーム音を通知させるための情報等、様々な情報のことをいう。
そして、支援サーバ３は、ステップＳ３０８において、当該変換したテキストデータをユーザ端末２へ送信する。ステップＳ３０８の処理の後、支援サーバ３は上述の監視ループの処理に戻る。

【0092】

次に、アシスタントシステムを実現するための支援アプリを備えるユーザ端末２の処理について、図１４及び図１５を用いて説明する。図１４においてユーザ端末２は、ステップＳ４０１→Ｓ４０４→Ｓ４０８→Ｓ４１１についてループして監視を行う。

【0093】

まずユーザ端末２は、ステップＳ４０１において、ユーザの入力操作によるアプリ起動操作を検知すると、ステップＳ４０２に処理を進める。ここで、ユーザの入力操作とは、例えば図５Ａにおけるタッチパネルによるアイコンａｐの選択操作等である。
その後、ユーザ端末２は、ステップＳ４０２において支援アプリを起動し、続くステップＳ４０３において、起動した支援アプリによりユーザ端末２と支援サーバ３との通信セッションを確立する処理を実行する。
ステップＳ４０３の処理を終えると、ユーザ端末２は上述の監視ループの処理に戻る。

【0094】

またユーザ端末２は、ステップＳ４０４において、要求情報を検知するとステップＳ４０５に処理を進める。ここで要求情報には、料理の提案の要求や料理の行程情報の要求等、様々な要求が考えられる。またユーザは、そのような要求をユーザ端末２に音声による入力することで行う。

【0095】

ユーザ端末２は、ステップＳ４０５において、支援アプリにより入力された音声データの解析を行い、支援サーバ３との通信に適したテキストデータに変換する。そしてユーザ端末２は、ステップＳ４０６において、当該テキストデータを支援サーバ３に送信する。
ステップＳ４０６の処理を終えると、ユーザ端末２は上述の監視ループ処理に戻る。

【0096】

またユーザ端末２は、ステップＳ４０８においてスリープ条件が成立した場合、ステップＳ４０９に処理を進める。ここでスリープ条件の成立とは、例えばユーザ端末２をユーザが操作しなくなってから一定時間が経過した状態をいう。ここでの一定時間とは、ユーザ端末２により設定されるもので、例えば３０秒、３分等である。

【0097】

このときユーザ端末２は、ステップＳ４０９において、ユーザ端末２をスリープ状態に制御する処理を行う。また、ユーザ端末２は、続くステップＳ４２０において自身をロック状態となるよう制御する。
そして、ステップＳ４１０において、ユーザ端末２は、支援アプリが起動している場合は、当該アプリの処理を中断する処理を行う。これにより、支援アプリによるユーザ端末２と支援サーバ３との通信セッションが切断される。
ステップＳ４１０の処理を終えると、ユーザ端末２は図１４の処理を終了し、図１５の処理を実行する。

【0098】

ここで、図１５を用いて、スリープ状態におけるユーザ端末２の処理について説明する。
まずユーザ端末２は、ステップＳ４５０において、提供サーバ１からユーザ端末２の起動要求を受信するまで待機する。当該起動要求を受信すると、ユーザ端末２は、スリープ状態から復帰し、ステップＳ４５１においてディスプレイに図８Ａに示すようなロック画面ＤＳ３を提示する。
なお、ユーザ端末２は、ユーザのユーザ端末２への入力操作等により、スリープ状態から復帰することも可能である。

【0099】

ユーザ端末２は、ステップＳ４５１の処理の後、ステップＳ４５２→Ｓ４５４→Ｓ４５５についてループして監視を行う。
ユーザ端末２は、ステップＳ４５２において、提供サーバ１から行程情報を受信すると、ステップＳ４５３に処理を進め、当該行程情報に応じた提示処理を行う。ユーザ端末２は、図８Ｂに示すように、行程情報をプッシュ通知として吹き出しＳＰ１０に表示させる。また、ユーザ端末２は、行程情報の内容を音声によっても通知することも可能である。

【0100】

またユーザ端末２は、ステップＳ４５４においてロック解除操作を検知すると、自身のロック状態を解除する。そしてユーザ端末２は図１５の処理を終了し、図１４の監視ループ処理に戻る。
またユーザ端末２は、ステップＳ４５５においてスリープ条件が成立した場合、ステップＳ４５０に処理を進め、起動要求を受信するまで待機する。

【0101】

図１４に戻り、ユーザ端末２は、ステップＳ４１１において行程情報を受信すると、ステップＳ４１２に処理を進める。ユーザ端末２は、支援サーバ３から要求した料理の行程情報を順次受信する。
ユーザ端末２は、ステップＳ４１２において行程情報の提示制御を行う。例えば、図７Ｂに示すように、各行程の作業時間経過ごとにアシスト画面ＤＳ２上に行程情報が吹き出しＳＰとして提示される。
ステップＳ４１２の処理を終えると、ユーザ端末２は上述の監視ループ処理に戻る。

【0102】

＜６．第２の実施の形態＞
第２の実施の形態におけるアシスタントシステムの動作を実現するために、支援アプリを備えるユーザ端末２、支援サーバ３及び提供サーバ１が実行する処理の概要について、図１６を用いて説明する。以下、第１の実施の形態と同様の処理については同様の符号を付し、説明を省略する。また、支援サーバ３の処理の詳細については、第１の実施の形態と同様であるため説明を省略する。
第２の実施の形態では、提供サーバ１が、要求された料理の各行程情報を所定時間ごとに支援サーバ３に送信している状態において、ステップＳ３２での通信セッション状態の切断により、ステップＳ３４にて行程情報が支援サーバ３に送信できない場合、アラーム情報をユーザ端末２に提示させる。

【0103】

まず提供サーバ１は、第１の実施の形態と同様の処理を行った後、ステップＳ３４において第３の行程情報を支援サーバ３に送信する。しかしながら、ステップＳ３２においてユーザ端末２の支援アプリと支援サーバ３との通信セッションは切断されてしまっている。そのため、提供サーバ１は支援サーバ３に第３の行程情報を送信することができない。
この場合、提供サーバ１は、ステップＳ４０において、アラーム情報をユーザ端末２に送信し、ユーザ端末２にアラーム情報を提示制御する。

【0104】

アラーム情報を受信したユーザ端末２は、ステップＳ４５において、自身をスリープ状態から復帰させる起動処理を行う。そしてユーザ端末２は、ステップＳ４１において、図８Ｂの吹き出しＳＰ１０に「調理状況を確認して下さい」といった注意喚起の文字を表示し、端末からアラーム音を発生させる。
これにより、調理中に寝てしまったユーザや、調理場を離れてしまったユーザに対して、注意喚起を行うことができる。

【0105】

また提供サーバ１は、ステップＳ４０でのアラーム情報送信から所定時間Ｔａが経過すると、ステップＳ４２において再度第３行程情報を支援サーバ３に送信する。
提供サーバ１は、支援サーバ３に第３の行程情報を送信することができない場合、ステップＳ４３において、前回よりも音量の大きいアラーム音の音声データを含むアラーム情報をユーザ端末２に送信する。
そして、ユーザ端末２は、ステップＳ４６において、自身をスリープ状態から復帰させる起動処理を行い、ステップＳ４２において、図８Ｂの吹き出しＳＰ１０に注意喚起の文字を表示し、端末から前回よりも大きいアラーム音を発生させる。

【0106】

提供サーバ１は、その後も所定の時間Ｔａの経過毎に前回よりも大きいアラーム音を含む情報をユーザ端末２に送信する。
なお、所定時間Ｔａは、例えば３分毎といったように一定の間隔としてもよいし、３分、２分、１分…といったように段々短くなるように設定してもよい。また、通知するアラーム音の大きさは、毎回同じ音量でもよいし段々小さくなるように設定してもよい。

【0107】

次に、第２の実施の形態での図１１のステップＳ１０４の所定情報送信処理における、提供サーバ１の処理について図１７を用いて説明する。
提供サーバ１は、ステップＳ２０１において、第ｎ行程情報を支援サーバ３に送信し、ステップＳ２０２において送信が成功したかを判定する。そして、支援サーバ３への第ｎ行程情報の送信が失敗した場合、提供サーバ１は、ステップＳ２０２からステップＳ２１０に処理を進める。

【0108】

提供サーバ１は、ステップＳ２１０において、アラーム情報をユーザ端末２に送信する。そして、ステップＳ２１１において、提供サーバ１は、ユーザ端末２に当該アラーム情報に応じた提示制御を行う。これにより、ユーザ端末２の図８Ｂのロック画面ＤＳ３の吹き出しＳＰ１０に注意喚起の文字が表示され、端末からアラーム音が発せられる。

【0109】

また提供サーバ１は、ステップＳ２１２において、時間ｔ（ａ）の計測を開始する。そして提供サーバ１は、ステップＳ２１３において、時間ｔ（ａ）がアラーム通知を行うために設定された閾値Ｔａ以上となるまで待機する。閾値Ｔａはアラームを通知するためにあらかじめ設定された値である。

【0110】

提供サーバ１は、ステップＳ２１３において時間ｔ（ａ）が閾値Ｔａ以上になるまで待機する。ステップＳ２１３にて時間ｔ（ａ）が閾値Ｔａ以上となると、提供サーバ１はステップＳ２１４において、第ｎ行程情報を支援サーバ３に送信し、ステップＳ２１５において送信が成功したかを判定する。

【0111】

ステップＳ２１５において支援サーバ３への第ｎ行程情報の送信が失敗した場合、ユーザ端末２の支援アプリと支援サーバ３の通信セッションが確立されていない状態である。従って、ユーザ端末２は、未だスリープ状態であると考えられる。
そこで、提供サーバ１は、ステップＳ２１５からステップＳ２１６に処理を進め、前回よりも音量の大きいアラーム音の音声データを含むアラーム情報をユーザ端末２に送信する。その後、提供サーバ１はステップＳ２１１に処理を進め、ユーザ端末２に当該アラーム情報に応じた提示制御を行う。
提供サーバ１は、ステップＳ２１５で第ｎ行程情報の送信が成功するまで、ステップＳ２１１〜Ｓ２１６の処理を継続して実行する。
なお、提供サーバ１は、ユーザ端末２や支援サーバ３からの要求に応じて、アラーム音の通知に関する処理を中止することもできる。

【0112】

提供サーバ１は、ステップＳ２１５において、支援サーバ３への第ｎ行程情報の送信が成功したと判定すると、図１７の処理を終了し、図１４のステップＳ１０５に処理を進める。

【0113】

次に、第２の実施の形態におけるユーザ端末２の処理について、図１８を用いて説明する。図１４での監視ループにおいて、ユーザ端末２は、ステップＳ４０８においてスリープ条件が成立した場合、ステップＳ４０９→Ｓ４２０→Ｓ４１０と処理を行うことで、ユーザ端末２をスリープ状態及びロック状態に制御し、ユーザ端末２と支援サーバ３の通信セッションが切断される。

【0114】

そして図１８において、スリープ状態におけるユーザ端末２の処理が実行される。このときユーザ端末２は、ステップＳ４５１にてロック画面を提示した後、ステップＳ４６０→Ｓ４５４→Ｓ４５５についてループして監視を行う。

【0115】

ユーザ端末２は、ステップＳ４６０において提供サーバ１からアラーム情報を受信すると、自身をスリープ状態から復帰させる起動処理を行う。そしてユーザ端末２は、ステップＳ４５３において、受信したアラーム情報に応じたアラーム音を端末から発生させる。
またユーザ端末２は、アラーム音を発生させる際に、例えば図８Ｂに示すように、吹き出しＳＰ１０に「調理状況を確認して下さい」といった注意喚起の文字を表示することもできる。
ステップＳ４５３の処理を終えると、ユーザ端末２は上述の監視ループ処理に戻る。
ユーザ端末２のステップＳ４５４及びＳ４５５の処理については、第１の実施の形態と同様の処理のため説明を省略する。

【0116】

＜７．まとめ及び変形例＞
上記した実施の形態等で説明した提供サーバ１は、仲介部（支援サーバ３）から処理要求を受信する要求データ受信部１１と、処理要求に応じて複数の行程情報を有するガイド情報（料理情報）を取得するガイド情報取得部１２と、複数の行程情報を間欠的に順次送信するとともに、ガイド情報（料理情報）における全ての行程情報の送信が完了する前に端末装置（ユーザ端末２）と仲介部（支援サーバ３）の通信セッションが切断された場合、該通信セッションが切断された際の複数の行程情報の送信状況に応じた出力を実行させるための情報を端末装置（ユーザ端末２）へ送信する情報送信部１３と、を備えるものである。また提供サーバ１は、ユーザ端末２と支援サーバ３の通信セッションが確立されている状態において、複数の行程情報を間欠的に順次仲介部（支援サーバ３）に送信する。

【0117】

これにより、ユーザ端末２と支援サーバ３との通信セッションが途中で切断された場合であっても、提供サーバ１からユーザ端末２への情報の送信が行われる。
ユーザ端末２がスリープ状態となることで支援アプリによる処理が中断され、支援アプリを有するユーザ端末２と支援サーバ３との通信セッションが切断されてしまう。そのため、料理の行程情報を提供サーバ１が支援サーバ３を介してユーザ端末２に送信することができなくなる。よって、ユーザに継続して料理の各行程情報を通知することができなくなってしまう。このような場合であっても行程情報等の情報を継続してユーザに提供することができる。つまり、時間経過によりユーザ端末２がスリープ状態となっても時系列に沿ったガイド等の情報を提示することができる。

【0118】

また、ユーザ端末２がスリープ状態となってしまうと、ユーザは、続きの情報を取得するためにユーザ端末２のスリープ状態やロック状態を手動による解除操作を行う必要がある。そして、支援アプリ等を起動することで支援サーバ３との通信セッションを再度確立させ、作っていた料理のレシピ情報を支援アプリ側に再度要求することになる。しかしながら、既に作りたい料理自体の提案は終わっているにも関わらず、図５Ａに示すような支援アプリ側とのやり取りを行わなければいけないことは、ユーザにとって不便であった。
このような場合、ユーザ端末２に触れることなく、視覚又は聴覚により、料理の行程情報を把握することができることは、作業中のユーザにとって利便である。

【0119】

また実施の形態において、提供サーバ１と支援サーバ３を別々の情報処理装置として説明したが、提供サーバ１と支援サーバ３は一つの情報処理装置として形成されていてもよい。つまり、実施の形態における提供サーバ１としての情報処理装置が支援サーバ３の機能を有していてもよい。

【0120】

また提供サーバ１は、ユーザ端末２に行程情報又はアラーム情報等の所定の情報、即ち複数の行程情報の送信状況に応じた出力を実行させるための情報を音声により提示可能な情報として送信することが考えられる。
これによりユーザ端末２の提示画面へ所定の情報を提示するか否かに関わらず、当該情報を通知することができる。ここでアラーム情報は、音による通知でもよいし、振動、発光等の端末装置を使用しているユーザに意識を向けさせるための様々な通知態様が考えられる。

【0121】

料理を調理しているユーザにとっては、衛生面や端末を汚したくないといった観点から、スリープ解除等の操作を行うにあたり、ユーザ端末２に触りたくないといった要望もある。
そのため、ユーザ端末２に触れることなく、聴覚により料理の行程情報を把握することは、作業中のユーザにとって利便性の向上に繋がる。
また料理中は、火気等を取り扱う場合や、タイミングが大切な行程も存在する。従って、ユーザにとって、ユーザ端末２の画面をずっと見ているわけにはいかない場合が多々存在する。そのため、音声により料理の行程等の情報を受信できることはユーザにとっての利便性の向上に直結する。
また、音声で行程情報を認識することが可能となることで、視覚障害を有する者にとっても実益がある。

【0122】

また所定の情報は行程情報であり、提供サーバ１は、送信した行程情報における想定時間が経過すると、次の行程情報を、通信セッションが確立された状態においては支援サーバ３に送信し、通信セッションが切断された状態においてはユーザ端末２へ送信することが考えられる。
これにより、ユーザ端末２と支援サーバ３との通信セッションが途中で切断された場合であっても、提供サーバ１からユーザ端末２へ行程情報を継続して送信することができる。つまり、ユーザは、ユーザ端末２に触れることなく、料理の行程情報を把握することができる。

【0123】

また提供サーバ１は、通信セッションが切断された状態において、行程情報をユーザ端末２にプッシュ通知として送信することが考えられる。
これによりユーザ端末２がロック画面等であった場合にも行程情報を提示することができる。即ち、ユーザがユーザ端末２のロック画面の解除操作を行わなくても、続きの行程情報を継続して確認することができる。

【0124】

また所定の情報、即ち複数の行程情報の送信状況に応じた出力を実行させるための情報は、ユーザ端末２の起動要求情報であることが考えられる。
ユーザ端末２と支援サーバ３との通信セッションが途中で切断された状態において、ユーザ端末２はスリープ状態となっていると考えられる。そこで提供サーバ１からユーザ端末２への情報送信の際にユーザ端末２の起動要求情報を送信することで、スリープ状態を解除しつつ情報を受信することができる。

【0125】

つまり、ユーザ端末２がスリープ状態であった場合でも、自動的にスリープ状態を解除し、続きの行程情報を継続して確認することができる。これにより、ユーザ端末２が行程情報を通知するとき以外はスリープ状態としておくことが可能となる。従って、ユーザ端末２のバッテリの節約を図ることができる。

【0126】

また所定の情報、即ち複数の行程情報の送信状況に応じた出力を実行させるための情報はアラーム情報であり、提供サーバ１は、通信セッションが確立された状態において送信した行程情報における想定時間が経過した際に、通信セッションが切断された状態である場合、アラーム情報をユーザ端末２へ送信することが考えられる。これにより、行程情報について所定の時間が経過したことを通知することで、ユーザ端末２のユーザに注意喚起を行う。

【0127】

例えば、煮込みに２０分かかるといったように、行程の中には、次の行程のナビゲーションまでに長時間を有することがある。この場合、調理中のユーザが寝てしまったり、調理場からいなくなってしまうことも想定される。そういった場合にアラーム音でユーザに行程が経過している旨を伝えることが可能となる。
なお、所定の情報としてアラーム情報だけでなく経過時間の情報等を送信してもよい。

【0128】

また提供サーバ１は、アラーム情報をユーザ端末２へ送信してから所定時間が経過後に通信セッションが切断された状態である場合、アラーム情報を再度ユーザ端末２へ送信することが考えられる。
これにより、ユーザが気がつくまでアラームによる注意喚起を定期的に継続して行う。これにより、調理中のユーザにより効果的な注意喚起を行うことができる。

【0129】

また提供サーバ１は、アラーム情報のユーザ端末２への送信回数の増加に応じて、より大きい音を鳴らせるようなアラーム情報をユーザ端末２に送信することが考えられる。
これにより、ユーザにアラーム音によりユーザ端末２の状況をより認識させやすくなる。これにより、調理中のユーザにより一層効果的な注意喚起を行うことができる。

【0130】

また提供サーバ１は、ユーザ端末２への行程情報の送信が成功したか否かに応じて、ユーザ端末２と支援サーバ３の通信セッションの状態を判定することが考えられる。
これにより、改めて通信セッションの状態を確認する処理を行うことなく、支援サーバ３への行程情報の送信が成功したか否かにより、ユーザ端末２と支援サーバ３の通信セッションの状態を判定することができる。従って、通信処理回数の削減による通信の効率化や、通信容量の削減を図ることが可能となる。

【0131】

なお、本実施の形態においては、コンテンツの一例として料理を用い、料理の行程情報等のアシスタントシステムとして説明したが、ここでのコンテンツは料理に限られることはなく、所定の事項に関する文章、図表、画像、音声などの情報であればコンテンツの長短や内容については特に限定しない。コンテンツとしては、例えば広告やニュース、レビュー、ブログなどが挙げられる。

【0132】

また、本アシスタントシステムにおいて提供するガイド情報についても、料理の行程に限られることはなく、道案内における順路ごとの情報、工作における制作手順、新着ニュース情報のニュース情報ごとの提供等、様々な手順を含む情報が考えられる。

【0133】

また、本実施の形態について説明した処理は、それぞれが独立した処理であってもよいし、それぞれの処理を組み合わせて行うことも可能である。なお、実施の形態の組み合わせとしては、上記した例の他にも様々な態様が考えられる。

【0134】

＜８．プログラム及び記憶媒体＞
以上、本実施の形態の情報処理装置の実施の形態としての提供サーバ１を説明してきたが、実施の形態のプログラムは、提供サーバ１における各処理を情報処理装置（ＣＰＵなど）に実行させるプログラムである。

【0135】

実施の形態のプログラムは、端末装置と仲介部の通信セッションが確立されている状態で、情報処理装置が、前記端末装置の入力データに基づいて前記仲介部が生成した処理要求に応じて情報送信を行うことで、送信した情報に基づく出力が前記端末装置で行われるシステムにおける前記情報処理装置であって、前記仲介部から前記処理要求を受信する要求データ受信機能と、前記処理要求に応じて複数の行程情報を有するガイド情報を取得するガイド情報取得機能と、前記複数の行程情報を間欠的に順次送信するとともに、前記ガイド情報における全ての行程情報の送信が完了する前に前記通信セッションが切断された場合、該通信セッションが切断された際の前記複数の行程情報の送信状況に応じた出力を実行させるための情報を前記端末装置へ送信する情報送信機能と、を情報処理装置に実行させるプログラムである。

【0136】

このようなプログラムにより、上述した提供サーバ１としての情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置などの機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭなどに予め記憶しておくことができる。或いはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的或いは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウエアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータなどにインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークによりダウンロードすることもできる。

【0137】

最後に、上述した各実施の形態の説明は本技術の一例であり、本技術は上述の実施の形態に限定されることはない。このため、上述した各実施の形態以外であっても、本技術に係る技術的思想を逸脱しない範囲であれば、設計などに応じて種々の変更が可能であることはもちろんである。

【符号の説明】

【0138】

１…提供サーバ、２…ユーザ端末、３…支援サーバ、４…コンテンツＤＢ、１１…要求データ受信部、１２…ガイド情報取得部、１３…情報送信部

【要約】

端末装置がスリープ状態となった場合であっても、行程情報を継続してユーザに提供する。
本発明に係る情報処理装置は、端末装置と仲介部の通信セッションが確立されている状態で、情報処理装置が、前記端末装置の入力データに基づいて前記仲介部が生成した処理要求に応じて情報送信を行うことで、送信した情報に基づく出力が前記端末装置で行われるシステムにおける情報処理装置であって、前記仲介部から前記処理要求を受信する要求データ受信部と、前記処理要求に応じて複数の行程情報を有するガイド情報を取得するガイド情報取得部と、前記複数の行程情報を間欠的に順次送信するとともに、前記ガイド情報における全ての行程情報の送信が完了する前に前記通信セッションが切断された場合、該通信セッションが切断された際の前記複数の行程情報の送信状況に応じた出力を実行させるための情報を前記端末装置へ送信する情報送信部と、を備えるものである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】