WO2014112362A1

WO2014112362A1 - コンテンツ提示方法、及びプログラム

Info

Publication number: WO2014112362A1
Application number: PCT/JP2014/000135
Authority: WO
Inventors: 泰治佐々木; 峰久永田; 康史三浦; 俊治原田
Original assignee: Panasonic Corp
Current assignee: Panasonic Corp
Priority date: 2013-01-18
Filing date: 2014-01-15
Publication date: 2014-07-24
Anticipated expiration: 2015-07-18
Also published as: JPWO2014112362A1; US20150074554A1; JP6308942B2

Abstract

　コンテンツ提示方法は、ユーザの行動履歴情報を取得する取得ステップ（Ｓ３００１）と、機器からユーザへの対話のためのコンテンツを生成する頻度を行動履歴情報に基づき決定し、決定した頻度でコンテンツを生成するコンテンツ生成ステップ（Ｓ３００２）と、生成されたコンテンツを配信することで、コンテンツをユーザに提示する提示ステップ（Ｓ３００３）とを含む。例えば、コンテンツ生成ステップ（Ｓ３００２）では、さらに、生成するコンテンツの種別を行動履歴情報に基づき決定し、決定した種別のコンテンツを生成する。

Description

コンテンツ提示方法、及びプログラム

　本発明は、コンテンツ提示方法、及びプログラムに関する。

　特許文献１は、ソーシャルネットワーク（ＳＮＳ（Ｓｏｃｉａｌ　Ｎｅｔｗｏｒｋｉｎｇ　Ｓｅｒｖｉｃｅ）とも記載する）の原理を機器に適用したネットワーク管理システムを開示する。特許文献１に開示される技術によれば、ユーザとモノとの間、又は、モノ同士の間でＦａｃｅｂｏｏｋの友達関係のような関係が構築され、ユーザと機器との間でＳＮＳライクなコミュニケーションが取られる。

　特許文献２は、車両の走行状態に関する情報に基づいて、投稿すべきつぶやきを生成し、生成したつぶやきをユーザの代わりに自動的に投稿するシステムを開示する。

米国特許出願公開第２０１１／０１６１４７８号明細書特開２０１２－８９６９号公報

　上記のつぶやきのようなコンテンツを機器が生成し投稿する場合、投稿されるコンテンツの数は、人間により投稿されるコンテンツの数より飛躍的に多くなる可能性がある。投稿されるコンテンツの数が多いほど、当該コンテンツを配送する配送サーバの処理負荷がより大きくなる。

　本発明では、ユーザビリティを損なうことなく、配送サーバにおける処理負荷を低減することができるコンテンツ提示方法などを提供する。

　本発明の一態様に係るコンテンツ提示方法は、ユーザの行動履歴情報を取得する取得ステップと、機器から前記ユーザへの対話のためのコンテンツを生成する頻度を前記行動履歴情報に基づき決定し、決定した前記頻度で前記コンテンツを生成するコンテンツ生成ステップと、生成された前記コンテンツを配信することで、前記コンテンツを前記ユーザに提示する提示ステップとを含む。

　なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

　本発明のコンテンツ提示方法は、ユーザビリティを損なうことなく、配送サーバにおける処理負荷を低減することができる。

図１は、実施の形態において提供するサービスの全体像を示す図である。図２は、実施の形態におけるサービスの類型（自社データセンタ型）を示す図である。図３は、実施の形態におけるサービスの類型（ＩａａＳ利用型）を示す図である。図４は、実施の形態におけるサービスの類型（ＰａａＳ利用型）を示す図である。図５は、実施の形態におけるサービスの類型（ＳａａＳ利用型）を示す図である。図６は、実施の形態におけるコンテンツ生成・閲覧システムの構成を示すブロック図である。図７は、実施の形態における機器管理ＤＢのデータ構成の説明図である。図８は、実施の形態における操作履歴ＤＢのデータ構造の説明図である。図９は、実施の形態における操作パラメータ定義の説明図である。図１０は、実施の形態におけるユーザ・機器管理ＤＢのデータ構造の説明図である。図１１は、実施の形態におけるつぶやきＤＢのデータ構造の説明図である。図１２は、実施の形態における閲覧履歴ＤＢのデータ構造の説明図である。図１３は、実施の形態におけるつぶやき発生方法の説明図である。図１４は、実施の形態におけるつぶやき発生頻度のパラメータの説明図である。図１５は、実施の形態におけるつぶやき発生頻度のパラメータを用いてつぶやきの発生頻度を変更するつぶやき発生方法の説明図である。図１６は、実施の形態におけるつぶやき閲覧結果の表示の説明図である。図１７は、実施の形態におけるユーザ・機器管理ＤＢの別例を説明する図である。図１８は、実施の形態におけるつぶやきＤＢのデータ構造の変形例１を示す図である。図１９は、実施の形態におけるコンテンツ生成・閲覧システムの変形例を示すブロック図である。図２０は、リクエストＩＤとリクエストパラメータ定義を説明する図である。図２１Ａは、操作お薦めつぶやきの表示の第一例の説明図である。図２１Ｂは、操作お薦めつぶやきの表示の第二例の説明図である。図２１Ｃは、操作お薦めつぶやきの表示の第三例の説明図である。図２１Ｄは、操作お薦めつぶやきの表示の第四例の説明図である。図２２は、機器に対する人間的な性格づけを実現するためのユーザ・機器管理ＤＢのデータ構造の変形例を説明する図である。図２３は、つぶやき閲覧結果の表示の変形例を説明する図である。図２４は、つぶやきＤＢのデータ構造の変形例３を説明する図である。図２５は、操作依頼つぶやきの表示例１を説明する図である。図２６は、操作依頼つぶやきの表示例２を説明する図である。図２７は、操作お薦めつぶやきの表示の変形例を説明する図である。図２８は、機器群によるつぶやき内容の調整を説明する図である。図２９は、実施の形態のおけるコンテンツ提示装置の構成の他の例を示すブロック図である。図３０は、実施の形態のおけるコンテンツ提示装置におけるコンテンツ処理方法の他の例を示すフローチャートである。

（本発明の基礎となった知見）
　本発明者は、「背景技術」の欄において記載した、コミュニケーション方法に関し、以下の問題が生じることを見出した。

　近年、インターネットに接続可能なテレビやレコーダなどのＡＶ（Ａｕｄｉｏ　Ｖｉｓｕａｌ）家電が増加し、映画やスポーツなどの動画配信サービスが提供されている。また、体重計、活動量計、炊飯器、オーブンレンジ、又は、冷蔵庫などの生活家電と呼ばれる家電機器もインターネットへの接続が進んでいる。これにより、家電機器の操作履歴を含む操作情報、又は、動作履歴を含む動作情報を、インターネットを通じてサーバに送信し、サーバで蓄積・分析することが行われている。また、サーバでの分析結果を利用して、利用者に様々なサービスを提供することも行われている。

　一方で、ユーザ間のコミュニケーションを促進するインターネットサービスとして、Ｆａｃｅｂｏｏｋ、Ｔｗｉｔｔｅｒ又はＬｉｎｅ等のソーシャルネットワークサービスが広く使われている。

　Ｆａｃｅｂｏｏｋは、ユーザがインターネット上で友達関係を構築し、ユーザが投稿する自身の状況等を記したテキスト文章や写真を友人同士で共有し、閲覧又は返信を行うことで、ユーザ同士のコミュニケーションを可能とするサービスである。

　Ｔｗｉｔｔｅｒは、ミニブログとも呼ばれ、自身の状況等を記した短いテキスト文章をサーバに投稿し、サーバに蓄積されるテキスト文章を利用者間で共有することで、利用者に楽しみを提供するコミュニケーションサービスである。

　Ｌｉｎｅは、ユーザ間でリアルタイムに短いメッセージのやりとりを行うことができるコミュニケーションサービスである。

　以降では、このようなコミュニケーションサービスにおいて、ユーザが投稿する自身の状況等を記したテキスト文章又は写真のことを、「つぶやき」と定義する。

　最近では、人であるユーザではなく、機器が現在の状況に基づいてつぶやきを自動的に生成して、人であるユーザが閲覧を行うサービスが検討され始めている。例えば、特許文献１は、ソーシャルネットワークの原理を機器に適用したネットワーク管理システムを開示する。特許文献１に開示される技術によれば、ユーザとモノとの間、又は、モノ同士の間でＦａｃｅｂｏｏｋの友達関係のような関係が構築され、ユーザと機器との間でＳＮＳライクなコミュニケーションが取られる。

　このような機器がつぶやきを自動的に発生させる場合には、大量のつぶやきを記録し迅速な検索を実現するデータベースの構築が課題となる。一般的に人が保有する電子機器は、人の数よりも多く、それらの機器がインターネットに接続される場合に、機器が人と同じくらいの頻度でつぶやきを発生させる場合には、人が発生するつぶやきの数よりも、機器が発生するつぶやきの数は当然多くなり、巨大なデータベースシステムの構築が必要となってしまう。

　つまり、上記のように機器がつぶやきを生成し投稿する場合、投稿されるつぶやきの数は、人間により投稿されるつぶやきの数より飛躍的に多くなる可能性がある。つぶやきの数が多いほど、投稿されるサーバの処理負荷がより大きくなる。

　本発明では、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができるコンテンツ提示方法などを提供する。

　このような問題を解決するために、本発明の一態様に係るコンテンツ提示方法は、ユーザの行動履歴情報を取得する取得ステップと、機器から前記ユーザへの対話のためのコンテンツを生成する頻度を前記行動履歴情報に基づき決定し、決定した前記頻度で前記コンテンツを生成するコンテンツ生成ステップと、生成された前記コンテンツを配信することで、前記コンテンツを前記ユーザに提示する提示ステップとを含む。

　これによれば、機器に関するコンテンツの生成頻度が、ユーザの行動履歴情報に基づいて決定される。具体的には、ユーザの行動履歴から判定される、ユーザによるコンテンツの閲覧可能性に応じて、当該コンテンツの生成頻度が決定される。よって、本発明に係るコンテンツ提示方法により、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　従来技術によれば、コンテンツの種別と生成頻度とは、機器が動作したこと（又は、動作しなかった）ことなどを契機として決定されるが、当該コンテンツを閲覧するユーザの行動履歴情報には無関係である。本発明に係るコンテンツ提示方法では、生成するコンテンツの種別と頻度とをユーザの行動履歴情報を考慮して決定することで、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　例えば、前記コンテンツ生成ステップでは、さらに、生成する前記コンテンツの種別を前記行動履歴情報に基づき決定し、決定した種別の前記コンテンツを生成する。

　これによれば、機器に関するコンテンツの種別が、ユーザの行動履歴情報に基づいて決定される。具体的には、ユーザの行動履歴から判定される、ユーザによるコンテンツの閲覧可能性に応じて、当該コンテンツの種別が決定される。よって、本発明に係るコンテンツ提示方法により、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　例えば、前記提示ステップでは、前記ユーザによる前記コンテンツの閲覧要求を受け付け、受け付けた前記閲覧要求に応じて前記コンテンツを前記ユーザに提示し、前記取得ステップでは、前記提示ステップで受け付けた前記閲覧要求の頻度を含む情報を、前記行動履歴情報として取得し、前記コンテンツ生成ステップでは、前記行動履歴情報における前記閲覧要求の頻度が低いほど、前記コンテンツをより低い頻度で生成し、又は、前記行動履歴情報における前記閲覧要求の頻度が高いほど、前記コンテンツをより高い頻度で生成する。

　これによれば、コンテンツの閲覧要求の頻度が低いユーザに対して、より少ない数のコンテンツが提示される。これにより、ユーザが一度に閲覧すべきコンテンツが当該ユーザの閲覧頻度に応じて削減され、ユーザが一度に閲覧すべきコンテンツの数が閲覧頻度によらずおおむね一定になるようにすることができる。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　例えば、前記取得ステップでは、前記提示ステップで受け付けた前記閲覧要求の頻度が第一閾値未満である第一時間帯を特定する情報を、前記行動履歴情報として取得し、前記コンテンツ生成ステップでは、前記行動履歴情報から特定される前記第一時間帯において、前記第一時間帯を含まない時間帯における前記コンテンツの生成頻度より低い頻度で前記コンテンツを生成する。

