【文献】
大野淳司,SNSを利用した情報家電の遠隔制御・監視システムの提案,情報処理学会研究報告 2012(平成24)年度 1 [CD−ROM],日本,一般社団法人情報処理学会,2012年 6月15日,Vol.2012-DPS-151 No.13,p.1-7
(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0011】
(本発明の基礎となった知見)
本発明者は、「背景技術」の欄において記載した、コミュニケーション方法に関し、以下の問題が生じることを見出した。
【0012】
近年、インターネットに接続可能なテレビやレコーダなどのAV(Audio Visual)家電が増加し、映画やスポーツなどの動画配信サービスが提供されている。また、体重計、活動量計、炊飯器、オーブンレンジ、又は、冷蔵庫などの生活家電と呼ばれる家電機器もインターネットへの接続が進んでいる。これにより、家電機器の操作履歴を含む操作情報、又は、動作履歴を含む動作情報を、インターネットを通じてサーバに送信し、サーバで蓄積・分析することが行われている。また、サーバでの分析結果を利用して、利用者に様々なサービスを提供することも行われている。
【0013】
一方で、ユーザ間のコミュニケーションを促進するインターネットサービスとして、Facebook、Twitter又はLine等のソーシャルネットワークサービスが広く使われている。
【0014】
Facebookは、ユーザがインターネット上で友達関係を構築し、ユーザが投稿する自身の状況等を記したテキスト文章や写真を友人同士で共有し、閲覧又は返信を行うことで、ユーザ同士のコミュニケーションを可能とするサービスである。
【0015】
Twitterは、ミニブログとも呼ばれ、自身の状況等を記した短いテキスト文章をサーバに投稿し、サーバに蓄積されるテキスト文章を利用者間で共有することで、利用者に楽しみを提供するコミュニケーションサービスである。
【0016】
Lineは、ユーザ間でリアルタイムに短いメッセージのやりとりを行うことができるコミュニケーションサービスである。
【0017】
以降では、このようなコミュニケーションサービスにおいて、ユーザが投稿する自身の状況等を記したテキスト文章又は写真のことを、「つぶやき」と定義する。
【0018】
最近では、人であるユーザではなく、機器が現在の状況に基づいてつぶやきを自動的に生成して、人であるユーザが閲覧を行うサービスが検討され始めている。例えば、特許文献1は、ソーシャルネットワークの原理を機器に適用したネットワーク管理システムを開示する。特許文献1に開示される技術によれば、ユーザとモノとの間、又は、モノ同士の間でFacebookの友達関係のような関係が構築され、ユーザと機器との間でSNSライクなコミュニケーションが取られる。
【0019】
特許文献2は、車両の走行状態に関する情報に基づいて、投稿すべきつぶやきを生成し、生成したつぶやきをユーザの代わりに自動的に投稿するシステムを開示する。
【0020】
このような機器がつぶやきを自動的に発生させる場合には、大量のつぶやきを記録し迅速な検索を実現するデータベースの構築が課題となる。一般的に人が保有する電子機器は、人の数よりも多く、それらの機器がインターネットに接続される場合に、機器が人と同じくらいの頻度でつぶやきを発生させる場合には、人が発生するつぶやきの数よりも、機器が発生するつぶやきの数は当然多くなり、巨大なデータベースシステムの構築が必要となってしまう。
【0021】
つまり、上記のように機器がつぶやきを生成し投稿する場合、投稿されるつぶやきの数は、人間により投稿されるつぶやきの数より飛躍的に多くなる可能性がある。つぶやきの数が多いほど、投稿されるサーバの処理負荷がより大きくなる。
【0022】
本発明では、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができるコンテンツ提示方法などを提供する。
【0023】
このような問題を解決するために、本発明の一態様に係るコンテンツ提示方法は、ユーザの行動履歴情報を取得する取得ステップと、機器から前記ユーザへの対話のためのコンテンツを生成する頻度を前記行動履歴情報に基づき決定し、決定した前記頻度で前記コンテンツを生成するコンテンツ生成ステップと、生成された前記コンテンツを配信することで、前記コンテンツを前記ユーザに提示する提示ステップとを含む。
【0024】
これによれば、機器に関するコンテンツの生成頻度が、ユーザの行動履歴情報に基づいて決定される。具体的には、ユーザの行動履歴から判定される、ユーザによるコンテンツの閲覧可能性に応じて、当該コンテンツの生成頻度が決定される。よって、本発明に係るコンテンツ提示方法により、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0025】
従来技術によれば、コンテンツの種別と生成頻度とは、機器が動作したこと(又は、動作しなかった)ことなどを契機として決定されるが、当該コンテンツを閲覧するユーザの行動履歴情報には無関係である。本発明に係るコンテンツ提示方法では、生成するコンテンツの種別と頻度とをユーザの行動履歴情報を考慮して決定することで、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0026】
例えば、前記コンテンツ生成ステップでは、さらに、生成する前記コンテンツの種別を前記行動履歴情報に基づき決定し、決定した種別の前記コンテンツを生成する。
【0027】
これによれば、機器に関するコンテンツの種別が、ユーザの行動履歴情報に基づいて決定される。具体的には、ユーザの行動履歴から判定される、ユーザによるコンテンツの閲覧可能性に応じて、当該コンテンツの種別が決定される。よって、本発明に係るコンテンツ提示方法により、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0028】
例えば、前記提示ステップでは、前記ユーザによる前記コンテンツの閲覧要求を受け付け、受け付けた前記閲覧要求に応じて前記コンテンツを前記ユーザに提示し、前記取得ステップでは、前記提示ステップで受け付けた前記閲覧要求の頻度を含む情報を、前記行動履歴情報として取得し、前記コンテンツ生成ステップでは、前記行動履歴情報における前記閲覧要求の頻度が低いほど、前記コンテンツをより低い頻度で生成し、又は、前記行動履歴情報における前記閲覧要求の頻度が高いほど、前記コンテンツをより高い頻度で生成する。
【0029】
これによれば、コンテンツの閲覧要求の頻度が低いユーザに対して、より少ない数のコンテンツが提示される。これにより、ユーザが一度に閲覧すべきコンテンツが当該ユーザの閲覧頻度に応じて削減され、ユーザが一度に閲覧すべきコンテンツの数が閲覧頻度によらずおおむね一定になるようにすることができる。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0030】
例えば、前記取得ステップでは、前記提示ステップで受け付けた前記閲覧要求の頻度が第一閾値未満である第一時間帯を特定する情報を、前記行動履歴情報として取得し、前記コンテンツ生成ステップでは、前記行動履歴情報から特定される前記第一時間帯において、前記第一時間帯を含まない時間帯における前記コンテンツの生成頻度より低い頻度で前記コンテンツを生成する。
【0031】
これによれば、ユーザによるコンテンツの閲覧要求の頻度が低い時間帯(第一時間帯)において、より少ない数のコンテンツが提示される。これにより、ユーザが閲覧する可能性が低い時間帯のコンテンツの生成が抑制され、ユーザが閲覧する可能性が高い時間帯のコンテンツの生成が維持される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0032】
例えば、前記コンテンツの種別は、前記ユーザに問いかける旨を含むコンテンツを示す第一種別と、前記第一種別を除く第二種別とを含み、前記コンテンツ生成ステップでは、前記行動履歴情報における前記閲覧要求の頻度が低いほど、より低い頻度で前記第二種別のコンテンツを生成し、又は、前記行動履歴情報における前記閲覧要求の頻度が高いほど、より高い頻度で前記第二種別のコンテンツを生成する。
【0033】
これによれば、コンテンツの閲覧要求の頻度が低いユーザに対して、ユーザに問いかける旨のコンテンツを生成することが抑制される。仮に、コンテンツの閲覧要求の頻度が低いユーザに、問いかける旨のコンテンツを提示したとしても、当該ユーザが当該コンテンツを閲覧するのは比較的長時間経過後と考えられ、そのときに問いかけの回答が得られても適切な機器制御ができない可能性が高いためである。このように、ユーザによりコンテンツが閲覧された結果、適切な制御が行われないことが想定される場合に、当該コンテンツの生成が抑制される。
【0034】
例えば、前記コンテンツの種別は、前記ユーザに問いかける旨を含むコンテンツを示す第一種別と、前記第一種別を除く第二種別とを含み、前記コンテンツ生成ステップでは、前記行動履歴情報における前記閲覧要求の頻度が低いほど、より低い頻度で前記第二種別のコンテンツを生成し、又は、前記行動履歴情報における前記閲覧要求の頻度が高いほど、より高い頻度で前記第二種別のコンテンツを生成する。
【0035】
これによれば、機器に対する操作の頻度が低いユーザに対して、より少ない数のコンテンツが提示される。これにより、ユーザが一度に閲覧すべきコンテンツが当該ユーザの操作の頻度に応じて削減される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0036】
例えば、前記取得ステップでは、前記ユーザによる前記機器に対する操作の履歴に基づいて定められる情報であって、前記ユーザによる前記操作の頻度が第二閾値未満である第二時間帯を特定する情報を、前記行動履歴情報として取得し、前記コンテンツ生成ステップでは、前記行動履歴情報から特定される前記第二時間帯において、前記第二時間帯を含まない時間帯における前記コンテンツの生成頻度より低い頻度で前記コンテンツを生成する。
【0037】
これによれば、過去にユーザが機器を操作したことがある時間帯(第二時間帯)でない時間帯に、コンテンツの生成が抑制され、第三時間帯でのコンテンツの生成が維持される。当該ユーザは、将来的にも第三時間帯に機器を制御する可能性が高いと考えられるので、第三時間帯にコンテンツを生成して提示することでユーザの利便性を損なわずに、コンテンツの数を削減することができる。
【0038】
例えば、前記コンテンツの種別は、前記ユーザに問いかける旨を含むコンテンツを示す第一種別と、前記第一種別を除く第二種別とを含み、前記コンテンツ生成ステップでは、前記行動履歴情報における前記操作の頻度が低いほど、より低い頻度で前記第一種別のコンテンツを生成し、又は、前記行動履歴情報における前記操作の頻度が高いほど、より高い頻度で前記第一種別のコンテンツを生成する。
【0039】
これによれば、機器に対する操作の頻度が低いユーザに対して、ユーザに問いかける旨のコンテンツを生成することが抑制される。これにより、ユーザの利便性を損なわずに、コンテンツの数を削減することができる。
【0040】
例えば、前記コンテンツの種別は、前記ユーザに問いかける旨を含むコンテンツを示す第一種別と、前記第一種別を除く第二種別とを含み、前記コンテンツ生成ステップでは、前記行動履歴情報における前記操作の頻度が低いほど、より低い頻度で前記第一種別のコンテンツを生成し、又は、前記行動履歴情報における前記操作の頻度が高いほど、より高い頻度で前記第一種別のコンテンツを生成する。
【0041】
これによれば、ユーザが、あらかじめ設定された領域にいない場合に、コンテンツの生成が抑制され、上記領域にユーザがいる場合にはコンテンツの生成が維持される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0042】
また、本発明の一態様に係るプログラムは、上記に記載のコンテンツ提示方法をコンピュータに実行させるためのプログラムである。
【0043】
これによれば、上記のコンテンツ提示方法と同様の効果を奏する。
【0044】
なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なCD−ROMなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
【0045】
以下、実施の形態について、図面を参照しながら具体的に説明する。
【0046】
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
【0047】
(提供するサービスの全体像)
図1の(A)には、以下の実施の形態にかかるサービスの全体像が示されている。
【0048】
グループ100は、例えば企業、団体、家庭等であり、その規模を問わない。グループ100には、複数の機器101である機器A、機器Bおよびホームゲートウェイ102が存在する。複数の機器101には、インターネットと接続可能な機器(例えば、スマートフォン、PC、TV等)もあれば、それ自身ではインターネットと接続不可能な機器(例えば、照明、洗濯機、冷蔵庫等)も存在する。それ自身ではインターネットと接続不可能な機器であっても、ホームゲートウェイ102を介してインターネットと接続可能となる機器が存在してもよい。またグループ100には複数の機器101を使用するユーザ10が存在する。
【0049】
データセンタ運営会社110には、クラウドサーバ111が存在する。クラウドサーバ111とはインターネットを介して様々な機器と連携する仮想化サーバである。主に通常のデータベース管理ツール等で扱うことが困難な巨大なデータ(ビッグデータ)等を管理する。データセンタ運営会社110は、データ管理やクラウドサーバ111の管理、それらを行うデータセンタの運営等を行っている。データセンタ運営会社110が行っている役務については詳細を後述する。ここで、データセンタ運営会社110は、データ管理やクラウドサーバ111の運営等のみを行っている会社に限らない。例えば複数の機器101のうちの一つの機器を開発・製造している機器メーカが、併せてデータ管理やクラウドサーバ111の管理等を行っている場合は、機器メーカがデータセンタ運営会社110に該当する(
図1の(B))。また、データセンタ運営会社110は一つの会社に限らない。例えば機器メーカ及び他の管理会社が共同もしくは分担してデータ管理やクラウドサーバ111の運営を行っている場合は、両者もしくはいずれか一方がデータセンタ運営会社110に該当するものとする(
図1の(C))。
【0050】
サービスプロバイダ120は、サーバ121を保有している。ここで言うサーバ121とは、その規模は問わず例えば、個人用PC内のメモリ等も含む。また、サービスプロバイダがサーバ121を保有していない場合もある。
【0051】
なお、上記サービスにおいてホームゲートウェイ102は必須ではない。例えば、クラウドサーバ111が全てのデータ管理を行っている場合等は、ホームゲートウェイ102は不要となる。また、家庭内のあらゆる機器がインターネットに接続されている場合のように、それ自身ではインターネットと接続不可能な機器は存在しない場合もある。
【0052】
次に、上記サービスにおける機器のログ情報(操作履歴情報および動作履歴情報)の流れを説明する。
【0053】
まず、グループ100の機器A又は機器Bは、各ログ情報をデータセンタ110のクラウドサーバ111に送信する。クラウドサーバ111は機器A又は機器Bのログ情報を集積する(
図1の(a))。ここで、ログ情報とは複数の機器101の、例えば運転状況や動作日時等を示す情報である。例えば、テレビの視聴履歴やレコーダの録画予約情報、洗濯機の運転日時・洗濯物の量、冷蔵庫の開閉日時・開閉回数などであるが、これらのものに限らずあらゆる機器から取得が可能なすべての情報をいう。ログ情報は、インターネットを介して複数の機器101自体から直接クラウドサーバ111に提供される場合もある。また複数の機器101から一旦ホームゲートウェイ102にログ情報が集積され、ホームゲートウェイ102からクラウドサーバ111に提供されてもよい。
【0054】
次に、データセンタ運営会社110のクラウドサーバ111は、集積したログ情報を一定の単位でサービスプロバイダ120に提供する。ここで、データセンタ運営会社が集積した情報を整理してサービスプロバイダ120に提供することの出来る単位でもよいし、サービスプロバイダ120が要求した単位でもよい。一定の単位と記載したが一定でなくてもよく、状況に応じて提供する情報量が変化する場合もある。前記ログ情報は、必要に応じてサービスプロバイダ120が保有するサーバ121に保存される(
図1の(b))。そして、サービスプロバイダ120は、ログ情報をユーザに提供するサービスに適合する情報に整理し、ユーザに提供する。提供するユーザは、複数の機器101を使用するユーザ10でもよいし、外部のユーザ20でもよい。ユーザへのサービス提供方法は、例えば、サービスプロバイダから直接ユーザへ提供されてもよい(
図1の(b)及び(e))。また、ユーザへのサービス提供方法は、例えば、データセンタ運営会社110のクラウドサーバ111を再度経由して、ユーザに提供されてもよい(
図1の(c)及び(d))。また、データセンタ運営会社110のクラウドサーバ111がログ情報をユーザに提供するサービスに適合する情報に整理し、サービスプロバイダ120に提供してもよい。
【0055】
なお、ユーザ10とユーザ20とは、別でも同一でもよい。
【0056】
(実施の形態)
本実施の形態において、ユーザビリティを損なうことなく、配送サーバにおける処理負荷を低減することができるコンテンツ提示装置、コンテンツ提示方法、及び、システムについて説明する。なお、コンテンツの例として、ユーザが投稿する自身の状況等を記したテキスト文章又は写真である「つぶやき」を用いて説明するが、本発明はこれに限定されない。
【0057】
図6は、本実施の形態におけるつぶやき生成・閲覧システムの構成を示すブロック図である。なお、つぶやき生成・閲覧システムは、コンテンツ提示システムの一例である。
【0058】
図6に示すように、つぶやき生成・閲覧システムは、つぶやき生成・閲覧サーバ601と、機器602と、つぶやき閲覧機器603とを備える。つぶやき生成・閲覧サーバ601のブロックの一部もしくは全ては、データセンタ運営会社のクラウドサーバもしくはサービスプロバイダのサーバのどちらかに属す。
【0059】
機器602は、グループ100に所属する複数の機器101のうちの1つである。
【0060】
機器602は、通信部631を備える。
【0061】
通信部631は、機器602に対して行われた操作を、機器操作履歴情報としてつぶやき生成・閲覧サーバ601に伝送する。機器操作履歴とは、例えば、電子レンジのボタンのうち利用者が押下したボタンのコード番号、利用者が選択した選択機能に対応した機能識別子、又は、電子レンジのあたため時間などである。機器602には、機器管理DB622で管理されるユニークな機器IDが割り振られており、通信部631は、機器操作履歴を、機器IDと共に送信する。なお、
図6において、機器602が1つだけ示されているが、複数の機器602がつぶやき生成・閲覧サーバ601に接続された場合、つぶやき生成・閲覧サーバ601は、複数台の機器に対応できる。機器操作履歴情報は、行動履歴情報の一例である。
【0062】
つぶやき閲覧機器603は、通信部631と、情報入出力部632とを備える。
【0063】
通信部631は、ネットワークに接続し、通信データを伝送する。つぶやき閲覧機器603は、通信部631を介して、つぶやき生成・閲覧サーバ601からつぶやきを取得する。
【0064】
情報入出力部632は、情報の入力を受け付け、また、情報を出力する。情報入出力部632は、通信部631が取得したつぶやきを出力する。情報入出力部632は、具体的には、情報の出力を行うためのディスプレイ、又は、情報の入力を受け付けるキーボード又はタッチパネルなどである。つぶやき閲覧機器603は、具体的には、PC又はスマートフォン等のデバイスである。
【0065】
つぶやき生成・閲覧サーバ601は、つぶやき生成情報設定部611と、機器操作履歴DB612と、機器操作履歴収集部613と、つぶやき生成部614と、つぶやき頻度管理DB615と、つぶやき頻度算出部616と、ユーザ・機器管理DB617と、閲覧履歴DB618と、つぶやきDB619と、つぶやき提示部620と、機器管理部621と、機器管理DB622とを備える。なお、つぶやきDB619は、つぶやき生成・閲覧サーバ601が備えるのではなく、ネットワークで接続された外部の装置が備えていてもよい。その場合には、つぶやきDB619との通信を行う際には、適切な通信インタフェースを介した通信が行われる。
【0066】
機器管理部621は、つぶやき生成・閲覧サーバ601に接続される機器602の機器ID等の機器のプロフィール情報を設定する。機器管理部621は、設定した情報を、機器管理DB622に記録する。
【0067】
図7は、本実施の形態における機器管理DBのデータ構成の説明図である。
【0068】
図7の(a)は、機器管理DB622に記録される機器のプロフィール情報の例を示している。
【0069】
「機器ID」は、前述した通り機器を判別するためのIDであり、機器管理DB内でユニークになるように設定される。
【0070】
「メーカ」は、機器を製造するメーカの名称である。
【0071】
「品番」は、メーカが設定する機器を区別するための番号である。
【0072】
「製品分類ID」は、該当製品の内容を定義するIDである。製品分類IDは、具体的には、
図7の(b)に示すようなテーブル情報になっており、例えば、製品分類IDの00001は冷蔵庫に、00002は洗濯機に、00003はエアコンに、00004はテレビに、00005は電子レンジにと、それぞれ対応づけられている。この製品分類IDを参照することにより、
図7の(a)における機器IDが00001である製品は、製品分類IDが0001なので冷蔵庫であることがわかる。同様に、機器IDが00002の製品は、製品分類IDが0005なので電子レンジであり、機器IDが00003の製品は、製品分類IDが0003なのでエアコンであることがそれぞれわかる。
【0073】
「製造年月日」は、当該機器が製造された日付である。「製造国」は、当該機器が製造された国である。
【0074】
「機器管理URL」は、当該機器のその他のプロフィール情報を含む、より詳細な情報を格納するURLである。該当URLへのアクセスにより、上記のようなより詳細な情報が取得される。
【0075】
「認証パスワード」は、該当機器のつぶやきを閲覧するためのアクセス権を取得するためのパスワードである。
【0076】
図7の(a)に示したプロフィール情報の属性以外にも、例えば、当該機器の寸法、又は質量等、他の属性に関する情報が格納されていてもよい。
【0077】
機器管理部621は、機器602を製造するメーカが機器602を製造したタイミングで、上記のプロフィール情報を設定してもよいし、機器602がつぶやき生成・閲覧サーバ601に接続されたタイミングで、機器のメーカのサーバ等に自動で問い合わせを行い、設定されるようにしてもよい。
【0078】
なお、機器管理DB622で管理される機器IDは、機器602に伝送され、機器602のメモリ又はHDD等の記憶装置に保存される。前述の通り機器602がつぶやき生成・閲覧サーバ601への接続を行う場合には、上記のように保存された機器IDを接続と同時に通信することで、つぶやき生成・閲覧サーバ601による機器602の判別が行われることになる。
【0079】
図6に戻り、機器操作履歴収集部613は、機器602から機器操作履歴情報を取得し、機器602に付与される機器IDと関連付けて、機器操作履歴DB612に、機器操作履歴を蓄積する。
【0080】
図8は、実施の形態における操作履歴DBのデータ構造の説明図である。
【0081】
図8は機器操作履歴DB612に蓄積される機器操作履歴情報の例を示している。機器操作履歴情報は、履歴IDと、機器IDと、操作時刻と、操作IDと、操作情報とが1つの単位として記録される。
【0082】
「履歴ID」は、機器操作履歴を管理するための番号であり、データベース内でユニークになるように付与される。
【0083】
「操作時刻」は、機器に対して操作が実行された時刻を示す。
【0084】
「操作ID」は、機器に対して実行された操作内容を示すIDである。
【0085】
「操作情報」は、操作IDによって示される操作対象や状態を示すデータである。
【0086】
「操作ID」と「操作情報」とは、あらかじめ製品分類IDごとに仕様が定義されている。これを操作パラメータ定義と呼ぶ。機器操作履歴収集部613は、機器管理DB622を参照し、機器IDに対応する製品分類IDを取得し、以下に示す操作パラメータ定義をさらに参照することで、機器操作履歴情報に蓄積される操作の内容を処理することができる。なお、以降では「操作ID」と「操作情報」とは、製品分類IDごとに定義されるとして説明するが、例えば、品番ごとなど細かい単位で定義できるようにしてもよい。
【0087】
図9は、実施の形態における操作パラメータ定義の説明図である。
【0088】
具体的な操作パラメータの定義内容の例は、
図9に示している。
図9の(a)は、製品分類ID=0001(冷蔵庫)の操作パラメータの定義である。操作IDの定義では、操作ID=0x00000001がドアオープンを、操作ID=0x00000002がドアクローズをそれぞれ示す。操作情報の定義では、0x00000001が冷蔵室を、0x00000002が冷凍室を、0x00000003が野菜室を、0x00000004がチルド室を、それぞれ示す。
【0089】
図9の(b)は、製品分類ID=0003(エアコン)の操作パラメータの定義である。操作IDの定義では、操作ID=0x00000001が電源Onを、操作ID=0x00000002が電源Offを、操作ID=0x00000005が設定温度Up(上昇)を、それぞれ示す。操作情報の定義では、操作実行後のエアコンの設定値を示し、先頭1バイト目がエアコンの運転モードを示し、0x01が冷房を、0x02が除湿を、0x03が暖房を、それぞれ示す。先頭2バイト目は設定温度値を示す。先頭3バイト目は風量設定で、0x01が自動を、0x02が「弱」を、0x03が「強」を、それぞれ示す。先頭4バイト目は風向き設定で0x01が自動を、0x02が「左向き」を、0x03が「右向き」を、それぞれ示す。
【0090】
図9の(c)は、製品分類ID=0005(電子レンジ)の操作パラメータの定義である。操作IDの定義では、操作ID=0x00000001が「温め開始」を、操作ID=0x00000002が「温め終了」を、それぞれ示す。操作情報の定義は設定されない。
【0091】
図8の操作履歴情報の例では、
図9の操作パラメータ定義を参照している。
図8において履歴ID=0に対応する機器IDが00001であり、
図7において製品ID=00001に対応する製品分類IDが0001(冷蔵庫)であるので、冷蔵庫の操作パラメータ定義(
図9の(a))が適用される。よって、履歴ID=0は、操作ID=0x00000001であるので、
図9の(a)の操作パラメータ定義を参照し、ドアオープンであることが分かり、操作情報=0x00000002であるので、
図9の(a)の操作パラメータ定義に基づいて、対象は冷凍室であることが分かる。このようにして、履歴ID=0の操作は、機器ID=0001の冷蔵庫に対して、2013年1月15日12時10分15秒に、冷凍室のドアをオープンしたことが分かる。
【0092】
他の例では、履歴ID=2に対応する機器IDが00003であり、
図7において製品ID=00003に対応する製品分類IDが0003(エアコン)であるので、エアコンの操作パラメータ定義(
図9の(b))が適用される。よって、履歴ID=2は、操作ID=0x00000001であるので、
図9の(b)の操作パラメータ定義を参照し、電源Onであることが分かり、操作情報=0x03191100であるので、
図9の(b)の操作パラメータ定義を参照し、操作実行後のエアコンの設定は運転モード=暖房、設定温度=25度、風量設定=自動、風向き=自動であることが分かる。このようにして、履歴ID=2の操作は、機器ID=0003のエアコンに対して、2013年1月15日12時15分20秒に、電源Onを実行し、その実行後のエアコンの設定状態は、運転モード=暖房、設定温度=25度、風量設定=自動、風向き=自動であることが分かる。
【0093】
図6に戻り、つぶやき提示部620は、つぶやきを閲覧するためのミニブログサーバ又はSNSサーバであり、HTTP(Hypertext Transfer Protocol)等の通信プロトコルを利用し、ユーザ又は機器のつぶやきをつぶやき閲覧機器603に提供する。つぶやき提示部620は、つぶやき閲覧機器603を用いてつぶやき生成・閲覧サーバ601にアクセスするユーザ、及び、機器602を、ユーザ・機器管理DB617によって管理する。
【0094】
なお、つぶやき生成部614が、生成したつぶやきをつぶやきDB619に登録し、登録されたつぶやきをつぶやき提示部620がつぶやき閲覧機器603に提供する、という一連の流れを、「つぶやき生成部614からつぶやき閲覧機器603へ、つぶやきを配信する」と表現する場合もある。また、上記のとおりつぶやきDB619が外部の装置に備えられている場合には、その外部の装置につぶやきを配信させる、ということもできる。
【0095】
図10は、本実施の形態におけるユーザ・機器管理DBのデータ構造の説明図である。
【0096】
図10は、ユーザ・機器管理DB617に記録されるプロフィール情報の例を示している。ユーザ・機器管理DB617には、ユーザIDと、種別と、名前と、フォローするユーザのユーザID(又は、機器の機器ID)と、フォローされるユーザのユーザID(又は、機器の機器ID)と、認証パスワードとが1つのエントリとして記録される。
【0097】
「ユーザID」は、つぶやき提示部620内で管理されるユーザのユニークなIDである。
【0098】
「種別」は、該当のユーザが人なのか、機器なのかを示すフラグ情報である。
【0099】
「名前」は、該当のユーザの名前である。
【0100】
「機器ID」は、「種別」が機器である場合の、機器管理DB622で管理される機器IDである。
【0101】
「フォローするユーザID」は、該当のユーザがフォローするユーザのID群である。
【0102】
「フォローされるユーザID」は、該当のユーザをフォローするユーザのID群である。ここで、「フォローする」とは、指定されるユーザのつぶやきを、最初のページであるタイムラインに閲覧できるようにすることである。例えば、ユーザAが、ユーザBをフォローするとした場合には、ユーザAが閲覧するつぶやきのタイムラインには、ユーザBが作成したつぶやきが表示される。
【0103】
「認証パスワード」は、ユーザがつぶやき提示部620にアクセスする場合のアカウント管理に利用される。
【0104】
フォローするユーザ又は機器を設定する方法を説明する。つぶやき提示部620は、ユーザ・機器管理DB617の検索を行うページをユーザに提供する。ユーザは、提供されたページを使って、機器ID又は名前等を用いて検索を実行する。つぶやき提示部620は、ユーザによる検索の結果出てくるユーザ又は機器を、フォローする対象として設定できるようにする。ユーザAがユーザBをフォローすることを指定した場合には、ユーザBに対して承認依頼が発行され、ユーザBが承認したときのみフォローできるとしてもよい。ユーザAが機器Bをフォローすることを指定する場合には、機器に紐付けられたパスワードを使って承認を認証するように構成してもよい。この場合には、機器管理DB622のエントリにおけるパスワードが利用されてもよい。
【0105】
なお、つぶやき提示部620におけるユーザ同士の関係性を定義するものとして、「フォローする」又は「フォローされる」という言葉を用いて説明を行うが、ユーザ同士の関係性は、これに限定されるものではない。ユーザ同士の関係性は、例えば、Facebook等のSNSで定義されるような「友達関係」であってもよい。この場合、友達関係にあるユーザ又は機器同士は、「フォローする」又は「フォローされる」の関係になるとすれば、本実施の形態の内容が適用され得る。また、ユーザ同士の関係性は、例えば「家族関係」であってもよい。この場合、家族関係にあるユーザ又は機器同士は、「フォローする」又は「フォローされる」の関係になるとすれば、本実施の形態の内容が適用され得る。また、ユーザ同士の関係性は、例えば「所有関係」であってもよい。この場合、所有関係にあるユーザと機器との間では、「フォローする」又は「フォローされる」の関係になるとすれば、本実施の形態の内容が適用され得る。なお、「友達関係」、「家族関係」又は「所有関係」にあるユーザ以外には、ユーザ又は機器のつぶやきを検索や表示もさせないとして、限定されたグループ又はコミュニティでつぶやきの共有を行うようにしてもよい。
【0106】
つぶやき提示部620は、新規にユーザがつぶやき提示部620にアクセスする場合には、「ユーザの新規登録」を提示し、ユーザによるプロフィール情報の入力結果に応じて、ユーザ毎にアカウントを生成し、ユーザのプロフィールをユーザ・機器管理DB617に追加する。
図10に示されるユーザID=00001と00005とは、上記の手順によって追加されたユーザに対応する。また、つぶやき提示部620は、機器管理DB622に登録される機器のプロフィールを元に、ユーザ・機器管理DB617にユーザとして登録する。例えば、
図10に示されるユーザID=0002、0003及び0004は、機器管理DB622に登録される機器に対応する。ユーザID=0002のユーザは、機器ID=0001であるため、
図7の(a)を参照し、機器ID=00001の冷蔵庫であることがわかる。
【0107】
つぶやき提示部620は、ユーザからつぶやきの閲覧命令を受け取ると、つぶやきDB619に格納されるつぶやきから、該当のユーザがフォローするユーザのつぶやきを検索・取得し、つぶやき閲覧機器603に伝送する。
【0108】
図11は、実施の形態におけるつぶやきDBのデータ構造の説明図である。
【0109】
図11は、つぶやきDB619に蓄積されるつぶやきのデータ構造を示す。つぶやきDB619に格納されるデータは、つぶやきIDと、ユーザIDと、時刻と、内容と、返信IDとが1つのエントリとして蓄積される。
【0110】
「つぶやきID」は、つぶやきDB619内でユニークな管理番号であって、各つぶやきに対して設定される管理番号である。
【0111】
「ユーザID」は、該当のつぶやきを発生したユーザを特定するための、ユーザ・機器管理DB617のユーザIDである。
【0112】
「時刻」は、該当のつぶやきが発生した時刻であり、例えば、つぶやきDB619に追加される時刻である。
【0113】
「内容」は、該当つぶやきのテキスト又は写真等のコンテンツ本体である。
【0114】
「返信ID」は、該当エントリの返信先のつぶやきIDを示す。返信IDを参照することで、該当のエントリが、どのつぶやきに対する返信かを判断することが可能となる。
図11の例では、つぶやきID=4のつぶやき「一緒に買い物しよう!」の返信IDが3であるので、つぶやきID=4のつぶやきは、つぶやきID=3のつぶやき「大阪府茨木市イオン前なう。」に対する返信であることが分かる。
【0115】
つぶやき提示部620は、ユーザへのつぶやきの表示だけでなく、ユーザによるつぶやきの書き込み、又は、つぶやきへの返答をも実現する。つぶやき提示部620は、つぶやき閲覧機器603に、つぶやきの書き込みページを提示し、ユーザは、つぶやき閲覧機器603の情報入出力部632により、つぶやきメッセージを入力する。つぶやき提示部620は、つぶやきメッセージを受け取ると、該当ユーザのユーザIDと共に、受け取ったつぶやきメッセージをつぶやきDBに追加する。
【0116】
図10及び
図11の例で、ユーザID=00001のユーザ(sawada55)が、つぶやき提示部620に、つぶやき閲覧命令を実行した場合には、つぶやき提示部620は、
図10のユーザ・機器管理DB617を参照し、ユーザID=00001のユーザがフォローするユーザID=00002、00004、及び00005のユーザと、自身(ユーザID=00001)とが生成した最新のつぶやきを取得する。
図11の例では、つぶやき提示部620は、つぶやきID=0、2、3、4のつぶやきを取得して、つぶやき閲覧機器603に伝送し、つぶやき閲覧機器603は該当のつぶやきを表示する。
図11の例でsawada55がつぶやきを表示させた場合のGUI(Graphical User Interface)の例を
図23の(a)に示す。なお、つぶやき閲覧命令とは、例えば、WebAPI(Web Application Programming Interface)等でのつぶやき取得命令である。
【0117】
また、Facebookでは、発生されたユーザのつぶやきに対して、肯定的又は好意的意見を容易に示すためのI/F(インタフェース)として、「いいね」ボタンがある。「いいね」ボタンは、つぶやきと共に表示され、そのボタンがクリックされることで、ユーザが「いいね」を押したことをユーザインターフェースに提示する。この「いいね」ボタンを実現するためには、一例として、つぶやきDBを
図24のように構成する。
図24では、エントリに「いいね」ボタンを選択したユーザIDが登録されている。つぶやき提示部620は、つぶやきに付与される「いいね」ボタンをユーザが選択した場合には、つぶやきDBの該当つぶやきエントリの「いいねユーザID」に該当ユーザのユーザIDを指定する。このようにすることで、誰がどのつぶやきに「いいね」を選択したかを判断することができる。
図23の(b)は、「いいね」ボタンの提示例を示している。なお、Facebookでは、「いいね」ボタンが、つぶやきに対する肯定的又は好意的意見を容易に示すためのツールとして用いられているが、SNSサイトによって、名称は異なる。例えば、mixiでは、「ミクシチェック」、任天堂のMiiverseでは、「そうだね」ボタンなどである。以降では、「いいね」ボタンを、「肯定的又は好意的意見を容易に示すためのボタンI/F」であるとして説明するが、名称等は、該当のSNS等に応じて、変更してもよい。
【0118】
つぶやき提示部620は、ユーザ毎につぶやきの閲覧履歴(閲覧要求履歴ともいう)を記録して、閲覧履歴DB618に記録する。つぶやきの閲覧履歴は、行動履歴情報の一例である。
【0119】
図12は、実施の形態における閲覧履歴DBのデータ構造の説明図である。
【0120】
図12は閲覧履歴DB618の構造を示す。閲覧履歴DB618は、ユーザIDと、時刻と、操作とを1つのエントリとして記録して管理する。
【0121】
「ユーザID」は、閲覧を実行したユーザのユーザID(ユーザ・機器管理DB617で管理されるユーザID)である。
【0122】
「時刻」は、閲覧操作の実行時刻である。
【0123】
「操作」は操作内容を示し、例えば、最新つぶやきを取得、ユーザの検索、つぶやきの検索、つぶやきの投稿などがある。
【0124】
図6に戻り、つぶやき生成情報設定部611は、つぶやき生成部614のつぶやき発生方法を定義する。つぶやき発生方法とは、自動でつぶやきを発生させるためのアルゴリズムである。
【0125】
図13は、実施の形態におけるつぶやき発生方法の説明図である。
【0126】
上記のアルゴリズムの一例としては、
図13に示すようにC言語等のプログラム言語によって記載されたアルゴリズムがある。アルゴリズムは、製品分類IDごとに設定される。
図13は、製品分類ID=0x0001(冷蔵庫)のつぶやき発生方法の例である。
図13に示すように、eventCallback()と、scheduleCallback()との2種類のコールバック関数が用意され、ユーザは、つぶやき生成情報設定部611を利用して、これら2つの関数を実装することで、つぶやき発生方法を定義する。eventCallback()とscheduleCallback()とはあくまで一例であり、これ以外にコールバックが定義されてもよい。例えば、ユーザがつぶやき提示部620にアクセスしたときに発生するコールバックなどが定義されてもよい。
【0127】
eventCallback()は、機器操作が実行されたタイミングで、実行されるコールバック関数である。引数には、machineID(機器ID)、operationID(操作ID)、及び、operationData(操作情報)が渡される。
図13の例では、冷蔵庫のドアがオープンされた場合と、冷蔵庫がクローズされた場合との例が示されている。先頭文のUserManageDatabaseは、ユーザ・機器管理DB617のプログラム上のクラスオブジェクトを示し、このメソッドを使用することで、データベースにアクセスすることができる。
【0128】
UserManageDatabase.findUser(機器ID)は、機器IDに対応するユーザIDを検索して取得するメソッドであり、返り値でユーザIDを渡す。最初のif文は、operationID==0x0000001であり、ドアオープンされたケースを示す。
【0129】
HistoryDatabaseは、機器操作履歴DB612のプログラム上のクラスオブジェクトを示し、このメソッドを使用することで、データベースにアクセスすることができる。HistoryDatabase.countAtDate(機器ID,操作ID,日付)は、該当機器IDに対して、操作IDで示される操作が、指定される日付で何度実行されたかをカウントするメソッドである。カウントされた回数の結果は、リターン値で返され、
図13の例では、nOpenに格納される。その後のPost()関数は、ユーザIDでつぶやきDB619に該当つぶやきを追加する関数である。Post()は、C言語のprint文を模した関数であり、“%d”は10進数の変数であり、“%d”の箇所にnOpenの値が挿入された文章を生成して、つぶやきDB619に追加する。例えば、nOpenが12であれば、「ドアオープン!今日はこれで12回目のオープンです。」という文章になる。このように、eventCallback()内のアルゴリズムを定義することによって、機器操作が発生したタイミングで、機器操作に基づいたつぶやきの発生方法を定義することが可能となる。
【0130】
scheduleCallback()は、定期的なタイマーイベントとして実行されるコールバック関数である。引数には、machineID(機器ID)が指定される。タイマーの間隔は、システム構成によって設定されるとしてもよいし、つぶやき生成情報設定部611により設定できるとしてもよい。
図13の例では、scheduleCallbackの関数では、TweetDatabaseのメソッドが実行されている。TweetDatabaseは、つぶやきDBのプログラム上のクラスオブジェクトであり、上記メソッドを使用することで、データベースにアクセスすることができる。
【0131】
TweetDatabase.getLastTweet()は、当該機器による最後のつぶやきを取得するメソッドであり、返り値で、最終のつぶやきが返答される。返答された最終のつぶやきは、
図13の例では「tweet」に格納される。
【0132】
「if( Date.now - tweet.date < 10800 ) return」の文は、つぶやきの発生時刻と現在時刻とを比較している条件文であり、Data.nowは秒単位の現在時刻であり、tweet.dateは最後のつぶやきが発生した秒単位の時刻情報を示す。この差を取ることにより、最後のつぶやきから現在までにどれくらいの時間が経過したかを示す。10800秒は3時間であるので、最後のつぶやきから、現在までの経過時間が3時間未満であれば、何も実行せずに終了するとしている。このように構成することで、つぶやきの頻度を調整できる。
【0133】
その後のswitch文は、乱数によってつぶやきの内容を変更することを示している。rand()%100により、0から99までの乱数の結果が計算され、各caseに応じて、出力するつぶやきの内容を変更することで、多くのつぶやきのバリエーションを実現できる。このように、scheduleCallback()内のアルゴリズムを定義することによって、機器が定期的に発生するつぶやきの発生方法を定義することができる。
【0134】
つぶやき生成部614は、つぶやき生成情報設定部611によって設定されたつぶやき生成アルゴリズムにしたがって、機器による自律的なつぶやきの発生を処理する。具体的には、機器管理DB622に定義される機器ごとの単位で、プログラムのスレッドが実行する。実行されたスレッドにおいて、(1)機器操作発生タイミングでeventCallback()が実行され、(2)定期的なタイマーごとにscheduleCallback()が実行される。それ以外の間はwait/idleしている。eventCallback()とscheduleCallback()との内容は、
図13で説明した通り、つぶやき生成情報設定部611によって定義され、この関数を実行した結果、つぶやきDB619につぶやきが追加される。なお、実行するスレッドは機器単位ではなく、ある一定の複数の機器単位でもよい。なお、実行するスレッドは、機器管理DB内の機器のうち、ネットワークに接続可能状態にあるものだけに限定してもよい。
【0135】
また、つぶやき生成部614は、つぶやきDB619に登録されるつぶやきを参照して、そのつぶやきに対して、機器による返信を自動で生成させることも可能である。具体的には、scheduleCallback()等により機器が生成するつぶやきの生成において、該当機器がフォローするユーザのつぶやきを、つぶやきDB619から取得し、取得したつぶやきの内容の解析を行い、返信のつぶやきを生成して、つぶやきDB619に追加すればよい。
【0136】
また、同様に、つぶやき生成部614は、つぶやきDB619に登録されるつぶやきを参照して、そのつぶやきに対して、機器による「いいね」ボタンの選択を自動で行うことも可能である。具体的には、scheduleCallback()等において、該当機器がフォローするユーザのつぶやきを、つぶやきDB619から取得し、その内容の解析を行い、該当つぶやきエントリの「いいねユーザID」に自身のユーザIDを追加することで実現できる。
【0137】
以上、説明した、機器、つぶやき生成・閲覧サーバ、つぶやき閲覧機器を用いることで、機器による自律的なつぶやきの生成、及び、生成されたつぶやきの閲覧を実現することができる。次に、この構成を元に、つぶやきを閲覧するユーザに対してユーザビリティを損なうことなく、機器が自動的に発生させるつぶやきの量を制御することで、つぶやきを蓄積するデータベースの負荷を削減するための方法を説明する。
【0138】
図14は、本実施の形態におけるつぶやき発生頻度のパラメータの説明図である。
【0139】
つぶやき頻度算出部616は、つぶやきの発生頻度を算出し、算出したつぶやき頻度をユーザ・機器管理DB617に格納する。
図14は、ユーザ・機器管理DB617の構成を示しており、
図10の構成に加えて、各エントリに対して、「つぶやき発生頻度」の属性が追加されている。つぶやき頻度算出部616によって算出された、機器が発生するつぶやきの発生頻度は、この「つぶやき発生頻度」に格納される。
【0140】
つぶやき頻度算出部616は、閲覧履歴DB618を参照して、つぶやき発生頻度を算出する。具体的には、例えば、閲覧履歴DBを参照した結果、ユーザID=00001(sawada55)の閲覧は平均1日に1回であり、閲覧履歴DBを参照した結果、ユーザID=00005(taiji)の閲覧は平均8日に1回であるとする。この場合に、つぶやき頻度算出部616は、ユーザID=00001(sawada55)がフォローするユーザ(機器)のつぶやき発生頻度を高く設定し、ユーザID=00005(taiji)がフォローするユーザ(機器)のつぶやき発生頻度を低く設定する。
図14の例では、ユーザID=00001(sawada55)は、ユーザID=00002の機器をフォローしているので、この機器のつぶやき発生頻度の値を、例えば1個/3時間と設定する。一方で、ユーザID=00005(taiji)は、ユーザID=00001の機器をフォローしているので、この機器のつぶやき発生頻度の値を、ユーザID=00001(sawada55)がフォローする機器よりも低く設定し、例えば、1個/24時間と設定する。
【0141】
つぶやき生成部614は、つぶやき頻度算出部616が算出したつぶやき発生頻度に基づいて、機器が発生するつぶやきを生成する。具体的には、schduleCallback()を呼び出すタイマー間隔をこの値に設定してもよいし、
図15に示すように、scheduleCallback()又はeventCallback()などで、該当機器に対応するつぶやき発生頻度を取得して、その値を参照して、つぶやき発生頻度を制御してもよい。
【0142】
図15は、本実施の形態におけるつぶやき発生頻度のパラメータを用いてつぶやきの発生頻度を変更するつぶやき発生方法の説明図である。
図15の例では、UserManageDatabase.getTweetFrequency(ユーザID)によって、発生頻度を取得する。
図15の例では、発生頻度は、1個のつぶやきを発生する平均時間間隔であり、現在時刻と最終つぶやき発生時刻との差分が、これより小さい場合はつぶやきを実行しないとすれば、発生頻度を制御できる。
【0143】
図16は、本実施の形態におけるつぶやき閲覧結果の表示の説明図である。上記のようにユーザがつぶやきを閲覧した表示結果は、例えば
図16のようになる。sawada55が平均1日に1回つぶやきを閲覧する場合に、つぶやき頻度が1個/3時間と設定されれば、フォローする機器が1つの場合には、ログイン時には平均して8個のつぶやきが表示される。一方で、taijiが平均8日に1回つぶやきを閲覧する場合に、つぶやき頻度が1個/24時間と設定されれば、フォローする機器が1つの場合には、ログイン時には平均して8個のつぶやきが表示される。このようにつぶやきの数を、ユーザの閲覧履歴に応じて変動させることで、ユーザがログイン時に閲覧する新着の数が変わらないように設定できるため、ユーザビリティを損なうことがない。なお、つぶやき頻度を平均値として、つぶやきの発生時期にばらつきを持たせる方が、人が行うような自然なつぶやきとなる。
【0144】
このように構成することで、ユーザのつぶやきの閲覧履歴を元に、各機器が自動で発生するつぶやきの頻度を制御することができる。これにより、つぶやきを閲覧するユーザの利便性が損なわれずに、機器が自動的に発生させるつぶやきの量を制御することが可能となる。
【0145】
なお、
図17のように、互いに異なるユーザIDのユーザが、同じ機器IDの機器をフォローする場合には、頻繁に閲覧するユーザの閲覧履歴を元につぶやき発生頻度を決定するように構成してもよい。
図17は、本実施の形態におけるユーザ・機器管理DBの別例を説明する図である。このように構成することで、頻繁にアクセスする利用者のユーザビリティが損なわれない。
【0146】
なお、つぶやき頻度算出部616は、ユーザのつぶやき閲覧履歴をもとに、算出結果として「時間帯」を追加して設定できるようにしてもよい。例えば、ユーザのつぶやき閲覧履歴において、昼付近の時間帯での閲覧が多ければ、ユーザがフォローする機器の「時間帯」に「朝」を設定する。そして、つぶやき生成情報設定部611によって設定されるつぶやき発生方法により、「朝」が設定された機器は、現在時刻を参照して、朝の時間帯に多くつぶやきを生成するようにする。一方、ユーザのつぶやき閲覧履歴において、深夜付近の時間帯での閲覧が多ければ、ユーザがフォローする機器の「時間帯」に「夜」を設定する。そして、つぶやき生成情報設定部611によって設定されるつぶやき発生方法により、「夜」が設定された機器は、現在時刻を参照して、夜の時間帯に多くつぶやきを生成するようにする。このように構成することで、ユーザのライフスタイルに合わせて、タイムリーにつぶやきを発生させることが可能となる。
【0147】
なお、上記の「時間帯」は、「7時から8時まで」というように、開始時刻から終了時刻までの時間として指定されることもある。
【0148】
なお、つぶやきDBのデータ構造としては、
図18のように、データベースへの登録時刻と、つぶやきが発生した時刻とを分けて管理するように構成してもよい。
図18は、本実施の形態におけるつぶやきDBのデータ構造の変形例1を示す図である。この場合には、つぶやき提示部620は、機器がつぶやいた時刻として、データベースへの「登録時刻」ではなく、「つぶやき時刻」をユーザに提示する。つぶやき提示部620は、ユーザが「つぶやき時刻」より前に、アクセスする場合には、該当つぶやきを表示せず、現在時刻がつぶやき時刻を過ぎてからつぶやきを提示する。このように構成することで、つぶやき生成手段は、自身の負荷を考慮もしくは予測を行い、データベースへのつぶやき発生処理をスケジューリングすることができる。つまり、処理負荷が低いタイミングで、あらかじめ分かっている内容のつぶやきを先回りで生成することで、処理負荷を平滑化することが可能となる。
【0149】
なお、
図18のように、データベースへの登録時刻と、つぶやきが発生した時刻とを分けて管理するように構成した場合に、ユーザがつぶやき提示部620にアクセスしたタイミングで、現在時刻よりも過去の時刻を「つぶやき時刻」としたつぶやきを生成しユーザに提示するように構成してもよい。このように構成することで、頻繁にアクセスしないユーザに対する機器つぶやきの発生頻度を抑えることが可能となる。つまり、頻繁にアクセスしないユーザに対しては、つぶやき生成手段は機器のつぶやきの生成をやめておき、ユーザがアクセスしたときにだけ、最新のつぶやきとして、過去のつぶやきを生成して提示するといったことが可能となる。
【0150】
なお、つぶやき頻度算出部616は、ユーザのつぶやき閲覧履歴をもとに算出するとしたが、つぶやき閲覧履歴ではなく、該当機器の使用履歴を利用してもよい。例えば、掃除機の利用が、月に1回のユーザと、週に1回のユーザがいる場合には、週に1回のユーザに対するつぶやき発生頻度を高めるように構成してもよい。このようにすることで、一般に頻繁に機器を利用するユーザは、該当機器に対する興味が高いため、その興味に応えたつぶやきの発生を実現することができる。
【0151】
なお、つぶやき頻度算出部616は、ユーザのつぶやき閲覧履歴をもとに算出するとしたが、つぶやき閲覧履歴ではなく、該当機器以外の使用履歴もしくはセンサーの結果を利用してもよい。例えば、目覚まし時計が機器として、つぶやき生成・閲覧サーバ601に接続されている場合には、目覚まし時計の操作履歴であるOnとOffとが機器操作履歴DB612に蓄積される。この値を参照することにより、目覚まし時計を所有する若しくは保持するユーザの睡眠リズムが分かる。そこで、つぶやき頻度算出部616は、この目覚まし時計の操作履歴を参照し、つぶやき頻度(発生頻度や時間帯)を決定する。このようにすることで、ユーザの生活リズムに合わせて、タイムリーでユーザの状況にあった内容のつぶやきを発生させることができる。例えば、ユーザに対して問いかけを行うようなつぶやきの場合には、ユーザが起きている時間帯に合わせる、といったことが可能となる。なお、目覚まし時計は一例であり、家の電力消費量のグラフなどのログ情報をつぶやき生成・閲覧サーバ601が取得できれば、そうした情報を使うことで、よりユーザに適応させて、つぶやきの発生タイミングや内容を制御できる。なお、「ユーザに対して問いかけを行うようなつぶやき」のことを「第一種別のコンテンツ」といい、第一種別以外のコンテンツを「第二種別のコンテンツ」ということもある。
【0152】
なお、つぶやき頻度算出部616は、ユーザのつぶやき閲覧履歴をもとに算出するとしたが、つぶやき閲覧履歴ではなく、つぶやきの書き込み頻度を利用してもよい。例えば、書き込み頻度が低いユーザに対しては、機器のつぶやき頻度を低くするとしてもよい。言い換えれば、書き込み頻度が高いユーザに対しては、機器のつぶやき頻度を高くするとしてもよい。このようにすることで、ユーザの好みに合わせたつぶやき頻度を実現できる。
【0153】
なお、機器が発生するつぶやきに対して、ユーザが返答を行うことで、該当機器に対する実際の操作を実行できるようにしてもよい。
【0154】
図19は、実施の形態におけるコンテンツ生成・閲覧システムの変形例を示すブロック図である。
図19に示されるつぶやき生成・閲覧サーバ601Aでは、つぶやき生成・閲覧サーバ601に対して、機器操作制御部1801が追加されている。機器操作制御部1801は、つぶやき提示部620からの命令に応じて、該当の機器に対して、「操作命令」を通信する。機器602は、通信部631により、「操作命令」を受け取り、自身の機器操作を実行する。
【0155】
以下、より具体的に説明する。
図20のように、つぶやきDBにはリクエストIDの属性が追加されている。リクエストIDは、製品分類ごとに定義されるリクエストパラメータのIDであり、リクエストパラメータ定義を参照することにより、ユーザが返答を行った後に行うべき操作内容が定義される。
【0156】
具体的には、
図20の(a)のつぶやきDBのつぶやきID=0の例によれば、エアコンによるつぶやきでは、「暖房つけますか?」のテキストと共に、リクエストID=0x00000002が指定されている。リクエストID=0x00000002は、
図20の(b)のリクエストパラメータ定義を参照すると、暖房Onであることが分かる。つぶやき生成部614は、機器の処理をお薦めする質問の場合には、つぶやきDBに、つぶやきのメッセージと共に、ユーザの返答時に行うべき操作内容として、リクエストIDを同時に設定する。このようにリクエストIDが付与されるつぶやきを、「操作お薦めつぶやき」と定義する。
【0157】
つぶやき提示部620がユーザに対して、エアコンによる「暖房つけますか?」のつぶやきを提示した後、このリクエストに対してユーザが「はい」と返答を行えば、つぶやき提示部620は、機器操作制御部1801に対して、該当エアコンの機器IDとリクエストIDとを送信する。機器操作制御部1801は、機器IDから特定される機器であるエアコンがリクエストIDに対応した動作をするための操作命令を生成し、生成した操作命令をエアコンに伝送する。エアコンは、伝送された操作命令を実行する。操作命令は、例えば、
図9で説明したような操作パラメータ定義を用いて記述される。なお、操作お薦めつぶやきに対して、ユーザが「いいえ」と返答するか、又は、何も返答を行わない場合、つぶやき提示部620は、機器操作制御部1801に何も行わない。
【0159】
なお、操作お薦めつぶやきにおいては、
図21Aのように、つぶやきの表示において、ユーザによる回答の選択肢を提示してもよい。このようにすれば、ユーザの意図を正確に反映できる。
【0160】
なお、操作お薦めつぶやきにおいては、
図21Bのように、つぶやきの表示において、「いいね」ボタン等を表示してもよい。ユーザが当該「いいね」ボタン等を押したことを、つぶやき提示部620は、ユーザによる肯定的な意図表示として処理してもよい。このようにすることで、ユーザは、SNSのユーザインターフェースで簡単に意図表示を行うことができる。
【0161】
なお、操作お薦めつぶやきにおいては、
図21Cのように、操作結果を表示してもよい。このようにすることで、ユーザは、自身の意図した操作が、機器により確かに実行されたことを確認することができる。
【0162】
なお、操作お薦めつぶやきにおいては、
図21Dのように、確認メッセージが提示されてもよい。つぶやき提示部620は、ユーザによる返答を正しく解析できない場合には、再度つぶやきを発生させて、確認メッセージを提示するようにしてもよい。このようにすることで、ユーザの意図と異なる誤動作を防ぐことができる。
【0163】
なお、操作お薦めつぶやきは、該当機器以外の使用履歴もしくはセンサーの結果に基づいて、発生するようにしてもよい。例えば、ユーザのスマートフォンのGPS情報を収集し、外出先から家に帰宅することを検知した場合には、ユーザが家に帰宅してから実行する機器の操作履歴を元に、該当機器の操作お薦めつぶやきを生成してもよい。具体例としては、ユーザが家に帰宅することを検知した場合に、ユーザの機器操作履歴に基づき、エアコンが「エアコンつけますか?」と操作お薦めつぶやきを生成する。
【0164】
具体的な構成としては、つぶやき生成部614は、scheduleCallback()等のつぶやき発生処理において、機器をフォローするユーザのスマートフォンのGPS情報を取得し、外出先から家に帰宅途中であることを検知すると、機器管理DB622及び機器操作履歴DB612を参照し、ユーザ帰宅後に実行する確率が高い操作情報(操作ID)を特定し、操作お薦めつぶやきを生成し、つぶやきDB619に登録する。
【0165】
なお、操作お薦めつぶやきが生成されたにもかかわらず、ユーザが閲覧したタイミングで、既にリモコン等でお薦めされる機器操作が実行されている状態になっている場合には、そのままユーザに対して操作お薦めつぶやきを提示しては、混乱を与えてしまう可能性があるので、下記のように対応してもよい。
【0166】
(1)該当の操作お薦めつぶやきがユーザによって閲覧されていない状態であり、該当の操作が既に実行されている状態である場合には、該当のつぶやきを破棄する、としてもよい。具体的には、つぶやき提示部620は、ユーザからの閲覧要求を受け付け、新着のつぶやきをつぶやきDBから取得した段階で、取得した新着のつぶやきが操作お薦めつぶやきである場合であって、機器操作履歴DB612を参照することで、該当操作が既に実行されている状態であることがわかる場合には、該当操作お薦めつぶやきをつぶやきDBから削除するとしてもよい。
【0167】
(2)該当の操作お薦めつぶやきがユーザによって閲覧されていない状態であり、該当の操作が既に実行されている状態である場合には、該当のつぶやきの表示を変更するとしてもよい。具体的には、つぶやき提示部620は、ユーザからの閲覧要求を受け付け、新着のつぶやきをつぶやきDBから取得した段階で、取得した新着のつぶやきが操作お薦めつぶやきである場合であって、機器操作履歴DB612を参照することで、該当操作が既に実行されている状態であることがわかる場合には、該当操作お薦めつぶやきの表示を通常とは異なる形で提示する。なお、つぶやきの表示を変更する方法には、例えば、
図27の(a)に示されるように、該当のつぶやきをグレーアウトする方法がある。
【0168】
(3)該当の操作お薦めつぶやきがユーザによって閲覧されていない状態であり、該当の操作が既に実行されている状態である場合には、該当のつぶやきに、事後フォローする形で、別のつぶやきを返信してもよい。
図27の(b)の例では、「暖房つけますか?」という操作お薦めつぶやきに対して、「先ほど、リモコンで暖房がつきました。」とフォローの返信を行っている。具体的には、つぶやき提示部620は、ユーザからの閲覧要求を受け付け、新着のつぶやきをつぶやきDBから取得した段階で、取得した新着のつぶやきが操作お薦めつぶやきである場合であって、機器操作履歴DB612を参照することで、該当操作が既に実行されている状態である場合には、つぶやき生成部614にイベント通知を行う。つぶやき生成部614は、該当の操作おすすめつぶやきに対して、返信つぶやきを生成し、つぶやきDBに登録を行う。
【0169】
上記のように構成することにより、操作お薦めつぶやきが生成されたにもかかわらず、ユーザが閲覧したタイミングで、既にリモコン等でお薦めされる機器操作が実行されていた状態になっている場合においても、ユーザへの混乱を防ぐことが可能となる。なお、上記(1)〜(3)の対応は、ユーザが該当のつぶやきを閲覧していない状態であり、該当の操作が既に実行されている状態である場合だけでなく、例えば、「操作お薦めつぶやき」から、ある一定時間を経過している場合に発生させてもよい。この場合には、「操作お薦めつぶやき」に対して、「有効期間」のパラメータを設けておき、つぶやきDBに登録しておく。つぶやき提示部620は、ユーザが閲覧するタイミングで、該当有効期間を過ぎている場合には、上記(1)〜(3)の対応を行うように構成することで実現できる。
【0170】
なお、ユーザによる閲覧頻度が低いほど、操作お薦めつぶやきの作成頻度をより低くしてもよい。閲覧頻度が低いユーザは、有効期間内に操作お薦めつぶやきを閲覧する可能性が低いためである。
【0171】
なお、操作お薦めつぶやきにおいては、ユーザが返答することで、機器の操作を実現するとしたが、ユーザがフォローする機器に対してつぶやきを行うことで、操作を直接お願いしてもよい。この場合には、つぶやき提示部620は、機器へのユーザによるつぶやきを解析し、該当機器のリクエストパラメータ定義からリクエストIDを特定し、該当機器IDと該当リクエストIDとを機器操作制御部1801に伝送する。その後、つぶやき提示部620は、つぶやき生成部614にイベント通知を行い、つぶやき生成部614はイベント通知に対応して、返答のつぶやきを生成し、つぶやきDBに登録する。このように、機器に対して、操作を依頼するつぶやきを、「操作依頼つぶやき」と定義する。操作依頼つぶやきのユーザインターフェースのイメージを
図25に示す。このように構成することで、ユーザは、つぶやきのI/Fによって、簡単に機器の操作を制御することが可能である。
【0172】
なお、機器によるつぶやきにおいて、ユーザに飽きさせない多様のバリエーションのつぶやきをユーザに提供するために、機器に対して、人間的な性格をパラメータとして設定できるようにしてもよい。具体的には、
図22のようにユーザ・機器管理DBが構成され、各エントリに対して、性別、血液型、出身地、結婚の有無、年令、趣味、職業、資格、有効度及び情緒といったパラメータが設定される。各パラメータは、機器のプロフィール等から自動で設定されてもよく、機器を所有するユーザが適宜GUI等で変更できるようにしてもよい。
【0173】
つぶやき生成部614は、該当機器によるつぶやきを発生させる場合には、これらのパラメータを参照してつぶやきの内容(コメント)を変更する。下記にその変更内容の例を記載する。
【0174】
つぶやき生成部614は、「性別」が男であれば男言葉(「今日も元気だぜ!」)、女であれば女言葉(「今日も元気ですわ!」)になるようにコメントを変更する。
【0175】
つぶやき生成部614は、「血液型」がA型であれば神経質、O型であれば大雑把、というような性質に基づいてコメントを変更する。
【0176】
つぶやき生成部614は、「出身値」に応じて、当該地方の方言をコメントに適用する。出身地が埼玉であれば標準語、大阪であれば関西弁というようにコメントを変更する。なお、出身値のパラメータは、実際の機器の製造場所が設定されるようにしてもよい。その場合、つぶやき生成部614は、機器管理DB622の属性情報を取得して設定すればよい。
【0177】
つぶやき生成部614は、「結婚」に、未婚若しくは既婚の別、又は、どのパートナーと結婚しているかを設定してもよい。結婚しているパートナー同士で仲良く会話がなされたり、夫婦喧嘩が行われたりしてもよい。
【0178】
つぶやき生成部614は、「年齢」が低い場合は子供の話し方、高い場合は大人の話し方というようにコメントを変更する。なお、年齢のパラメータは、実際の機器の購入時又は製造時からの現在時刻までの年数が設定されるようにしてもよい。その場合、つぶやき生成部614は、機器管理DB622の属性情報を取得して設定すればよい。
【0179】
つぶやき生成部614は、「趣味」又は「資格」に応じて、趣味又は資格に関する内容の情報をWebの検索等によって取得して、その情報に基づいてコメントを変更する。
【0180】
つぶやき生成部614は、「友好度」に応じてコメントの口調を変更してもよい。ここで、「友好度」は、仲のよさを示す。つぶやき生成部614は、「友好度」が高ければ、ため口の口調を用い、そうでなければ丁寧語の口調を用いるとすると、ユーザとの間でより人間に近いコミュニケーションを実現できる。「友好度」は、該当機器をフォローするユーザごとに別々に設定できるようにしても良い。この場合、語りかけるユーザの友好度によって話し方や中身をかえてもよく、機器に対する「操作依頼つぶやき」においては、友好度に応じて、操作を実行する確率を変更してもよい。つまり、友好度の高いユーザからのお願いは素直に実行するが、友好度の低いユーザからのお願いは断るなどしてもよい。
【0181】
つぶやき生成部614は、「情緒」に応じてコメント内容を変更してもよい。「情緒」は、怒りっぽい、又は、泣きっぽいなどの人間の感情部分の特徴を示す。
【0182】
以上のように構成することで、つぶやき生成部614は、多様なつぶやきのバリエーションをユーザに提供することが可能となる。
【0183】
なお、ユーザと機器との関係として、「家族関係」又は「友人関係」が設定できるようにしてもよい。つまり、ユーザは、機器に対して「息子」、「娘」、「夫」、「奥さん」、「いとこ」、「ボーイフレンド」、「ガールフレンド」又は「親友」といった属性を設定できるようにしてもよい。これら属性に基づきコメントにおける言葉遣い等を変更すれば、ユーザと機器との間で、より人間的なコミュニケーションを実現できる。例えば、「ガールフレンド」と設定された機器からは、「なんか疲れちゃった〜(はーと)」など甘えた言葉のつぶやきが生成されるとしてもよい。なお、これらの属性に基づき、例えば、ソーシャルグラフ又は家系図で、ユーザと機器群との関係をGUIとして表示してもよい。
【0184】
なお、「友好度」は、機器とユーザとの間以外にも、機器同士で設定可能としてもよい。その場合には、友好度の高い機器同士が勝手におしゃべり(返信しあう)をするようにつぶやきを生成してもよい。反対に友好度の低い機器同士は喧嘩をするようにつぶやきを生成してもよい。
【0185】
なお、「友好度」は、機器とユーザ間以外にも、機器と機器同士でも設定可能としてもよく、その場合には、友好度の高い機器同士は「いいね」をお互いに発生させる確率を高いようにするとしてもよい。
【0186】
なお、機器同士の友好度の値は、同一カテゴリの機器同士において高いと構成してもよい。例えば、電子レンジと冷蔵庫とは共に食材を扱うので仲がよい、又は、テレビとレコーダとは共に映像を扱うので仲がよい、などである。このようにすれば、ユーザは、直感的に機器の仲のよさを理解することができる。
【0187】
なお、機器同士の友好度の値は、使用時間帯が同じ機器同士において高いと構成してもよい。例えば、電子レンジと冷蔵庫とは同時に利用する可能性が高いので仲がよい、又は、テレビとレコーダとは同時に利用する可能性が高いので仲がよい、などである。このようにすれば、ユーザは直感的に機器の仲のよさを理解することができる。
【0188】
なお、ユーザの注意を引くために、機器が発生するつぶやきは、過剰な言い方であってもよい。例えば、加湿器が「水がなくなりそうで、死にそう」といえば、ユーザをどきりとさせ、ユーザの注意を引くことができる。なお、機器によるつぶやきをより人間的にするために、低い確率で、真実とは異なること、つまり嘘をつくことをしてもよい。このことを、エイプリルフール(4月1日)に行えば、ユーザにとって楽しいユーモアとなり得る。
【0189】
なお、ユーザ・機器管理DB617に「熟練度」を設けてもよい。熟練度は、「操作お薦めつぶやき」に対する操作依頼の処理実行の成功確率を示す。熟練度が低い場合は、時々、操作依頼を行っても機器は処理を失敗するように構成し、熟練度が上がることで、成功確率を上げるとしてもよい。このように構成すれば、熟練度をあげる育成ゲームのような楽しさを、ユーザに提供することができる。
【0190】
なお、「操作依頼つぶやき」の変形例として、機器を特定せずに、あるお願いをしたら、そのお願いを、機器が手を挙げて自動で実行するように構成してもよい。例えば、
図26の(a)のように、ユーザが「室温を上げて」とお願いすると、エアコン、ファンヒーター又は床暖房が手を上げて、操作を実行する。
【0191】
具体的には、つぶやき提示部620は、ユーザの操作依頼つぶやきを解析し、対応可能な機器IDを特定する。その後、1つまたは複数の機器IDにおけるリクエストパラメータ定義から、リクエストIDを特定し、該当機器IDと該当リクエストIDとを機器操作制御部1801に伝送する。その後、つぶやき提示部620は、つぶやき生成部614にイベント通知を行う。つぶやき生成部614はイベント通知に対応して、該当機器による返答のつぶやきを生成し、つぶやきDBに登録する。このように構成することで、ユーザは機器を特定せずに、簡単に自身のお願いを機器に実行させることが可能となる。
【0192】
なお、
図26の(b)のように、お願いをした後に、すぐに実行せずに、操作を実行するかを再度ユーザに確認するように構成してもよい。このように構成すれば、ユーザの意図しない機器が操作を実行してしまうことを防ぐことができる。
【0193】
なお、ユーザが発生するつぶやきに対して、ユーザがフォローする機器群から、ユーザがして欲しそうな操作を類推して、「操作おすすめつぶやき」を生成してもよい。例えば、ユーザが「これから帰るなう」とつぶやきを発声させた場合に、ユーザがフォローするエアコンから「暖房つける?」、照明から「あかりつけとく?」といったつぶやきが生成されるようにしてもよい。このように構成すれば、ユーザは難しい制御なしに、簡単に機器操作を実行できる。具体的には、つぶやき生成部614は、scheduleCallback()等のつぶやき発生処理において、機器がフォローされるユーザのつぶやきを取得し、その内容を解析してユーザの現在の行動を特定し、その行動において、必要とされる機器の操作を、機器操作履歴DBを参照して特定し、操作お薦めつぶやきを生成し、つぶやきDBに登録する。
【0194】
なお、上記のようなユーザのつぶやきの代わりに、ユーザの位置情報を含む情報を利用して上記と同様の制御をおこなうこともできる。ユーザの位置情報は、GPS(Global Positioning System)などにより取得できる。なお、ユーザの位置情報は、ユーザの行動履歴情報の一例である。
【0195】
なお、機器が生成するつぶやきにおいては、ユーザがフォローする他の機器と内容が重複しないように、ユーザがフォローする機器群において、つぶやきの内容を調整するように構成してもよい。
図28の(a)の例では、ユーザがフォローする機器が全て「おはよう」という挨拶をつぶやいているが、ユーザとしては、すべての機器が同じ内容をつぶやいては面白みに欠ける。そこで、
図28の(b)に示すように、機器が生成するつぶやきの内容が異なるようにする。これは、つぶやき生成部614におけるつぶやき発生処理において、フォローされるユーザが保有する機器のつぶやきの最新の内容を参照し、重複しないようにつぶやきを生成することで実現できる。
【0196】
なお、本実施の形態においてはユーザが使用する機器によるつぶやきの発生方法を記載したが、現在保有していない機器によるつぶやきを実現してもよい。例えば、インターネット等で製品の購入予約を行った段階で、該当製品がつぶやきを生成するように構成してもよい。「もう少しであなたのおうちにいくよ!」というように、宅配の状況のつぶやきを行ってもよい。これは、インターネット等で製品の購入予約を行った段階で、機器管理DB622と、ユーザ・機器管理DB617とに機器が登録され、つぶやき生成部614のつぶやき発生方法を適切に定義されることで、実現可能である。
【0197】
なお、機器が故障して使えなくなった場合に、機器に対して感情移入したユーザがさびしい思いをすることを回避するために、故障した機器のユーザID(ユーザ・機器管理DB617で管理されるID)に対応するエントリの機器IDを、新しく購入した機器の機器IDに変更できるようにしてもよい。このように構成すれば、これまでの機器のつぶやきが引き継がれることになるため、ユーザはさびしい思いをすることを回避できる。
【0198】
なお、つぶやきDBの属性として、当該つぶやきを閲覧可能なユーザを指定するプライバシー属性が定義されていてもよい。この属性が設定されている場合には、機器が生成するつぶやきは指定されるユーザ以外は閲覧できないとしてもよい。例えば、体重計のつぶやきについては、ユーザの体重など、他のユーザに見られたくないつぶやき情報にはプライバシー属性が設定され、該当ユーザのみが閲覧できるようになっており、体重計の使い方等のつぶやきにはプライバシー属性が設定されない。このように構成すれば、機器のつぶやきに対して、柔軟なプライバシー設定が可能となる。
【0199】
なお、機器が生成するつぶやきのバリエーションとしては、他に以下のようなものがある。
【0200】
(1)機器に関連するニュースをインターネットで検索をして、その内容(URLやTwitterのつぶやき)等を含めた内容をつぶやく。例えば、冷蔵庫が「冷蔵庫の中身の整理整頓方法を教えます!(http://xxx.../)」といった機器のノウハウ情報をつぶやく。
【0201】
(2)機器が写真を撮影してアップロードし、そのリンク先をつぶやきに含める。例えば、冷蔵庫が「今の冷蔵庫の中身です(http://xxx.../..jpg)」とつぶやく。
【0202】
(3)ユーザが保有する機器の種類や使用履歴に応じて、家電がCMをつぶやく。例えば、電子レンジを保持しないユーザに対して、冷蔵庫が「M社から最新の電子レンジでました(http://xxx..../)」とつぶやく。
【0203】
(4)ユーザが保有する機器の使用履歴に応じて、家電が「使っていない機能」をつぶやく。例えば、電子レンジの「ミルクボタン」を押したことがないユーザに対して、電子レンジが「電子レンジのミルクボタンを押すことで、劇旨ホットミルクが作れますよ。」とつぶやく。
【0204】
上記の実現は、つぶやき生成部614におけるつぶやき発生方法を前述の通りプログラムで定義することで実現できる。
【0205】
図29は、実施の形態のおけるコンテンツ提示装置の構成の他の例を示すブロック図である。
【0206】
図29に示されるように、コンテンツ提示装置2901は、機器のユーザの行動履歴情報を取得する取得部2911と、機器からユーザへの対話のためのコンテンツを生成する頻度を行動履歴情報に基づき決定し、決定した頻度でコンテンツを生成するコンテンツ生成部2912と、対話用コンテンツを配信するためのサーバに、生成されたコンテンツを対話用コンテンツとして配信させることで、コンテンツをユーザに提示する提示部2913とを備える。
【0207】
図30は、実施の形態のおけるコンテンツ提示装置におけるコンテンツ処理方法の他の例を示すフローチャートである。
【0208】
図30に示されるように、コンテンツ提示方法は、機器のユーザの行動履歴情報を取得する取得ステップ(ステップS3001)と、機器からユーザへの対話のためのコンテンツを生成する頻度を行動履歴情報に基づき決定し、決定した頻度でコンテンツを生成するコンテンツ生成ステップ(ステップS3002)と、対話用コンテンツを配信するためのサーバに、生成されたコンテンツを対話用コンテンツとして配信させることで、コンテンツをユーザに提示する提示ステップ(ステップS3003)とを含む。
【0209】
以上のように、本実施の形態のコンテンツ提示方法によれば、機器に関するコンテンツの種別と頻度とが、ユーザの行動履歴情報に基づいて決定される。具体的には、ユーザの行動履歴から判定される、ユーザによるコンテンツの閲覧可能性に応じて、当該コンテンツの種別とその生成頻度とが決定される。よって、本発明に係るコンテンツ提示方法により、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0210】
また、機器に関するコンテンツの種別が、ユーザの行動履歴情報に基づいて決定される。具体的には、ユーザの行動履歴から判定される、ユーザによるコンテンツの閲覧可能性に応じて、当該コンテンツの種別が決定される。よって、本発明に係るコンテンツ提示方法により、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0211】
また、コンテンツの閲覧要求の頻度が低いユーザに対して、より少ない数のコンテンツが提示される。これにより、ユーザが一度に閲覧すべきコンテンツが当該ユーザの閲覧頻度に応じて削減され、ユーザが一度に閲覧すべきコンテンツの数が閲覧頻度によらずおおむね一定になるようにすることができる。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0212】
また、ユーザによるコンテンツの閲覧要求の頻度が低い時間帯(第一時間帯)において、より少ない数のコンテンツが提示される。これにより、ユーザが閲覧する可能性が低い時間帯のコンテンツの生成が抑制され、ユーザが閲覧する可能性が高い時間帯のコンテンツの生成が維持される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0213】
また、コンテンツの閲覧要求の頻度が低いユーザに対して、ユーザに問いかける旨のコンテンツを生成することが抑制される。仮に、コンテンツの閲覧要求の頻度が低いユーザに、問いかける旨のコンテンツを提示したとしても、当該ユーザが当該コンテンツを閲覧するのは比較的長時間経過後と考えられ、そのときに問いかけの回答が得られても適切な機器制御ができない可能性が高いためである。このように、ユーザによりコンテンツが閲覧された結果、適切な制御が行われないことが想定される場合に、当該コンテンツの生成が抑制される。
【0214】
また、これによれば、機器に対する操作の頻度が低いユーザに対して、より少ない数のコンテンツが提示される。これにより、ユーザが一度に閲覧すべきコンテンツが当該ユーザの操作の頻度に応じて削減される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0215】
また、過去にユーザが機器を操作したことがある時間帯(第二時間帯)でない時間帯に、コンテンツの生成が抑制され、第三時間帯でのコンテンツの生成が維持される。当該ユーザは、将来的にも第三時間帯に機器を制御する可能性が高いと考えられるので、第三時間帯にコンテンツを生成して提示することでユーザの利便性を損なわずに、コンテンツの数を削減することができる。
【0216】
また、機器に対する操作の頻度が低いユーザに対して、ユーザに問いかける旨のコンテンツを生成することが抑制される。これにより、ユーザの利便性を損なわずに、コンテンツの数を削減することができる。
【0217】
また、ユーザが、あらかじめ設定された領域にいない場合に、コンテンツの生成が抑制され、上記領域にユーザがいる場合にはコンテンツの生成が維持される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。
【0218】
上記態様において説明された技術は、例えば、以下のクラウドサービスの類型において実現されうる。しかし、上記態様において説明された技術が実現される類型はこれに限られるものでない。
【0219】
(サービスの類型1:自社データセンタ型)
図2は、サービスの類型1(自社データセンタ型)を示す。本類型は、サービスプロバイダ120がグループ100から情報を取得し、ユーザに対してサービスを提供する類型である。本類型では、サービスプロバイダ120が、データセンタ運営会社の機能を有している。即ち、サービスプロバイダが、ビッグデータの管理をするクラウドサーバ111を保有している。従って、データセンタ運営会社は存在しない。
【0220】
本類型では、サービスプロバイダ120は、データセンタ(クラウドサーバ111)を運営、管理している(203)。また、サービスプロバイダ120は、OS(202)及びアプリケーション(201)を管理する。サービスプロバイダ120は、サービスプロバイダ120が管理するOS(202)及びアプリケーション(201)を用いてサービス提供を行う(204)。
【0221】
(サービスの類型2:IaaS利用型)
図3は、サービスの類型2(IaaS利用型)を示す。ここでIaaSとはインフラストラクチャー・アズ・ア・サービスの略であり、コンピュータシステムを構築および稼動させるための基盤そのものを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。
【0222】
本類型では、データセンタ運営会社がデータセンタ(クラウドサーバ111)を運営、管理している(203)。また、サービスプロバイダ120は、OS(202)及びアプリケーション(201)を管理する。サービスプロバイダ120は、サービスプロバイダ120が管理するOS(202)及びアプリケーション(201)を用いてサービス提供を行う(204)。
【0223】
(サービスの類型3:PaaS利用型)
図4は、サービスの類型3(PaaS利用型)を示す。ここでPaaSとはプラットフォーム・アズ・ア・サービスの略であり、ソフトウェアを構築および稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。
【0224】
本類型では、データセンタ運営会社110は、OS(202)を管理し、データセンタ(クラウドサーバ111)を運営、管理している(203)。また、サービスプロバイダ120は、アプリケーション(201)を管理する。サービスプロバイダ120は、データセンタ運営会社が管理するOS(202)及びサービスプロバイダ120が管理するアプリケーション(201)を用いてサービス提供を行う(204)。
【0225】
(サービスの類型4:SaaS利用型)
図5は、サービスの類型4(SaaS利用型)を示す。ここでSaaSとはソフトウェア・アズ・ア・サービスの略である。例えばデータセンタ(クラウドサーバ)を保有しているプラットフォーム提供者が提供するアプリケーションを、データセンタ(クラウドサーバ)を保有していない会社・個人(利用者)がインターネットなどのネットワーク経由で使用できる機能を有するクラウドサービス提供モデルである。
【0226】
本類型では、データセンタ運営会社110は、アプリケーション(201)を管理し、OS(202)を管理し、データセンタ(クラウドサーバ111)を運営、管理している(203)。また、サービスプロバイダ120は、データセンタ運営会社110が管理するOS(202)及びアプリケーション(201)を用いてサービス提供を行う(204)。
【0227】
以上いずれの類型においても、サービスプロバイダ120がサービス提供行為を行ったものとする。また例えば、サービスプロバイダ若しくはデータセンタ運営会社は、OS、アプリケーション若しくはビックデータのデータベース等を自ら開発してもよいし、また、第三者に外注させてもよい。
【0228】
なお、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、CPUまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態のつぶやき生成・閲覧サーバなどを実現するソフトウェアは、次のようなプログラムである。
【0229】
すなわち、このプログラムは、コンピュータに、ユーザの行動履歴情報を取得する取得ステップと、機器から前記ユーザへの対話のためのコンテンツを生成する頻度を前記行動履歴情報に基づき決定し、決定した前記頻度で前記コンテンツを生成するコンテンツ生成ステップと、生成された前記コンテンツを配信することで、前記コンテンツを前記ユーザに提示する提示ステップとを含むコンテンツ提示方法を実行させる。
【0230】
以上、一つまたは複数の態様に係るコンテンツ提示方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。