　これによれば、ユーザによるコンテンツの閲覧要求の頻度が低い時間帯（第一時間帯）において、より少ない数のコンテンツが提示される。これにより、ユーザが閲覧する可能性が低い時間帯のコンテンツの生成が抑制され、ユーザが閲覧する可能性が高い時間帯のコンテンツの生成が維持される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　例えば、前記コンテンツの種別は、前記ユーザに問いかける旨を含むコンテンツを示す第一種別と、前記第一種別を除く第二種別とを含み、前記コンテンツ生成ステップでは、前記行動履歴情報における前記閲覧要求の頻度が低いほど、より低い頻度で前記第二種別のコンテンツを生成し、又は、前記行動履歴情報における前記閲覧要求の頻度が高いほど、より高い頻度で前記第二種別のコンテンツを生成する。

　これによれば、コンテンツの閲覧要求の頻度が低いユーザに対して、ユーザに問いかける旨のコンテンツを生成することが抑制される。仮に、コンテンツの閲覧要求の頻度が低いユーザに、問いかける旨のコンテンツを提示したとしても、当該ユーザが当該コンテンツを閲覧するのは比較的長時間経過後と考えられ、そのときに問いかけの回答が得られても適切な機器制御ができない可能性が高いためである。このように、ユーザによりコンテンツが閲覧された結果、適切な制御が行われないことが想定される場合に、当該コンテンツの生成が抑制される。

　これによれば、機器に対する操作の頻度が低いユーザに対して、より少ない数のコンテンツが提示される。これにより、ユーザが一度に閲覧すべきコンテンツが当該ユーザの操作の頻度に応じて削減される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　例えば、前記取得ステップでは、前記ユーザによる前記機器に対する操作の履歴に基づいて定められる情報であって、前記ユーザによる前記操作の頻度が第二閾値未満である第二時間帯を特定する情報を、前記行動履歴情報として取得し、前記コンテンツ生成ステップでは、前記行動履歴情報から特定される前記第二時間帯において、前記第二時間帯を含まない時間帯における前記コンテンツの生成頻度より低い頻度で前記コンテンツを生成する。

　これによれば、過去にユーザが機器を操作したことがある時間帯（第二時間帯）でない時間帯に、コンテンツの生成が抑制され、第三時間帯でのコンテンツの生成が維持される。当該ユーザは、将来的にも第三時間帯に機器を制御する可能性が高いと考えられるので、第三時間帯にコンテンツを生成して提示することでユーザの利便性を損なわずに、コンテンツの数を削減することができる。

　例えば、前記コンテンツの種別は、前記ユーザに問いかける旨を含むコンテンツを示す第一種別と、前記第一種別を除く第二種別とを含み、前記コンテンツ生成ステップでは、前記行動履歴情報における前記操作の頻度が低いほど、より低い頻度で前記第一種別のコンテンツを生成し、又は、前記行動履歴情報における前記操作の頻度が高いほど、より高い頻度で前記第一種別のコンテンツを生成する。

　これによれば、機器に対する操作の頻度が低いユーザに対して、ユーザに問いかける旨のコンテンツを生成することが抑制される。これにより、ユーザの利便性を損なわずに、コンテンツの数を削減することができる。

　これによれば、ユーザが、あらかじめ設定された領域にいない場合に、コンテンツの生成が抑制され、上記領域にユーザがいる場合にはコンテンツの生成が維持される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　また、本発明の一態様に係るプログラムは、上記に記載のコンテンツ提示方法をコンピュータに実行させるためのプログラムである。

　これによれば、上記のコンテンツ提示方法と同様の効果を奏する。

　なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。

　以下、実施の形態について、図面を参照しながら具体的に説明する。

　なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

　（提供するサービスの全体像）
　図１の（Ａ）には、以下の実施の形態にかかるサービスの全体像が示されている。

　グループ１００は、例えば企業、団体、家庭等であり、その規模を問わない。グループ１００には、複数の機器１０１である機器Ａ、機器Ｂおよびホームゲートウェイ１０２が存在する。複数の機器１０１には、インターネットと接続可能な機器（例えば、スマートフォン、ＰＣ、ＴＶ等）もあれば、それ自身ではインターネットと接続不可能な機器（例えば、照明、洗濯機、冷蔵庫等）も存在する。それ自身ではインターネットと接続不可能な機器であっても、ホームゲートウェイ１０２を介してインターネットと接続可能となる機器が存在してもよい。またグループ１００には複数の機器１０１を使用するユーザ１０が存在する。

　データセンタ運営会社１１０には、クラウドサーバ１１１が存在する。クラウドサーバ１１１とはインターネットを介して様々な機器と連携する仮想化サーバである。主に通常のデータベース管理ツール等で扱うことが困難な巨大なデータ（ビッグデータ）等を管理する。データセンタ運営会社１１０は、データ管理やクラウドサーバ１１１の管理、それらを行うデータセンタの運営等を行っている。データセンタ運営会社１１０が行っている役務については詳細を後述する。ここで、データセンタ運営会社１１０は、データ管理やクラウドサーバ１１１の運営等のみを行っている会社に限らない。例えば複数の機器１０１のうちの一つの機器を開発・製造している機器メーカが、併せてデータ管理やクラウドサーバ１１１の管理等を行っている場合は、機器メーカがデータセンタ運営会社１１０に該当する（図１の（Ｂ））。また、データセンタ運営会社１１０は一つの会社に限らない。例えば機器メーカ及び他の管理会社が共同もしくは分担してデータ管理やクラウドサーバ１１１の運営を行っている場合は、両者もしくはいずれか一方がデータセンタ運営会社１１０に該当するものとする（図１の（Ｃ））。

　サービスプロバイダ１２０は、サーバ１２１を保有している。ここで言うサーバ１２１とは、その規模は問わず例えば、個人用ＰＣ内のメモリ等も含む。また、サービスプロバイダがサーバ１２１を保有していない場合もある。

　なお、上記サービスにおいてホームゲートウェイ１０２は必須ではない。例えば、クラウドサーバ１１１が全てのデータ管理を行っている場合等は、ホームゲートウェイ１０２は不要となる。また、家庭内のあらゆる機器がインターネットに接続されている場合のように、それ自身ではインターネットと接続不可能な機器は存在しない場合もある。

　次に、上記サービスにおける機器のログ情報（操作履歴情報および動作履歴情報）の流れを説明する。

　まず、グループ１００の機器Ａ又は機器Ｂは、各ログ情報をデータセンタ１１０のクラウドサーバ１１１に送信する。クラウドサーバ１１１は機器Ａ又は機器Ｂのログ情報を集積する（図１の（ａ））。ここで、ログ情報とは複数の機器１０１の、例えば運転状況や動作日時等を示す情報である。例えば、テレビの視聴履歴やレコーダの録画予約情報、洗濯機の運転日時・洗濯物の量、冷蔵庫の開閉日時・開閉回数などであるが、これらのものに限らずあらゆる機器から取得が可能なすべての情報をいう。ログ情報は、インターネットを介して複数の機器１０１自体から直接クラウドサーバ１１１に提供される場合もある。また複数の機器１０１から一旦ホームゲートウェイ１０２にログ情報が集積され、ホームゲートウェイ１０２からクラウドサーバ１１１に提供されてもよい。

　次に、データセンタ運営会社１１０のクラウドサーバ１１１は、集積したログ情報を一定の単位でサービスプロバイダ１２０に提供する。ここで、データセンタ運営会社が集積した情報を整理してサービスプロバイダ１２０に提供することの出来る単位でもよいし、サービスプロバイダ１２０が要求した単位でもよい。一定の単位と記載したが一定でなくてもよく、状況に応じて提供する情報量が変化する場合もある。前記ログ情報は、必要に応じてサービスプロバイダ１２０が保有するサーバ１２１に保存される（図１の（ｂ））。そして、サービスプロバイダ１２０は、ログ情報をユーザに提供するサービスに適合する情報に整理し、ユーザに提供する。提供するユーザは、複数の機器１０１を使用するユーザ１０でもよいし、外部のユーザ２０でもよい。ユーザへのサービス提供方法は、例えば、サービスプロバイダから直接ユーザへ提供されてもよい（図１の（ｂ）及び（ｅ））。また、ユーザへのサービス提供方法は、例えば、データセンタ運営会社１１０のクラウドサーバ１１１を再度経由して、ユーザに提供されてもよい（図１の（ｃ）及び（ｄ））。また、データセンタ運営会社１１０のクラウドサーバ１１１がログ情報をユーザに提供するサービスに適合する情報に整理し、サービスプロバイダ１２０に提供してもよい。

　なお、ユーザ１０とユーザ２０とは、別でも同一でもよい。

　（実施の形態）
　本実施の形態において、ユーザビリティを損なうことなく、配送サーバにおける処理負荷を低減することができるコンテンツ提示装置、コンテンツ提示方法、及び、システムについて説明する。なお、コンテンツの例として、ユーザが投稿する自身の状況等を記したテキスト文章又は写真である「つぶやき」を用いて説明するが、本発明はこれに限定されない。

　図６は、本実施の形態におけるつぶやき生成・閲覧システムの構成を示すブロック図である。なお、つぶやき生成・閲覧システムは、コンテンツ提示システムの一例である。

　図６に示すように、つぶやき生成・閲覧システムは、つぶやき生成・閲覧サーバ６０１と、機器６０２と、つぶやき閲覧機器６０３とを備える。つぶやき生成・閲覧サーバ６０１のブロックの一部もしくは全ては、データセンタ運営会社のクラウドサーバもしくはサービスプロバイダのサーバのどちらかに属す。

　機器６０２は、グループ１００に所属する複数の機器１０１のうちの１つである。

　機器６０２は、通信部６３１を備える。

　通信部６３１は、機器６０２に対して行われた操作を、機器操作履歴情報としてつぶやき生成・閲覧サーバ６０１に伝送する。機器操作履歴とは、例えば、電子レンジのボタンのうち利用者が押下したボタンのコード番号、利用者が選択した選択機能に対応した機能識別子、又は、電子レンジのあたため時間などである。機器６０２には、機器管理ＤＢ６２２で管理されるユニークな機器ＩＤが割り振られており、通信部６３１は、機器操作履歴を、機器ＩＤと共に送信する。なお、図６において、機器６０２が１つだけ示されているが、複数の機器６０２がつぶやき生成・閲覧サーバ６０１に接続された場合、つぶやき生成・閲覧サーバ６０１は、複数台の機器に対応できる。機器操作履歴情報は、行動履歴情報の一例である。

　つぶやき閲覧機器６０３は、通信部６３１と、情報入出力部６３２とを備える。

　通信部６３１は、ネットワークに接続し、通信データを伝送する。つぶやき閲覧機器６０３は、通信部６３１を介して、つぶやき生成・閲覧サーバ６０１からつぶやきを取得する。

　情報入出力部６３２は、情報の入力を受け付け、また、情報を出力する。情報入出力部６３２は、通信部６３１が取得したつぶやきを出力する。情報入出力部６３２は、具体的には、情報の出力を行うためのディスプレイ、又は、情報の入力を受け付けるキーボード又はタッチパネルなどである。つぶやき閲覧機器６０３は、具体的には、ＰＣ又はスマートフォン等のデバイスである。

　つぶやき生成・閲覧サーバ６０１は、つぶやき生成情報設定部６１１と、機器操作履歴ＤＢ６１２と、機器操作履歴収集部６１３と、つぶやき生成部６１４と、つぶやき頻度管理ＤＢ６１５と、つぶやき頻度算出部６１６と、ユーザ・機器管理ＤＢ６１７と、閲覧履歴ＤＢ６１８と、つぶやきＤＢ６１９と、つぶやき提示部６２０と、機器管理部６２１と、機器管理ＤＢ６２２とを備える。なお、つぶやきＤＢ６１９は、つぶやき生成・閲覧サーバ６０１が備えるのではなく、ネットワークで接続された外部の装置が備えていてもよい。その場合には、つぶやきＤＢ６１９との通信を行う際には、適切な通信インタフェースを介した通信が行われる。

　機器管理部６２１は、つぶやき生成・閲覧サーバ６０１に接続される機器６０２の機器ＩＤ等の機器のプロフィール情報を設定する。機器管理部６２１は、設定した情報を、機器管理ＤＢ６２２に記録する。

　図７は、本実施の形態における機器管理ＤＢのデータ構成の説明図である。

　図７の（ａ）は、機器管理ＤＢ６２２に記録される機器のプロフィール情報の例を示している。

　「機器ＩＤ」は、前述した通り機器を判別するためのＩＤであり、機器管理ＤＢ内でユニークになるように設定される。

　「メーカ」は、機器を製造するメーカの名称である。

　「品番」は、メーカが設定する機器を区別するための番号である。

　「製品分類ＩＤ」は、該当製品の内容を定義するＩＤである。製品分類ＩＤは、具体的には、図７の（ｂ）に示すようなテーブル情報になっており、例えば、製品分類ＩＤの００００１は冷蔵庫に、００００２は洗濯機に、００００３はエアコンに、００００４はテレビに、００００５は電子レンジにと、それぞれ対応づけられている。この製品分類ＩＤを参照することにより、図７の（ａ）における機器ＩＤが００００１である製品は、製品分類ＩＤが０００１なので冷蔵庫であることがわかる。同様に、機器ＩＤが００００２の製品は、製品分類ＩＤが０００５なので電子レンジであり、機器ＩＤが００００３の製品は、製品分類ＩＤが０００３なのでエアコンであることがそれぞれわかる。

　「製造年月日」は、当該機器が製造された日付である。「製造国」は、当該機器が製造された国である。

　「機器管理ＵＲＬ」は、当該機器のその他のプロフィール情報を含む、より詳細な情報を格納するＵＲＬである。該当ＵＲＬへのアクセスにより、上記のようなより詳細な情報が取得される。

　「認証パスワード」は、該当機器のつぶやきを閲覧するためのアクセス権を取得するためのパスワードである。

　図７の（ａ）に示したプロフィール情報の属性以外にも、例えば、当該機器の寸法、又は質量等、他の属性に関する情報が格納されていてもよい。

　機器管理部６２１は、機器６０２を製造するメーカが機器６０２を製造したタイミングで、上記のプロフィール情報を設定してもよいし、機器６０２がつぶやき生成・閲覧サーバ６０１に接続されたタイミングで、機器のメーカのサーバ等に自動で問い合わせを行い、設定されるようにしてもよい。

　なお、機器管理ＤＢ６２２で管理される機器ＩＤは、機器６０２に伝送され、機器６０２のメモリ又はＨＤＤ等の記憶装置に保存される。前述の通り機器６０２がつぶやき生成・閲覧サーバ６０１への接続を行う場合には、上記のように保存された機器ＩＤを接続と同時に通信することで、つぶやき生成・閲覧サーバ６０１による機器６０２の判別が行われることになる。

　図６に戻り、機器操作履歴収集部６１３は、機器６０２から機器操作履歴情報を取得し、機器６０２に付与される機器ＩＤと関連付けて、機器操作履歴ＤＢ６１２に、機器操作履歴を蓄積する。

　図８は、実施の形態における操作履歴ＤＢのデータ構造の説明図である。

　図８は機器操作履歴ＤＢ６１２に蓄積される機器操作履歴情報の例を示している。機器操作履歴情報は、履歴ＩＤと、機器ＩＤと、操作時刻と、操作ＩＤと、操作情報とが１つの単位として記録される。

　「履歴ＩＤ」は、機器操作履歴を管理するための番号であり、データベース内でユニークになるように付与される。

　「操作時刻」は、機器に対して操作が実行された時刻を示す。

　「操作ＩＤ」は、機器に対して実行された操作内容を示すＩＤである。

　「操作情報」は、操作ＩＤによって示される操作対象や状態を示すデータである。

　「操作ＩＤ」と「操作情報」とは、あらかじめ製品分類ＩＤごとに仕様が定義されている。これを操作パラメータ定義と呼ぶ。機器操作履歴収集部６１３は、機器管理ＤＢ６２２を参照し、機器ＩＤに対応する製品分類ＩＤを取得し、以下に示す操作パラメータ定義をさらに参照することで、機器操作履歴情報に蓄積される操作の内容を処理することができる。なお、以降では「操作ＩＤ」と「操作情報」とは、製品分類ＩＤごとに定義されるとして説明するが、例えば、品番ごとなど細かい単位で定義できるようにしてもよい。

　図９は、実施の形態における操作パラメータ定義の説明図である。

　具体的な操作パラメータの定義内容の例は、図９に示している。図９の（ａ）は、製品分類ＩＤ＝０００１（冷蔵庫）の操作パラメータの定義である。操作ＩＤの定義では、操作ＩＤ＝０ｘ０００００００１がドアオープンを、操作ＩＤ＝０ｘ０００００００２がドアクローズをそれぞれ示す。操作情報の定義では、０ｘ０００００００１が冷蔵室を、０ｘ０００００００２が冷凍室を、０ｘ０００００００３が野菜室を、０ｘ０００００００４がチルド室を、それぞれ示す。

　図９の（ｂ）は、製品分類ＩＤ＝０００３（エアコン）の操作パラメータの定義である。操作ＩＤの定義では、操作ＩＤ＝０ｘ０００００００１が電源Ｏｎを、操作ＩＤ＝０ｘ０００００００２が電源Ｏｆｆを、操作ＩＤ＝０ｘ０００００００５が設定温度Ｕｐ（上昇）を、それぞれ示す。操作情報の定義では、操作実行後のエアコンの設定値を示し、先頭１バイト目がエアコンの運転モードを示し、０ｘ０１が冷房を、０ｘ０２が除湿を、０ｘ０３が暖房を、それぞれ示す。先頭２バイト目は設定温度値を示す。先頭３バイト目は風量設定で、０ｘ０１が自動を、０ｘ０２が「弱」を、０ｘ０３が「強」を、それぞれ示す。先頭４バイト目は風向き設定で０ｘ０１が自動を、０ｘ０２が「左向き」を、０ｘ０３が「右向き」を、それぞれ示す。

　図９の（ｃ）は、製品分類ＩＤ＝０００５（電子レンジ）の操作パラメータの定義である。操作ＩＤの定義では、操作ＩＤ＝０ｘ０００００００１が「温め開始」を、操作ＩＤ＝０ｘ０００００００２が「温め終了」を、それぞれ示す。操作情報の定義は設定されない。

　図８の操作履歴情報の例では、図９の操作パラメータ定義を参照している。図８において履歴ＩＤ＝０に対応する機器ＩＤが００００１であり、図７において製品ＩＤ＝００００１に対応する製品分類ＩＤが０００１（冷蔵庫）であるので、冷蔵庫の操作パラメータ定義（図９の（ａ））が適用される。よって、履歴ＩＤ＝０は、操作ＩＤ＝０ｘ０００００００１であるので、図９の（ａ）の操作パラメータ定義を参照し、ドアオープンであることが分かり、操作情報＝０ｘ０００００００２であるので、図９の（ａ）の操作パラメータ定義に基づいて、対象は冷凍室であることが分かる。このようにして、履歴ＩＤ＝０の操作は、機器ＩＤ＝０００１の冷蔵庫に対して、２０１３年１月１５日１２時１０分１５秒に、冷凍室のドアをオープンしたことが分かる。

　他の例では、履歴ＩＤ＝２に対応する機器ＩＤが００００３であり、図７において製品ＩＤ＝００００３に対応する製品分類ＩＤが０００３（エアコン）であるので、エアコンの操作パラメータ定義（図９の（ｂ））が適用される。よって、履歴ＩＤ＝２は、操作ＩＤ＝０ｘ０００００００１であるので、図９の（ｂ）の操作パラメータ定義を参照し、電源Ｏｎであることが分かり、操作情報＝０ｘ０３１９１１００であるので、図９の（ｂ）の操作パラメータ定義を参照し、操作実行後のエアコンの設定は運転モード＝暖房、設定温度＝２５度、風量設定＝自動、風向き＝自動であることが分かる。このようにして、履歴ＩＤ＝２の操作は、機器ＩＤ＝０００３のエアコンに対して、２０１３年１月１５日１２時１５分２０秒に、電源Ｏｎを実行し、その実行後のエアコンの設定状態は、運転モード＝暖房、設定温度＝２５度、風量設定＝自動、風向き＝自動であることが分かる。

　図６に戻り、つぶやき提示部６２０は、つぶやきを閲覧するためのミニブログサーバ又はＳＮＳサーバであり、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）等の通信プロトコルを利用し、ユーザ又は機器のつぶやきをつぶやき閲覧機器６０３に提供する。つぶやき提示部６２０は、つぶやき閲覧機器６０３を用いてつぶやき生成・閲覧サーバ６０１にアクセスするユーザ、及び、機器６０２を、ユーザ・機器管理ＤＢ６１７によって管理する。

　なお、つぶやき生成部６１４が、生成したつぶやきをつぶやきＤＢ６１９に登録し、登録されたつぶやきをつぶやき提示部６２０がつぶやき閲覧機器６０３に提供する、という一連の流れを、「つぶやき生成部６１４からつぶやき閲覧機器６０３へ、つぶやきを配信する」と表現する場合もある。また、上記のとおりつぶやきＤＢ６１９が外部の装置に備えられている場合には、その外部の装置につぶやきを配信させる、ということもできる。

　図１０は、本実施の形態におけるユーザ・機器管理ＤＢのデータ構造の説明図である。

　図１０は、ユーザ・機器管理ＤＢ６１７に記録されるプロフィール情報の例を示している。ユーザ・機器管理ＤＢ６１７には、ユーザＩＤと、種別と、名前と、フォローするユーザのユーザＩＤ（又は、機器の機器ＩＤ）と、フォローされるユーザのユーザＩＤ（又は、機器の機器ＩＤ）と、認証パスワードとが１つのエントリとして記録される。

　「ユーザＩＤ」は、つぶやき提示部６２０内で管理されるユーザのユニークなＩＤである。

　「種別」は、該当のユーザが人なのか、機器なのかを示すフラグ情報である。

　「名前」は、該当のユーザの名前である。

　「機器ＩＤ」は、「種別」が機器である場合の、機器管理ＤＢ６２２で管理される機器ＩＤである。

　「フォローするユーザＩＤ」は、該当のユーザがフォローするユーザのＩＤ群である。

　「フォローされるユーザＩＤ」は、該当のユーザをフォローするユーザのＩＤ群である。ここで、「フォローする」とは、指定されるユーザのつぶやきを、最初のページであるタイムラインに閲覧できるようにすることである。例えば、ユーザＡが、ユーザＢをフォローするとした場合には、ユーザＡが閲覧するつぶやきのタイムラインには、ユーザＢが作成したつぶやきが表示される。

　「認証パスワード」は、ユーザがつぶやき提示部６２０にアクセスする場合のアカウント管理に利用される。

　フォローするユーザ又は機器を設定する方法を説明する。つぶやき提示部６２０は、ユーザ・機器管理ＤＢ６１７の検索を行うページをユーザに提供する。ユーザは、提供されたページを使って、機器ＩＤ又は名前等を用いて検索を実行する。つぶやき提示部６２０は、ユーザによる検索の結果出てくるユーザ又は機器を、フォローする対象として設定できるようにする。ユーザＡがユーザＢをフォローすることを指定した場合には、ユーザＢに対して承認依頼が発行され、ユーザＢが承認したときのみフォローできるとしてもよい。ユーザＡが機器Ｂをフォローすることを指定する場合には、機器に紐付けられたパスワードを使って承認を認証するように構成してもよい。この場合には、機器管理ＤＢ６２２のエントリにおけるパスワードが利用されてもよい。

　なお、つぶやき提示部６２０におけるユーザ同士の関係性を定義するものとして、「フォローする」又は「フォローされる」という言葉を用いて説明を行うが、ユーザ同士の関係性は、これに限定されるものではない。ユーザ同士の関係性は、例えば、Ｆａｃｅｂｏｏｋ等のＳＮＳで定義されるような「友達関係」であってもよい。この場合、友達関係にあるユーザ又は機器同士は、「フォローする」又は「フォローされる」の関係になるとすれば、本実施の形態の内容が適用され得る。また、ユーザ同士の関係性は、例えば「家族関係」であってもよい。この場合、家族関係にあるユーザ又は機器同士は、「フォローする」又は「フォローされる」の関係になるとすれば、本実施の形態の内容が適用され得る。また、ユーザ同士の関係性は、例えば「所有関係」であってもよい。この場合、所有関係にあるユーザと機器との間では、「フォローする」又は「フォローされる」の関係になるとすれば、本実施の形態の内容が適用され得る。なお、「友達関係」、「家族関係」又は「所有関係」にあるユーザ以外には、ユーザ又は機器のつぶやきを検索や表示もさせないとして、限定されたグループ又はコミュニティでつぶやきの共有を行うようにしてもよい。

　つぶやき提示部６２０は、新規にユーザがつぶやき提示部６２０にアクセスする場合には、「ユーザの新規登録」を提示し、ユーザによるプロフィール情報の入力結果に応じて、ユーザ毎にアカウントを生成し、ユーザのプロフィールをユーザ・機器管理ＤＢ６１７に追加する。図１０に示されるユーザＩＤ＝００００１と００００５とは、上記の手順によって追加されたユーザに対応する。また、つぶやき提示部６２０は、機器管理ＤＢ６２２に登録される機器のプロフィールを元に、ユーザ・機器管理ＤＢ６１７にユーザとして登録する。例えば、図１０に示されるユーザＩＤ＝０００２、０００３及び０００４は、機器管理ＤＢ６２２に登録される機器に対応する。ユーザＩＤ＝０００２のユーザは、機器ＩＤ＝０００１であるため、図７の（ａ）を参照し、機器ＩＤ＝００００１の冷蔵庫であることがわかる。

　つぶやき提示部６２０は、ユーザからつぶやきの閲覧命令を受け取ると、つぶやきＤＢ６１９に格納されるつぶやきから、該当のユーザがフォローするユーザのつぶやきを検索・取得し、つぶやき閲覧機器６０３に伝送する。

　図１１は、実施の形態におけるつぶやきＤＢのデータ構造の説明図である。

　図１１は、つぶやきＤＢ６１９に蓄積されるつぶやきのデータ構造を示す。つぶやきＤＢ６１９に格納されるデータは、つぶやきＩＤと、ユーザＩＤと、時刻と、内容と、返信ＩＤとが１つのエントリとして蓄積される。

　「つぶやきＩＤ」は、つぶやきＤＢ６１９内でユニークな管理番号であって、各つぶやきに対して設定される管理番号である。

　「ユーザＩＤ」は、該当のつぶやきを発生したユーザを特定するための、ユーザ・機器管理ＤＢ６１７のユーザＩＤである。

　「時刻」は、該当のつぶやきが発生した時刻であり、例えば、つぶやきＤＢ６１９に追加される時刻である。

　「内容」は、該当つぶやきのテキスト又は写真等のコンテンツ本体である。

　「返信ＩＤ」は、該当エントリの返信先のつぶやきＩＤを示す。返信ＩＤを参照することで、該当のエントリが、どのつぶやきに対する返信かを判断することが可能となる。図１１の例では、つぶやきＩＤ＝４のつぶやき「一緒に買い物しよう！」の返信ＩＤが３であるので、つぶやきＩＤ＝４のつぶやきは、つぶやきＩＤ＝３のつぶやき「大阪府茨木市イオン前なう。」に対する返信であることが分かる。

　つぶやき提示部６２０は、ユーザへのつぶやきの表示だけでなく、ユーザによるつぶやきの書き込み、又は、つぶやきへの返答をも実現する。つぶやき提示部６２０は、つぶやき閲覧機器６０３に、つぶやきの書き込みページを提示し、ユーザは、つぶやき閲覧機器６０３の情報入出力部６３２により、つぶやきメッセージを入力する。つぶやき提示部６２０は、つぶやきメッセージを受け取ると、該当ユーザのユーザＩＤと共に、受け取ったつぶやきメッセージをつぶやきＤＢに追加する。

　図１０及び図１１の例で、ユーザＩＤ＝００００１のユーザ（ｓａｗａｄａ５５)が、つぶやき提示部６２０に、つぶやき閲覧命令を実行した場合には、つぶやき提示部６２０は、図１０のユーザ・機器管理ＤＢ６１７を参照し、ユーザＩＤ＝００００１のユーザがフォローするユーザＩＤ＝００００２、００００４、及び００００５のユーザと、自身（ユーザＩＤ＝００００１）とが生成した最新のつぶやきを取得する。図１１の例では、つぶやき提示部６２０は、つぶやきＩＤ＝０、２、３、４のつぶやきを取得して、つぶやき閲覧機器６０３に伝送し、つぶやき閲覧機器６０３は該当のつぶやきを表示する。図１１の例でｓａｗａｄａ５５がつぶやきを表示させた場合のＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）の例を図２３の（ａ）に示す。なお、つぶやき閲覧命令とは、例えば、ＷｅｂＡＰＩ（Ｗｅｂ　Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）等でのつぶやき取得命令である。

　また、Ｆａｃｅｂｏｏｋでは、発生されたユーザのつぶやきに対して、肯定的又は好意的意見を容易に示すためのＩ／Ｆ（インタフェース）として、「いいね」ボタンがある。「いいね」ボタンは、つぶやきと共に表示され、そのボタンがクリックされることで、ユーザが「いいね」を押したことをユーザインターフェースに提示する。この「いいね」ボタンを実現するためには、一例として、つぶやきＤＢを図２４のように構成する。図２４では、エントリに「いいね」ボタンを選択したユーザＩＤが登録されている。つぶやき提示部６２０は、つぶやきに付与される「いいね」ボタンをユーザが選択した場合には、つぶやきＤＢの該当つぶやきエントリの「いいねユーザＩＤ」に該当ユーザのユーザＩＤを指定する。このようにすることで、誰がどのつぶやきに「いいね」を選択したかを判断することができる。図２３の（ｂ）は、「いいね」ボタンの提示例を示している。なお、Ｆａｃｅｂｏｏｋでは、「いいね」ボタンが、つぶやきに対する肯定的又は好意的意見を容易に示すためのツールとして用いられているが、ＳＮＳサイトによって、名称は異なる。例えば、ｍｉｘｉでは、「ミクシチェック」、任天堂のＭｉｉｖｅｒｓｅでは、「そうだね」ボタンなどである。以降では、「いいね」ボタンを、「肯定的又は好意的意見を容易に示すためのボタンＩ／Ｆ」であるとして説明するが、名称等は、該当のＳＮＳ等に応じて、変更してもよい。

　つぶやき提示部６２０は、ユーザ毎につぶやきの閲覧履歴（閲覧要求履歴ともいう）を記録して、閲覧履歴ＤＢ６１８に記録する。つぶやきの閲覧履歴は、行動履歴情報の一例である。

　図１２は、実施の形態における閲覧履歴ＤＢのデータ構造の説明図である。

　図１２は閲覧履歴ＤＢ６１８の構造を示す。閲覧履歴ＤＢ６１８は、ユーザＩＤと、時刻と、操作とを１つのエントリとして記録して管理する。

　「ユーザＩＤ」は、閲覧を実行したユーザのユーザＩＤ（ユーザ・機器管理ＤＢ６１７で管理されるユーザＩＤ）である。

　「時刻」は、閲覧操作の実行時刻である。

　「操作」は操作内容を示し、例えば、最新つぶやきを取得、ユーザの検索、つぶやきの検索、つぶやきの投稿などがある。

　図６に戻り、つぶやき生成情報設定部６１１は、つぶやき生成部６１４のつぶやき発生方法を定義する。つぶやき発生方法とは、自動でつぶやきを発生させるためのアルゴリズムである。

　図１３は、実施の形態におけるつぶやき発生方法の説明図である。

　上記のアルゴリズムの一例としては、図１３に示すようにＣ言語等のプログラム言語によって記載されたアルゴリズムがある。アルゴリズムは、製品分類ＩＤごとに設定される。図１３は、製品分類ＩＤ＝０ｘ０００１（冷蔵庫）のつぶやき発生方法の例である。図１３に示すように、eventCallback()と、scheduleCallback()との２種類のコールバック関数が用意され、ユーザは、つぶやき生成情報設定部６１１を利用して、これら２つの関数を実装することで、つぶやき発生方法を定義する。eventCallback()とscheduleCallback()とはあくまで一例であり、これ以外にコールバックが定義されてもよい。例えば、ユーザがつぶやき提示部６２０にアクセスしたときに発生するコールバックなどが定義されてもよい。

　eventCallback()は、機器操作が実行されたタイミングで、実行されるコールバック関数である。引数には、machineID(機器ＩＤ)、operationID(操作ＩＤ)、及び、operationData(操作情報)が渡される。図１３の例では、冷蔵庫のドアがオープンされた場合と、冷蔵庫がクローズされた場合との例が示されている。先頭文のUserManageDatabaseは、ユーザ・機器管理ＤＢ６１７のプログラム上のクラスオブジェクトを示し、このメソッドを使用することで、データベースにアクセスすることができる。

　UserManageDatabase.findUser(機器ＩＤ)は、機器ＩＤに対応するユーザＩＤを検索して取得するメソッドであり、返り値でユーザＩＤを渡す。最初のif文は、operationID==0x0000001であり、ドアオープンされたケースを示す。

　HistoryDatabaseは、機器操作履歴ＤＢ６１２のプログラム上のクラスオブジェクトを示し、このメソッドを使用することで、データベースにアクセスすることができる。HistoryDatabase.countAtDate(機器ＩＤ，操作ＩＤ，日付)は、該当機器ＩＤに対して、操作ＩＤで示される操作が、指定される日付で何度実行されたかをカウントするメソッドである。カウントされた回数の結果は、リターン値で返され、図１３の例では、nOpenに格納される。その後のPost()関数は、ユーザＩＤでつぶやきＤＢ６１９に該当つぶやきを追加する関数である。Post()は、Ｃ言語のprint文を模した関数であり、“%d”は１０進数の変数であり、“%d”の箇所にnOpenの値が挿入された文章を生成して、つぶやきＤＢ６１９に追加する。例えば、nOpenが１２であれば、「ドアオープン！今日はこれで１２回目のオープンです。」という文章になる。このように、eventCallback()内のアルゴリズムを定義することによって、機器操作が発生したタイミングで、機器操作に基づいたつぶやきの発生方法を定義することが可能となる。

　scheduleCallback()は、定期的なタイマーイベントとして実行されるコールバック関数である。引数には、machineID(機器ＩＤ)が指定される。タイマーの間隔は、システム構成によって設定されるとしてもよいし、つぶやき生成情報設定部６１１により設定できるとしてもよい。図１３の例では、scheduleCallbackの関数では、TweetDatabaseのメソッドが実行されている。TweetDatabaseは、つぶやきＤＢのプログラム上のクラスオブジェクトであり、上記メソッドを使用することで、データベースにアクセスすることができる。

　TweetDatabase.getLastTweet()は、当該機器による最後のつぶやきを取得するメソッドであり、返り値で、最終のつぶやきが返答される。返答された最終のつぶやきは、図１３の例では「tweet」に格納される。

　「if( Date.now - tweet.date < 10800 ) return」の文は、つぶやきの発生時刻と現在時刻とを比較している条件文であり、Data.nowは秒単位の現在時刻であり、tweet.dateは最後のつぶやきが発生した秒単位の時刻情報を示す。この差を取ることにより、最後のつぶやきから現在までにどれくらいの時間が経過したかを示す。１０８００秒は３時間であるので、最後のつぶやきから、現在までの経過時間が３時間未満であれば、何も実行せずに終了するとしている。このように構成することで、つぶやきの頻度を調整できる。

　その後のswitch文は、乱数によってつぶやきの内容を変更することを示している。rand()%100により、0から99までの乱数の結果が計算され、各caseに応じて、出力するつぶやきの内容を変更することで、多くのつぶやきのバリエーションを実現できる。このように、scheduleCallback()内のアルゴリズムを定義することによって、機器が定期的に発生するつぶやきの発生方法を定義することができる。

　つぶやき生成部６１４は、つぶやき生成情報設定部６１１によって設定されたつぶやき生成アルゴリズムにしたがって、機器による自律的なつぶやきの発生を処理する。具体的には、機器管理ＤＢ６２２に定義される機器ごとの単位で、プログラムのスレッドが実行する。実行されたスレッドにおいて、（１）機器操作発生タイミングでeventCallback()が実行され、（２）定期的なタイマーごとにscheduleCallback()が実行される。それ以外の間はwait/idleしている。eventCallback()とscheduleCallback()との内容は、図１３で説明した通り、つぶやき生成情報設定部６１１によって定義され、この関数を実行した結果、つぶやきＤＢ６１９につぶやきが追加される。なお、実行するスレッドは機器単位ではなく、ある一定の複数の機器単位でもよい。なお、実行するスレッドは、機器管理ＤＢ内の機器のうち、ネットワークに接続可能状態にあるものだけに限定してもよい。

　また、つぶやき生成部６１４は、つぶやきＤＢ６１９に登録されるつぶやきを参照して、そのつぶやきに対して、機器による返信を自動で生成させることも可能である。具体的には、scheduleCallback()等により機器が生成するつぶやきの生成において、該当機器がフォローするユーザのつぶやきを、つぶやきＤＢ６１９から取得し、取得したつぶやきの内容の解析を行い、返信のつぶやきを生成して、つぶやきＤＢ６１９に追加すればよい。

　また、同様に、つぶやき生成部６１４は、つぶやきＤＢ６１９に登録されるつぶやきを参照して、そのつぶやきに対して、機器による「いいね」ボタンの選択を自動で行うことも可能である。具体的には、scheduleCallback()等において、該当機器がフォローするユーザのつぶやきを、つぶやきＤＢ６１９から取得し、その内容の解析を行い、該当つぶやきエントリの「いいねユーザＩＤ」に自身のユーザＩＤを追加することで実現できる。

　以上、説明した、機器、つぶやき生成・閲覧サーバ、つぶやき閲覧機器を用いることで、機器による自律的なつぶやきの生成、及び、生成されたつぶやきの閲覧を実現することができる。次に、この構成を元に、つぶやきを閲覧するユーザに対してユーザビリティを損なうことなく、機器が自動的に発生させるつぶやきの量を制御することで、つぶやきを蓄積するデータベースの負荷を削減するための方法を説明する。

　図１４は、本実施の形態におけるつぶやき発生頻度のパラメータの説明図である。

　つぶやき頻度算出部６１６は、つぶやきの発生頻度を算出し、算出したつぶやき頻度をユーザ・機器管理ＤＢ６１７に格納する。図１４は、ユーザ・機器管理ＤＢ６１７の構成を示しており、図１０の構成に加えて、各エントリに対して、「つぶやき発生頻度」の属性が追加されている。つぶやき頻度算出部６１６によって算出された、機器が発生するつぶやきの発生頻度は、この「つぶやき発生頻度」に格納される。

　つぶやき頻度算出部６１６は、閲覧履歴ＤＢ６１８を参照して、つぶやき発生頻度を算出する。具体的には、例えば、閲覧履歴ＤＢを参照した結果、ユーザＩＤ＝００００１（ｓａｗａｄａ５５）の閲覧は平均１日に１回であり、閲覧履歴ＤＢを参照した結果、ユーザＩＤ＝００００５（ｔａｉｊｉ）の閲覧は平均８日に１回であるとする。この場合に、つぶやき頻度算出部６１６は、ユーザＩＤ＝００００１（ｓａｗａｄａ５５）がフォローするユーザ（機器）のつぶやき発生頻度を高く設定し、ユーザＩＤ＝００００５（ｔａｉｊｉ）がフォローするユーザ（機器）のつぶやき発生頻度を低く設定する。図１４の例では、ユーザＩＤ＝００００１（ｓａｗａｄａ５５）は、ユーザＩＤ＝００００２の機器をフォローしているので、この機器のつぶやき発生頻度の値を、例えば１個／３時間と設定する。一方で、ユーザＩＤ＝００００５（ｔａｉｊｉ）は、ユーザＩＤ＝００００１の機器をフォローしているので、この機器のつぶやき発生頻度の値を、ユーザＩＤ＝００００１（ｓａｗａｄａ５５）がフォローする機器よりも低く設定し、例えば、１個／２４時間と設定する。

　つぶやき生成部６１４は、つぶやき頻度算出部６１６が算出したつぶやき発生頻度に基づいて、機器が発生するつぶやきを生成する。具体的には、schduleCallback()を呼び出すタイマー間隔をこの値に設定してもよいし、図１５に示すように、scheduleCallback()又はeventCallback()などで、該当機器に対応するつぶやき発生頻度を取得して、その値を参照して、つぶやき発生頻度を制御してもよい。

　図１５は、本実施の形態におけるつぶやき発生頻度のパラメータを用いてつぶやきの発生頻度を変更するつぶやき発生方法の説明図である。図１５の例では、UserManageDatabase.getTweetFrequency(ユーザＩＤ)によって、発生頻度を取得する。図１５の例では、発生頻度は、１個のつぶやきを発生する平均時間間隔であり、現在時刻と最終つぶやき発生時刻との差分が、これより小さい場合はつぶやきを実行しないとすれば、発生頻度を制御できる。

　図１６は、本実施の形態におけるつぶやき閲覧結果の表示の説明図である。上記のようにユーザがつぶやきを閲覧した表示結果は、例えば図１６のようになる。ｓａｗａｄａ５５が平均１日に１回つぶやきを閲覧する場合に、つぶやき頻度が１個／３時間と設定されれば、フォローする機器が１つの場合には、ログイン時には平均して８個のつぶやきが表示される。一方で、ｔａｉｊｉが平均８日に１回つぶやきを閲覧する場合に、つぶやき頻度が１個／２４時間と設定されれば、フォローする機器が１つの場合には、ログイン時には平均して８個のつぶやきが表示される。このようにつぶやきの数を、ユーザの閲覧履歴に応じて変動させることで、ユーザがログイン時に閲覧する新着の数が変わらないように設定できるため、ユーザビリティを損なうことがない。なお、つぶやき頻度を平均値として、つぶやきの発生時期にばらつきを持たせる方が、人が行うような自然なつぶやきとなる。

　このように構成することで、ユーザのつぶやきの閲覧履歴を元に、各機器が自動で発生するつぶやきの頻度を制御することができる。これにより、つぶやきを閲覧するユーザの利便性が損なわれずに、機器が自動的に発生させるつぶやきの量を制御することが可能となる。

　なお、図１７のように、互いに異なるユーザＩＤのユーザが、同じ機器ＩＤの機器をフォローする場合には、頻繁に閲覧するユーザの閲覧履歴を元につぶやき発生頻度を決定するように構成してもよい。図１７は、本実施の形態におけるユーザ・機器管理ＤＢの別例を説明する図である。このように構成することで、頻繁にアクセスする利用者のユーザビリティが損なわれない。

　なお、つぶやき頻度算出部６１６は、ユーザのつぶやき閲覧履歴をもとに、算出結果として「時間帯」を追加して設定できるようにしてもよい。例えば、ユーザのつぶやき閲覧履歴において、昼付近の時間帯での閲覧が多ければ、ユーザがフォローする機器の「時間帯」に「朝」を設定する。そして、つぶやき生成情報設定部６１１によって設定されるつぶやき発生方法により、「朝」が設定された機器は、現在時刻を参照して、朝の時間帯に多くつぶやきを生成するようにする。一方、ユーザのつぶやき閲覧履歴において、深夜付近の時間帯での閲覧が多ければ、ユーザがフォローする機器の「時間帯」に「夜」を設定する。そして、つぶやき生成情報設定部６１１によって設定されるつぶやき発生方法により、「夜」が設定された機器は、現在時刻を参照して、夜の時間帯に多くつぶやきを生成するようにする。このように構成することで、ユーザのライフスタイルに合わせて、タイムリーにつぶやきを発生させることが可能となる。

　なお、上記の「時間帯」は、「７時から８時まで」というように、開始時刻から終了時刻までの時間として指定されることもある。

　なお、つぶやきＤＢのデータ構造としては、図１８のように、データベースへの登録時刻と、つぶやきが発生した時刻とを分けて管理するように構成してもよい。図１８は、本実施の形態におけるつぶやきＤＢのデータ構造の変形例１を示す図である。この場合には、つぶやき提示部６２０は、機器がつぶやいた時刻として、データベースへの「登録時刻」ではなく、「つぶやき時刻」をユーザに提示する。つぶやき提示部６２０は、ユーザが「つぶやき時刻」より前に、アクセスする場合には、該当つぶやきを表示せず、現在時刻がつぶやき時刻を過ぎてからつぶやきを提示する。このように構成することで、つぶやき生成手段は、自身の負荷を考慮もしくは予測を行い、データベースへのつぶやき発生処理をスケジューリングすることができる。つまり、処理負荷が低いタイミングで、あらかじめ分かっている内容のつぶやきを先回りで生成することで、処理負荷を平滑化することが可能となる。

　なお、図１８のように、データベースへの登録時刻と、つぶやきが発生した時刻とを分けて管理するように構成した場合に、ユーザがつぶやき提示部６２０にアクセスしたタイミングで、現在時刻よりも過去の時刻を「つぶやき時刻」としたつぶやきを生成しユーザに提示するように構成してもよい。このように構成することで、頻繁にアクセスしないユーザに対する機器つぶやきの発生頻度を抑えることが可能となる。つまり、頻繁にアクセスしないユーザに対しては、つぶやき生成手段は機器のつぶやきの生成をやめておき、ユーザがアクセスしたときにだけ、最新のつぶやきとして、過去のつぶやきを生成して提示するといったことが可能となる。

　なお、つぶやき頻度算出部６１６は、ユーザのつぶやき閲覧履歴をもとに算出するとしたが、つぶやき閲覧履歴ではなく、該当機器の使用履歴を利用してもよい。例えば、掃除機の利用が、月に１回のユーザと、週に１回のユーザがいる場合には、週に１回のユーザに対するつぶやき発生頻度を高めるように構成してもよい。このようにすることで、一般に頻繁に機器を利用するユーザは、該当機器に対する興味が高いため、その興味に応えたつぶやきの発生を実現することができる。

　なお、つぶやき頻度算出部６１６は、ユーザのつぶやき閲覧履歴をもとに算出するとしたが、つぶやき閲覧履歴ではなく、該当機器以外の使用履歴もしくはセンサーの結果を利用してもよい。例えば、目覚まし時計が機器として、つぶやき生成・閲覧サーバ６０１に接続されている場合には、目覚まし時計の操作履歴であるＯｎとＯｆｆとが機器操作履歴ＤＢ６１２に蓄積される。この値を参照することにより、目覚まし時計を所有する若しくは保持するユーザの睡眠リズムが分かる。そこで、つぶやき頻度算出部６１６は、この目覚まし時計の操作履歴を参照し、つぶやき頻度（発生頻度や時間帯）を決定する。このようにすることで、ユーザの生活リズムに合わせて、タイムリーでユーザの状況にあった内容のつぶやきを発生させることができる。例えば、ユーザに対して問いかけを行うようなつぶやきの場合には、ユーザが起きている時間帯に合わせる、といったことが可能となる。なお、目覚まし時計は一例であり、家の電力消費量のグラフなどのログ情報をつぶやき生成・閲覧サーバ６０１が取得できれば、そうした情報を使うことで、よりユーザに適応させて、つぶやきの発生タイミングや内容を制御できる。なお、「ユーザに対して問いかけを行うようなつぶやき」のことを「第一種別のコンテンツ」といい、第一種別以外のコンテンツを「第二種別のコンテンツ」ということもある。

　なお、つぶやき頻度算出部６１６は、ユーザのつぶやき閲覧履歴をもとに算出するとしたが、つぶやき閲覧履歴ではなく、つぶやきの書き込み頻度を利用してもよい。例えば、書き込み頻度が低いユーザに対しては、機器のつぶやき頻度を低くするとしてもよい。言い換えれば、書き込み頻度が高いユーザに対しては、機器のつぶやき頻度を高くするとしてもよい。このようにすることで、ユーザの好みに合わせたつぶやき頻度を実現できる。

　なお、機器が発生するつぶやきに対して、ユーザが返答を行うことで、該当機器に対する実際の操作を実行できるようにしてもよい。

　図１９は、実施の形態におけるコンテンツ生成・閲覧システムの変形例を示すブロック図である。図１９に示されるつぶやき生成・閲覧サーバ６０１Ａでは、つぶやき生成・閲覧サーバ６０１に対して、機器操作制御部１８０１が追加されている。機器操作制御部１８０１は、つぶやき提示部６２０からの命令に応じて、該当の機器に対して、「操作命令」を通信する。機器６０２は、通信部６３１により、「操作命令」を受け取り、自身の機器操作を実行する。

　以下、より具体的に説明する。図２０のように、つぶやきＤＢにはリクエストＩＤの属性が追加されている。リクエストＩＤは、製品分類ごとに定義されるリクエストパラメータのＩＤであり、リクエストパラメータ定義を参照することにより、ユーザが返答を行った後に行うべき操作内容が定義される。

　具体的には、図２０の（ａ）のつぶやきＤＢのつぶやきＩＤ＝０の例によれば、エアコンによるつぶやきでは、「暖房つけますか？」のテキストと共に、リクエストＩＤ＝０ｘ０００００００２が指定されている。リクエストＩＤ＝０ｘ０００００００２は、図２０の（ｂ）のリクエストパラメータ定義を参照すると、暖房Ｏｎであることが分かる。つぶやき生成部６１４は、機器の処理をお薦めする質問の場合には、つぶやきＤＢに、つぶやきのメッセージと共に、ユーザの返答時に行うべき操作内容として、リクエストＩＤを同時に設定する。このようにリクエストＩＤが付与されるつぶやきを、「操作お薦めつぶやき」と定義する。

　つぶやき提示部６２０がユーザに対して、エアコンによる「暖房つけますか？」のつぶやきを提示した後、このリクエストに対してユーザが「はい」と返答を行えば、つぶやき提示部６２０は、機器操作制御部１８０１に対して、該当エアコンの機器ＩＤとリクエストＩＤとを送信する。機器操作制御部１８０１は、機器ＩＤから特定される機器であるエアコンがリクエストＩＤに対応した動作をするための操作命令を生成し、生成した操作命令をエアコンに伝送する。エアコンは、伝送された操作命令を実行する。操作命令は、例えば、図９で説明したような操作パラメータ定義を用いて記述される。なお、操作お薦めつぶやきに対して、ユーザが「いいえ」と返答するか、又は、何も返答を行わない場合、つぶやき提示部６２０は、機器操作制御部１８０１に何も行わない。

　図２１Ａ～図２１Ｄは、操作お薦めつぶやきの表示例の説明図である。

　なお、操作お薦めつぶやきにおいては、図２１Ａのように、つぶやきの表示において、ユーザによる回答の選択肢を提示してもよい。このようにすれば、ユーザの意図を正確に反映できる。

　なお、操作お薦めつぶやきにおいては、図２１Ｂのように、つぶやきの表示において、「いいね」ボタン等を表示してもよい。ユーザが当該「いいね」ボタン等を押したことを、つぶやき提示部６２０は、ユーザによる肯定的な意図表示として処理してもよい。このようにすることで、ユーザは、ＳＮＳのユーザインターフェースで簡単に意図表示を行うことができる。

　なお、操作お薦めつぶやきにおいては、図２１Ｃのように、操作結果を表示してもよい。このようにすることで、ユーザは、自身の意図した操作が、機器により確かに実行されたことを確認することができる。

　なお、操作お薦めつぶやきにおいては、図２１Ｄのように、確認メッセージが提示されてもよい。つぶやき提示部６２０は、ユーザによる返答を正しく解析できない場合には、再度つぶやきを発生させて、確認メッセージを提示するようにしてもよい。このようにすることで、ユーザの意図と異なる誤動作を防ぐことができる。

　なお、操作お薦めつぶやきは、該当機器以外の使用履歴もしくはセンサーの結果に基づいて、発生するようにしてもよい。例えば、ユーザのスマートフォンのＧＰＳ情報を収集し、外出先から家に帰宅することを検知した場合には、ユーザが家に帰宅してから実行する機器の操作履歴を元に、該当機器の操作お薦めつぶやきを生成してもよい。具体例としては、ユーザが家に帰宅することを検知した場合に、ユーザの機器操作履歴に基づき、エアコンが「エアコンつけますか？」と操作お薦めつぶやきを生成する。

　具体的な構成としては、つぶやき生成部６１４は、scheduleCallback()等のつぶやき発生処理において、機器をフォローするユーザのスマートフォンのＧＰＳ情報を取得し、外出先から家に帰宅途中であることを検知すると、機器管理ＤＢ６２２及び機器操作履歴ＤＢ６１２を参照し、ユーザ帰宅後に実行する確率が高い操作情報（操作ＩＤ）を特定し、操作お薦めつぶやきを生成し、つぶやきＤＢ６１９に登録する。

　なお、操作お薦めつぶやきが生成されたにもかかわらず、ユーザが閲覧したタイミングで、既にリモコン等でお薦めされる機器操作が実行されている状態になっている場合には、そのままユーザに対して操作お薦めつぶやきを提示しては、混乱を与えてしまう可能性があるので、下記のように対応してもよい。

　（１）該当の操作お薦めつぶやきがユーザによって閲覧されていない状態であり、該当の操作が既に実行されている状態である場合には、該当のつぶやきを破棄する、としてもよい。具体的には、つぶやき提示部６２０は、ユーザからの閲覧要求を受け付け、新着のつぶやきをつぶやきＤＢから取得した段階で、取得した新着のつぶやきが操作お薦めつぶやきである場合であって、機器操作履歴ＤＢ６１２を参照することで、該当操作が既に実行されている状態であることがわかる場合には、該当操作お薦めつぶやきをつぶやきＤＢから削除するとしてもよい。

　（２）該当の操作お薦めつぶやきがユーザによって閲覧されていない状態であり、該当の操作が既に実行されている状態である場合には、該当のつぶやきの表示を変更するとしてもよい。具体的には、つぶやき提示部６２０は、ユーザからの閲覧要求を受け付け、新着のつぶやきをつぶやきＤＢから取得した段階で、取得した新着のつぶやきが操作お薦めつぶやきである場合であって、機器操作履歴ＤＢ６１２を参照することで、該当操作が既に実行されている状態であることがわかる場合には、該当操作お薦めつぶやきの表示を通常とは異なる形で提示する。なお、つぶやきの表示を変更する方法には、例えば、図２７の（ａ）に示されるように、該当のつぶやきをグレーアウトする方法がある。

　（３）該当の操作お薦めつぶやきがユーザによって閲覧されていない状態であり、該当の操作が既に実行されている状態である場合には、該当のつぶやきに、事後フォローする形で、別のつぶやきを返信してもよい。図２７の（ｂ）の例では、「暖房つけますか？」という操作お薦めつぶやきに対して、「先ほど、リモコンで暖房がつきました。」とフォローの返信を行っている。具体的には、つぶやき提示部６２０は、ユーザからの閲覧要求を受け付け、新着のつぶやきをつぶやきＤＢから取得した段階で、取得した新着のつぶやきが操作お薦めつぶやきである場合であって、機器操作履歴ＤＢ６１２を参照することで、該当操作が既に実行されている状態である場合には、つぶやき生成部６１４にイベント通知を行う。つぶやき生成部６１４は、該当の操作おすすめつぶやきに対して、返信つぶやきを生成し、つぶやきＤＢに登録を行う。

　上記のように構成することにより、操作お薦めつぶやきが生成されたにもかかわらず、ユーザが閲覧したタイミングで、既にリモコン等でお薦めされる機器操作が実行されていた状態になっている場合においても、ユーザへの混乱を防ぐことが可能となる。なお、上記（１）～（３）の対応は、ユーザが該当のつぶやきを閲覧していない状態であり、該当の操作が既に実行されている状態である場合だけでなく、例えば、「操作お薦めつぶやき」から、ある一定時間を経過している場合に発生させてもよい。この場合には、「操作お薦めつぶやき」に対して、「有効期間」のパラメータを設けておき、つぶやきＤＢに登録しておく。つぶやき提示部６２０は、ユーザが閲覧するタイミングで、該当有効期間を過ぎている場合には、上記（１）～（３）の対応を行うように構成することで実現できる。

　なお、ユーザによる閲覧頻度が低いほど、操作お薦めつぶやきの作成頻度をより低くしてもよい。閲覧頻度が低いユーザは、有効期間内に操作お薦めつぶやきを閲覧する可能性が低いためである。

　なお、操作お薦めつぶやきにおいては、ユーザが返答することで、機器の操作を実現するとしたが、ユーザがフォローする機器に対してつぶやきを行うことで、操作を直接お願いしてもよい。この場合には、つぶやき提示部６２０は、機器へのユーザによるつぶやきを解析し、該当機器のリクエストパラメータ定義からリクエストＩＤを特定し、該当機器ＩＤと該当リクエストＩＤとを機器操作制御部１８０１に伝送する。その後、つぶやき提示部６２０は、つぶやき生成部６１４にイベント通知を行い、つぶやき生成部６１４はイベント通知に対応して、返答のつぶやきを生成し、つぶやきＤＢに登録する。このように、機器に対して、操作を依頼するつぶやきを、「操作依頼つぶやき」と定義する。操作依頼つぶやきのユーザインターフェースのイメージを図２５に示す。このように構成することで、ユーザは、つぶやきのＩ／Ｆによって、簡単に機器の操作を制御することが可能である。

　なお、機器によるつぶやきにおいて、ユーザに飽きさせない多様のバリエーションのつぶやきをユーザに提供するために、機器に対して、人間的な性格をパラメータとして設定できるようにしてもよい。具体的には、図２２のようにユーザ・機器管理ＤＢが構成され、各エントリに対して、性別、血液型、出身地、結婚の有無、年令、趣味、職業、資格、有効度及び情緒といったパラメータが設定される。各パラメータは、機器のプロフィール等から自動で設定されてもよく、機器を所有するユーザが適宜ＧＵＩ等で変更できるようにしてもよい。

　つぶやき生成部６１４は、該当機器によるつぶやきを発生させる場合には、これらのパラメータを参照してつぶやきの内容（コメント）を変更する。下記にその変更内容の例を記載する。

　つぶやき生成部６１４は、「性別」が男であれば男言葉（「今日も元気だぜ！」）、女であれば女言葉（「今日も元気ですわ！」）になるようにコメントを変更する。

　つぶやき生成部６１４は、「血液型」がＡ型であれば神経質、Ｏ型であれば大雑把、というような性質に基づいてコメントを変更する。

　つぶやき生成部６１４は、「出身値」に応じて、当該地方の方言をコメントに適用する。出身地が埼玉であれば標準語、大阪であれば関西弁というようにコメントを変更する。なお、出身値のパラメータは、実際の機器の製造場所が設定されるようにしてもよい。その場合、つぶやき生成部６１４は、機器管理ＤＢ６２２の属性情報を取得して設定すればよい。

　つぶやき生成部６１４は、「結婚」に、未婚若しくは既婚の別、又は、どのパートナーと結婚しているかを設定してもよい。結婚しているパートナー同士で仲良く会話がなされたり、夫婦喧嘩が行われたりしてもよい。

　つぶやき生成部６１４は、「年齢」が低い場合は子供の話し方、高い場合は大人の話し方というようにコメントを変更する。なお、年齢のパラメータは、実際の機器の購入時又は製造時からの現在時刻までの年数が設定されるようにしてもよい。その場合、つぶやき生成部６１４は、機器管理ＤＢ６２２の属性情報を取得して設定すればよい。

　つぶやき生成部６１４は、「趣味」又は「資格」に応じて、趣味又は資格に関する内容の情報をＷｅｂの検索等によって取得して、その情報に基づいてコメントを変更する。

　つぶやき生成部６１４は、「友好度」に応じてコメントの口調を変更してもよい。ここで、「友好度」は、仲のよさを示す。つぶやき生成部６１４は、「友好度」が高ければ、ため口の口調を用い、そうでなければ丁寧語の口調を用いるとすると、ユーザとの間でより人間に近いコミュニケーションを実現できる。「友好度」は、該当機器をフォローするユーザごとに別々に設定できるようにしても良い。この場合、語りかけるユーザの友好度によって話し方や中身をかえてもよく、機器に対する「操作依頼つぶやき」においては、友好度に応じて、操作を実行する確率を変更してもよい。つまり、友好度の高いユーザからのお願いは素直に実行するが、友好度の低いユーザからのお願いは断るなどしてもよい。

　つぶやき生成部６１４は、「情緒」に応じてコメント内容を変更してもよい。「情緒」は、怒りっぽい、又は、泣きっぽいなどの人間の感情部分の特徴を示す。

　以上のように構成することで、つぶやき生成部６１４は、多様なつぶやきのバリエーションをユーザに提供することが可能となる。

　なお、ユーザと機器との関係として、「家族関係」又は「友人関係」が設定できるようにしてもよい。つまり、ユーザは、機器に対して「息子」、「娘」、「夫」、「奥さん」、「いとこ」、「ボーイフレンド」、「ガールフレンド」又は「親友」といった属性を設定できるようにしてもよい。これら属性に基づきコメントにおける言葉遣い等を変更すれば、ユーザと機器との間で、より人間的なコミュニケーションを実現できる。例えば、「ガールフレンド」と設定された機器からは、「なんか疲れちゃった～（はーと）」など甘えた言葉のつぶやきが生成されるとしてもよい。なお、これらの属性に基づき、例えば、ソーシャルグラフ又は家系図で、ユーザと機器群との関係をＧＵＩとして表示してもよい。

　なお、「友好度」は、機器とユーザとの間以外にも、機器同士で設定可能としてもよい。その場合には、友好度の高い機器同士が勝手におしゃべり（返信しあう）をするようにつぶやきを生成してもよい。反対に友好度の低い機器同士は喧嘩をするようにつぶやきを生成してもよい。

　なお、「友好度」は、機器とユーザ間以外にも、機器と機器同士でも設定可能としてもよく、その場合には、友好度の高い機器同士は「いいね」をお互いに発生させる確率を高いようにするとしてもよい。

　なお、機器同士の友好度の値は、同一カテゴリの機器同士において高いと構成してもよい。例えば、電子レンジと冷蔵庫とは共に食材を扱うので仲がよい、又は、テレビとレコーダとは共に映像を扱うので仲がよい、などである。このようにすれば、ユーザは、直感的に機器の仲のよさを理解することができる。

　なお、機器同士の友好度の値は、使用時間帯が同じ機器同士において高いと構成してもよい。例えば、電子レンジと冷蔵庫とは同時に利用する可能性が高いので仲がよい、又は、テレビとレコーダとは同時に利用する可能性が高いので仲がよい、などである。このようにすれば、ユーザは直感的に機器の仲のよさを理解することができる。

　なお、ユーザの注意を引くために、機器が発生するつぶやきは、過剰な言い方であってもよい。例えば、加湿器が「水がなくなりそうで、死にそう」といえば、ユーザをどきりとさせ、ユーザの注意を引くことができる。なお、機器によるつぶやきをより人間的にするために、低い確率で、真実とは異なること、つまり嘘をつくことをしてもよい。このことを、エイプリルフール（４月１日）に行えば、ユーザにとって楽しいユーモアとなり得る。

　なお、ユーザ・機器管理ＤＢ６１７に「熟練度」を設けてもよい。熟練度は、「操作お薦めつぶやき」に対する操作依頼の処理実行の成功確率を示す。熟練度が低い場合は、時々、操作依頼を行っても機器は処理を失敗するように構成し、熟練度が上がることで、成功確率を上げるとしてもよい。このように構成すれば、熟練度をあげる育成ゲームのような楽しさを、ユーザに提供することができる。

　なお、「操作依頼つぶやき」の変形例として、機器を特定せずに、あるお願いをしたら、そのお願いを、機器が手を挙げて自動で実行するように構成してもよい。例えば、図２６の（ａ）のように、ユーザが「室温を上げて」とお願いすると、エアコン、ファンヒーター又は床暖房が手を上げて、操作を実行する。

　具体的には、つぶやき提示部６２０は、ユーザの操作依頼つぶやきを解析し、対応可能な機器ＩＤを特定する。その後、１つまたは複数の機器ＩＤにおけるリクエストパラメータ定義から、リクエストＩＤを特定し、該当機器ＩＤと該当リクエストＩＤとを機器操作制御部１８０１に伝送する。その後、つぶやき提示部６２０は、つぶやき生成部６１４にイベント通知を行う。つぶやき生成部６１４はイベント通知に対応して、該当機器による返答のつぶやきを生成し、つぶやきＤＢに登録する。このように構成することで、ユーザは機器を特定せずに、簡単に自身のお願いを機器に実行させることが可能となる。

　なお、図２６の（ｂ）のように、お願いをした後に、すぐに実行せずに、操作を実行するかを再度ユーザに確認するように構成してもよい。このように構成すれば、ユーザの意図しない機器が操作を実行してしまうことを防ぐことができる。

　なお、ユーザが発生するつぶやきに対して、ユーザがフォローする機器群から、ユーザがして欲しそうな操作を類推して、「操作おすすめつぶやき」を生成してもよい。例えば、ユーザが「これから帰るなう」とつぶやきを発声させた場合に、ユーザがフォローするエアコンから「暖房つける？」、照明から「あかりつけとく？」といったつぶやきが生成されるようにしてもよい。このように構成すれば、ユーザは難しい制御なしに、簡単に機器操作を実行できる。具体的には、つぶやき生成部６１４は、scheduleCallback()等のつぶやき発生処理において、機器がフォローされるユーザのつぶやきを取得し、その内容を解析してユーザの現在の行動を特定し、その行動において、必要とされる機器の操作を、機器操作履歴ＤＢを参照して特定し、操作お薦めつぶやきを生成し、つぶやきＤＢに登録する。

　なお、上記のようなユーザのつぶやきの代わりに、ユーザの位置情報を含む情報を利用して上記と同様の制御をおこなうこともできる。ユーザの位置情報は、ＧＰＳ（Ｇｌｏｂａｌ　Ｐｏｓｉｔｉｏｎｉｎｇ　Ｓｙｓｔｅｍ）などにより取得できる。なお、ユーザの位置情報は、ユーザの行動履歴情報の一例である。

　なお、機器が生成するつぶやきにおいては、ユーザがフォローする他の機器と内容が重複しないように、ユーザがフォローする機器群において、つぶやきの内容を調整するように構成してもよい。図２８の（ａ）の例では、ユーザがフォローする機器が全て「おはよう」という挨拶をつぶやいているが、ユーザとしては、すべての機器が同じ内容をつぶやいては面白みに欠ける。そこで、図２８の（ｂ）に示すように、機器が生成するつぶやきの内容が異なるようにする。これは、つぶやき生成部６１４におけるつぶやき発生処理において、フォローされるユーザが保有する機器のつぶやきの最新の内容を参照し、重複しないようにつぶやきを生成することで実現できる。

　なお、本実施の形態においてはユーザが使用する機器によるつぶやきの発生方法を記載したが、現在保有していない機器によるつぶやきを実現してもよい。例えば、インターネット等で製品の購入予約を行った段階で、該当製品がつぶやきを生成するように構成してもよい。「もう少しであなたのおうちにいくよ！」というように、宅配の状況のつぶやきを行ってもよい。これは、インターネット等で製品の購入予約を行った段階で、機器管理ＤＢ６２２と、ユーザ・機器管理ＤＢ６１７とに機器が登録され、つぶやき生成部６１４のつぶやき発生方法を適切に定義されることで、実現可能である。

　なお、機器が故障して使えなくなった場合に、機器に対して感情移入したユーザがさびしい思いをすることを回避するために、故障した機器のユーザＩＤ（ユーザ・機器管理ＤＢ６１７で管理されるＩＤ）に対応するエントリの機器ＩＤを、新しく購入した機器の機器ＩＤに変更できるようにしてもよい。このように構成すれば、これまでの機器のつぶやきが引き継がれることになるため、ユーザはさびしい思いをすることを回避できる。

　なお、つぶやきＤＢの属性として、当該つぶやきを閲覧可能なユーザを指定するプライバシー属性が定義されていてもよい。この属性が設定されている場合には、機器が生成するつぶやきは指定されるユーザ以外は閲覧できないとしてもよい。例えば、体重計のつぶやきについては、ユーザの体重など、他のユーザに見られたくないつぶやき情報にはプライバシー属性が設定され、該当ユーザのみが閲覧できるようになっており、体重計の使い方等のつぶやきにはプライバシー属性が設定されない。このように構成すれば、機器のつぶやきに対して、柔軟なプライバシー設定が可能となる。

　なお、機器が生成するつぶやきのバリエーションとしては、他に以下のようなものがある。

　（１）機器に関連するニュースをインターネットで検索をして、その内容（ＵＲＬやＴｗｉｔｔｅｒのつぶやき）等を含めた内容をつぶやく。例えば、冷蔵庫が「冷蔵庫の中身の整理整頓方法を教えます！（http://xxx.../）」といった機器のノウハウ情報をつぶやく。

　（２）機器が写真を撮影してアップロードし、そのリンク先をつぶやきに含める。例えば、冷蔵庫が「今の冷蔵庫の中身です（http://xxx.../..jpg）」とつぶやく。

　（３）ユーザが保有する機器の種類や使用履歴に応じて、家電がＣＭをつぶやく。例えば、電子レンジを保持しないユーザに対して、冷蔵庫が「Ｍ社から最新の電子レンジでました(http://xxx..../)」とつぶやく。

　（４）ユーザが保有する機器の使用履歴に応じて、家電が「使っていない機能」をつぶやく。例えば、電子レンジの「ミルクボタン」を押したことがないユーザに対して、電子レンジが「電子レンジのミルクボタンを押すことで、劇旨ホットミルクが作れますよ。」とつぶやく。

　上記の実現は、つぶやき生成部６１４におけるつぶやき発生方法を前述の通りプログラムで定義することで実現できる。

　図２９は、実施の形態のおけるコンテンツ提示装置の構成の他の例を示すブロック図である。

　図２９に示されるように、コンテンツ提示装置２９０１は、機器のユーザの行動履歴情報を取得する取得部２９１１と、機器からユーザへの対話のためのコンテンツを生成する頻度を行動履歴情報に基づき決定し、決定した頻度でコンテンツを生成するコンテンツ生成部２９１２と、対話用コンテンツを配信するためのサーバに、生成されたコンテンツを対話用コンテンツとして配信させることで、コンテンツをユーザに提示する提示部２９１３とを備える。

　図３０は、実施の形態のおけるコンテンツ提示装置におけるコンテンツ処理方法の他の例を示すフローチャートである。

　図３０に示されるように、コンテンツ提示方法は、機器のユーザの行動履歴情報を取得する取得ステップ（ステップＳ３００１）と、機器からユーザへの対話のためのコンテンツを生成する頻度を行動履歴情報に基づき決定し、決定した頻度でコンテンツを生成するコンテンツ生成ステップ（ステップＳ３００２）と、対話用コンテンツを配信するためのサーバに、生成されたコンテンツを対話用コンテンツとして配信させることで、コンテンツをユーザに提示する提示ステップ（ステップＳ３００３）とを含む。

　以上のように、本実施の形態のコンテンツ提示方法によれば、機器に関するコンテンツの種別と頻度とが、ユーザの行動履歴情報に基づいて決定される。具体的には、ユーザの行動履歴から判定される、ユーザによるコンテンツの閲覧可能性に応じて、当該コンテンツの種別とその生成頻度とが決定される。よって、本発明に係るコンテンツ提示方法により、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　また、機器に関するコンテンツの種別が、ユーザの行動履歴情報に基づいて決定される。具体的には、ユーザの行動履歴から判定される、ユーザによるコンテンツの閲覧可能性に応じて、当該コンテンツの種別が決定される。よって、本発明に係るコンテンツ提示方法により、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　また、コンテンツの閲覧要求の頻度が低いユーザに対して、より少ない数のコンテンツが提示される。これにより、ユーザが一度に閲覧すべきコンテンツが当該ユーザの閲覧頻度に応じて削減され、ユーザが一度に閲覧すべきコンテンツの数が閲覧頻度によらずおおむね一定になるようにすることができる。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　また、ユーザによるコンテンツの閲覧要求の頻度が低い時間帯（第一時間帯）において、より少ない数のコンテンツが提示される。これにより、ユーザが閲覧する可能性が低い時間帯のコンテンツの生成が抑制され、ユーザが閲覧する可能性が高い時間帯のコンテンツの生成が維持される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　また、コンテンツの閲覧要求の頻度が低いユーザに対して、ユーザに問いかける旨のコンテンツを生成することが抑制される。仮に、コンテンツの閲覧要求の頻度が低いユーザに、問いかける旨のコンテンツを提示したとしても、当該ユーザが当該コンテンツを閲覧するのは比較的長時間経過後と考えられ、そのときに問いかけの回答が得られても適切な機器制御ができない可能性が高いためである。このように、ユーザによりコンテンツが閲覧された結果、適切な制御が行われないことが想定される場合に、当該コンテンツの生成が抑制される。

　また、これによれば、機器に対する操作の頻度が低いユーザに対して、より少ない数のコンテンツが提示される。これにより、ユーザが一度に閲覧すべきコンテンツが当該ユーザの操作の頻度に応じて削減される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　また、過去にユーザが機器を操作したことがある時間帯（第二時間帯）でない時間帯に、コンテンツの生成が抑制され、第三時間帯でのコンテンツの生成が維持される。当該ユーザは、将来的にも第三時間帯に機器を制御する可能性が高いと考えられるので、第三時間帯にコンテンツを生成して提示することでユーザの利便性を損なわずに、コンテンツの数を削減することができる。

　また、機器に対する操作の頻度が低いユーザに対して、ユーザに問いかける旨のコンテンツを生成することが抑制される。これにより、ユーザの利便性を損なわずに、コンテンツの数を削減することができる。

　また、ユーザが、あらかじめ設定された領域にいない場合に、コンテンツの生成が抑制され、上記領域にユーザがいる場合にはコンテンツの生成が維持される。よって、ユーザビリティを損なうことなく、サーバにおける処理負荷を低減することができる。

　上記態様において説明された技術は、例えば、以下のクラウドサービスの類型において実現されうる。しかし、上記態様において説明された技術が実現される類型はこれに限られるものでない。

　（サービスの類型１：自社データセンタ型）
　図２は、サービスの類型１（自社データセンタ型）を示す。本類型は、サービスプロバイダ１２０がグループ１００から情報を取得し、ユーザに対してサービスを提供する類型である。本類型では、サービスプロバイダ１２０が、データセンタ運営会社の機能を有している。即ち、サービスプロバイダが、ビッグデータの管理をするクラウドサーバ１１１を保有している。従って、データセンタ運営会社は存在しない。

　本類型では、サービスプロバイダ１２０は、データセンタ（クラウドサーバ１１１）を運営、管理している（２０３）。また、サービスプロバイダ１２０は、ＯＳ（２０２）及びアプリケーション（２０１）を管理する。サービスプロバイダ１２０は、サービスプロバイダ１２０が管理するＯＳ（２０２）及びアプリケーション（２０１）を用いてサービス提供を行う（２０４）。

　（サービスの類型２：ＩａａＳ利用型）
　図３は、サービスの類型２（ＩａａＳ利用型）を示す。ここでＩａａＳとはインフラストラクチャー・アズ・ア・サービスの略であり、コンピュータシステムを構築および稼動させるための基盤そのものを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。

　本類型では、データセンタ運営会社がデータセンタ（クラウドサーバ１１１）を運営、管理している（２０３）。また、サービスプロバイダ１２０は、ＯＳ（２０２）及びアプリケーション（２０１）を管理する。サービスプロバイダ１２０は、サービスプロバイダ１２０が管理するＯＳ（２０２）及びアプリケーション（２０１）を用いてサービス提供を行う（２０４）。

　（サービスの類型３：ＰａａＳ利用型）
　図４は、サービスの類型３（ＰａａＳ利用型）を示す。ここでＰａａＳとはプラットフォーム・アズ・ア・サービスの略であり、ソフトウェアを構築および稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。

　本類型では、データセンタ運営会社１１０は、ＯＳ（２０２）を管理し、データセンタ（クラウドサーバ１１１）を運営、管理している（２０３）。また、サービスプロバイダ１２０は、アプリケーション（２０１）を管理する。サービスプロバイダ１２０は、データセンタ運営会社が管理するＯＳ（２０２）及びサービスプロバイダ１２０が管理するアプリケーション（２０１）を用いてサービス提供を行う（２０４）。

　（サービスの類型４：ＳａａＳ利用型）
　図５は、サービスの類型４（ＳａａＳ利用型）を示す。ここでＳａａＳとはソフトウェア・アズ・ア・サービスの略である。例えばデータセンタ（クラウドサーバ）を保有しているプラットフォーム提供者が提供するアプリケーションを、データセンタ（クラウドサーバ）を保有していない会社・個人（利用者）がインターネットなどのネットワーク経由で使用できる機能を有するクラウドサービス提供モデルである。

　本類型では、データセンタ運営会社１１０は、アプリケーション（２０１）を管理し、ＯＳ（２０２）を管理し、データセンタ（クラウドサーバ１１１）を運営、管理している（２０３）。また、サービスプロバイダ１２０は、データセンタ運営会社１１０が管理するＯＳ（２０２）及びアプリケーション（２０１）を用いてサービス提供を行う（２０４）。

　以上いずれの類型においても、サービスプロバイダ１２０がサービス提供行為を行ったものとする。また例えば、サービスプロバイダ若しくはデータセンタ運営会社は、ＯＳ、アプリケーション若しくはビックデータのデータベース等を自ら開発してもよいし、また、第三者に外注させてもよい。

　なお、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態のつぶやき生成・閲覧サーバなどを実現するソフトウェアは、次のようなプログラムである。

　すなわち、このプログラムは、コンピュータに、ユーザの行動履歴情報を取得する取得ステップと、機器から前記ユーザへの対話のためのコンテンツを生成する頻度を前記行動履歴情報に基づき決定し、決定した前記頻度で前記コンテンツを生成するコンテンツ生成ステップと、生成された前記コンテンツを配信することで、前記コンテンツを前記ユーザに提示する提示ステップとを含むコンテンツ提示方法を実行させる。

　以上、一つまたは複数の態様に係るコンテンツ提示方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。

　本発明の一態様に係る自動つぶやき生成システムは、例えば、生活家電、及び、ＡＶ家電の操作履歴、動作履歴などの情報を利用し、ユーザが容易に楽しく家電の情報を閲覧することができる。故に本発明にかかる自動つぶやき生成システムは、生活家電、及び、ＡＶ家電産業において高い利用可能性を持つ。

　　　１０、２０　　ユーザ
　　１００　　グループ
　　１０１　　機器
　　１０２　　ホームゲートウェイ
　　１１０　　データセンタ運営会社
　　１１１　　クラウドサーバ
　　１２０　　サービスプロバイダ
　　１２１　　サーバ
　　２０１　　アプリケーション
　　２０２　　ＯＳ
　　２０３　　データセンタ（クラウドサーバ）
　　２０４　　ユーザ
　　６０１、６０１Ａ　　つぶやき生成・閲覧サーバ
　　６０２　　機器
　　６０３　　つぶやき閲覧機器
　　６１１　　つぶやき生成情報設定部
　　６１２　　機器操作履歴ＤＢ
　　６１３　　機器操作履歴収集部
　　６１４　　つぶやき生成部
　　６１６　　つぶやき頻度算出部
　　６１７　　ユーザ・機器管理ＤＢ
　　６１８　　閲覧履歴ＤＢ
　　６１９　　つぶやきＤＢ
　　６２０　　つぶやき提示部
　　６２１　　機器管理部
　　６２２　　機器管理ＤＢ
　　６３１　　通信部
　　６３２　　情報入出力部
　　１８０１　　機器操作制御部

Claims

　ユーザの行動履歴情報を取得する取得ステップと、
　機器から前記ユーザへの対話のためのコンテンツを生成する頻度を前記行動履歴情報に基づき決定し、決定した前記頻度で前記コンテンツを生成するコンテンツ生成ステップと、
　生成された前記コンテンツを配信することで、前記コンテンツを前記ユーザに提示する提示ステップとを含む
　コンテンツ提示方法。
　前記コンテンツ生成ステップでは、さらに、
　生成する前記コンテンツの種別を前記行動履歴情報に基づき決定し、決定した種別の前記コンテンツを生成する
　請求項１に記載のコンテンツ提示方法。
　前記提示ステップでは、
　前記ユーザによる前記コンテンツの閲覧要求を受け付け、受け付けた前記閲覧要求に応じて前記コンテンツを前記ユーザに提示し、
　前記取得ステップでは、
　前記提示ステップで受け付けた前記閲覧要求の頻度を含む情報を、前記行動履歴情報として取得し、
　前記コンテンツ生成ステップでは、
　前記行動履歴情報における前記閲覧要求の頻度が低いほど、前記コンテンツをより低い頻度で生成し、又は、前記行動履歴情報における前記閲覧要求の頻度が高いほど、前記コンテンツをより高い頻度で生成する
　請求項１又は２に記載のコンテンツ提示方法。
　前記取得ステップでは、
　前記提示ステップで受け付けた前記閲覧要求の頻度が第一閾値未満である第一時間帯を特定する情報を、前記行動履歴情報として取得し、
　前記コンテンツ生成ステップでは、
　前記行動履歴情報から特定される前記第一時間帯において、前記第一時間帯を含まない時間帯における前記コンテンツの生成頻度より低い頻度で前記コンテンツを生成する
　請求項３に記載のコンテンツ提示方法。
　前記コンテンツの種別は、前記ユーザに問いかける旨を含むコンテンツを示す第一種別と、前記第一種別を除く第二種別とを含み、
　前記コンテンツ生成ステップでは、
　前記行動履歴情報における前記閲覧要求の頻度が低いほど、より低い頻度で前記第二種別のコンテンツを生成し、又は、前記行動履歴情報における前記閲覧要求の頻度が高いほど、より高い頻度で前記第二種別のコンテンツを生成する
　請求項３又は４に記載のコンテンツ提示方法。
　前記取得ステップでは、
　前記ユーザによる前記機器に対する操作の履歴に基づいて定められる情報であって、前記ユーザによる前記操作の頻度を含む情報を、前記行動履歴情報として取得し、
　前記コンテンツ生成ステップでは、
　前記行動履歴情報における前記操作の頻度が低いほど、前記コンテンツをより低い頻度で生成し、又は、前記行動履歴情報における前記操作の頻度が高いほど、前記コンテンツをより高い頻度で生成する
　請求項１～５のいずれか１項に記載のコンテンツ提示方法。
　前記取得ステップでは、
　前記ユーザによる前記機器に対する操作の履歴に基づいて定められる情報であって、前記ユーザによる前記操作の頻度が第二閾値未満である第二時間帯を特定する情報を、前記行動履歴情報として取得し、
　前記コンテンツ生成ステップでは、
　前記行動履歴情報から特定される前記第二時間帯において、前記第二時間帯を含まない時間帯における前記コンテンツの生成頻度より低い頻度で前記コンテンツを生成する
　請求項６に記載のコンテンツ提示方法。
　前記コンテンツの種別は、前記ユーザに問いかける旨を含むコンテンツを示す第一種別と、前記第一種別を除く第二種別とを含み、
　前記コンテンツ生成ステップでは、
　前記行動履歴情報における前記操作の頻度が低いほど、より低い頻度で前記第一種別のコンテンツを生成し、又は、前記行動履歴情報における前記操作の頻度が高いほど、より高い頻度で前記第一種別のコンテンツを生成する
　請求項６又は７に記載のコンテンツ提示方法。
　前記取得ステップでは、
　前記ユーザの位置情報を含む情報を、前記行動履歴情報として取得し、
　前記コンテンツ生成ステップでは、
　前記行動履歴情報から特定される前記ユーザの位置が、あらかじめ設定された領域内でない場合に、前記ユーザの位置が前記領域内である場合より低い頻度で前記コンテンツを生成する
　請求項１～８のいずれか１項に記載のコンテンツ提示方法。
　請求項１に記載のコンテンツ提示方法をコンピュータに実行させるためのプログラム。