プログラム生成装置
【課題】機器の標準通信仕様の変更があるか否かにかかわらず、クラウドサービス等のネットワーク上のサービスを、機器の新機能を利用して提供できるようなプログラムを生成するプログラム生成装置を提供する。
【解決手段】プログラム生成装置10は、制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第1プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第1サービスとを連携した連携サービスを実現する第2プログラムとを用いて、前記連携サービスを実現する第3プログラムを生成する生成部を有する。
【解決手段】プログラム生成装置10は、制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第1プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第1サービスとを連携した連携サービスを実現する第2プログラムとを用いて、前記連携サービスを実現する第3プログラムを生成する生成部を有する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、プログラム生成装置に関する。
【背景技術】
【0002】
インターネットの発達に伴いパソコン以外の様々な機器が通信機能を有するようになってきている。通信機能を有する機器としては、例えば、携帯電話、電力メータ、エアコンやTV等の家電機器、そして車など多様な機器がある。
【0003】
一方、近年、パソコン以外の様々な機器が、通信機能を有するようになることに伴い、クラウドサービス等のネットワーク上のサービスを、通信機能を有する機器と連携した新たなサービス(以下、ネット連携サービスと称する。)を提供する動きがある。このようなネット連携サービスにより、より多様なサービスを、サービス提供を受けるユーザは受け取ることができる。なお、ネットワーク上のサービスは、例えば、当該サービスを提供するASP(Application Service Provider)がインターネット上に配置するサーバが提供する。ネット連携サービスの一例として、ネットワーク上のサービスがクラウド連携サービスである場合を考える。そして、例えば、クラウド連携サービスの一例として、クラウドサービスがtwitter(商品名)である場合であって、かつ通信機能を有する機器がテレビである場合を例に考える。この場合、クラウド連携サービスとして、ユーザのテレビの受信チャネルを自動的に取得して、twitter(商品名)上に、現在、見ているテレビのチャネルを自動的に投稿するサービスを想定できる。
【0004】
従来、機器の通信機能を設計する際に、その通信仕様(通信手順)は、例えばDLNA(Digital Living Alliance)のような標準策定団体にて、標準化が行われてきた。その結果、異なるメーカの機器であっても、同じ標準通信仕様に従うことが一般的であり、同一メーカの新機種と旧機種であっても、同一の通信仕様標準化により各機器が共通した標準通信仕様に従うことが一般的であった。
【0005】
また、従来、ネット連携サービスを実行するためプログラムは、標準通信仕様にしたがった機器と連携するための機能と、その機能を用いて実行するサービスを提供するための機能とを併せ持ったプログラムが生成されていた。つまり、ネット連携サービスを実行するためのプログラムは、標準通信仕様に依存したプログラムとなっていた。
【0006】
一般的に、クラウドサービス等のネットワーク上のサービス進化の速度は非常に速い一方で、機器の標準通信仕様の進化は遅い。機器の通信仕様の進化が遅い理由は、通信仕様の普及には時間がかかるためである。通信仕様の普及にかかる時間は、古い通信仕様との互換性の容易さや通信仕様を備える機器の買い替えサイクルに依存する。例えば、エアコンは10年という長い使用期間のため、同じ通信仕様を長く使い続けることが予想され、標準通信仕様の進化が遅いことが想定される。このため、クラウド連携サービス等のネットワーク上のサービスと通信機能を有する機器と連携したネット連携サービスは、クラウドサービス等のネットワーク上のサービスが進化しても、使用する標準通信仕様が進化しない故に、進化が難しいという課題がある。
【0007】
また、半導体技術の進化の速度は速く機器の機能は急速に進化する一方で、機器の標準通信仕様の進化は遅い。例えば、モデルチェンジにより機器に機能を追加しても、標準通信仕様がその機能をサポートしていない仕様である場合もある。このような場合、ネット連携サービスは、サービス提供に当たり、モデルチェンジにより機器に追加された追加機能を利用できないという課題がある。例えば、先述のクラウド連携サービスの一例を用いて考える。例えば、TVに、番組表を有する機能を追加した場合であって、標準通信仕様には、番組表を取得する機能を有しない場合を考える。この場合、クラウド連携サービスとして、番組表のデータを用いたサービスを提供できない。例えば、twitter(商品名)上に、現在、見ているテレビの番組名を自動的に投稿するサービスを提供できない。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2009-110300号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
本発明の一側面は、機器の標準通信仕様の変更があるか否かにかかわらず、ネットワーク上のサービスを、機器の機能に合わせて、機器の機能を利用したサービスを提供できるようなプログラムを生成するプログラム生成装置を提供することを目的とする。
【課題を解決するための手段】
【0010】
本発明の一観点にかかるプログラム生成装置は、制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第1プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第1サービスとを連携した連携サービスを実現する第2プログラムとを用いて、前記連携サービスを実現する第3プログラムを生成する生成部を有する。
【図面の簡単な説明】
【0011】
【図1】本発明の第1の実施形態にかかるシステムを示すブロック図。
【図2】図1のシステムにおける動作を示すシーケンス図。
【図3A】動作装置13がTVである場合のAPIプログラムの例を示す図。
【図3B】動作装置13がTVである場合のAPIプログラムの例を示す図。
【図3C】動作装置13がTVである場合のAPIプログラムの例を示す図。
【図4A】ロジックプログラムの例を示す図。
【図4B】ロジックプログラムの例を示す図。
【図5】図1のシステムにおけるプログラム生成装置10を示すブロック図。
【図6】ヒューマンインタフェース処理部110が、画面にロジックプログラム選択画面を表示した場合の例を示す図。
【図7】ヒューマンインターフェース処理部110が、画面に動作装置選択画面を表示した場合の例を示す図。
【図8】プログラム実行装置選択画面の一例を示す図。
【図9A】実行プログラムの例を示す図。
【図9B】実行プログラムの例を示す図。
【図9C】実行プログラムの例を示す図。
【図9D】実行プログラムの例を示す図。
【図9E】実行プログラムの例を示す図。
【図10】本発明の第1の実施形態の変形例にかかるシステムを示すブロック図。
【図11】図10のシステムにおける動作を示すシーケンス図。
【図12】図10の動作装置20の構成を示すブロック図。
【図13】本発明の第2の実施形態にかかるシステムを示すブロック図。
【図14】図13のシステムにおけるシーケンス図。
【図15】スマートフォン30Aが、画面上に表示する走行可能範囲31Cの例。
【図16】本発明の第3の実施形態にかかるシステムを示すブロック図。
【図17】図14のシステムにおけるシーケンス図。
【図18】図16のエネルギー管理サーバ41で事項する実行プログラムの蓄熱量制御のアルゴリズムを示すフローチャート。
【発明を実施するための形態】
【0012】
以下、本発明の実施の形態について、図面を参照しながら説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【0013】
<第1の実施形態>
図1は、本発明の第1の実施形態にかかるシステムを示すブロック図である。
【0014】
本発明の第1の実施形態に係るシステムは、プログラム生成装置10と、API蓄積装置12と、動作装置13と、プログラム実行装置14と、アプリケーションサーバ15と、プログラム蓄積サーバ16と、がネットワーク17を介して接続されている。
【0015】
動作装置13とは、ユーザに対してサービス動作を行う装置である。動作装置13は、例えばTVやPVR(Personal Video Recorder:ハードディスクレコーダ)である。
【0016】
アプリケーションサーバ15は、ネットワークを介して、サービス利用者に対して、サービスを提供するサーバである。アプリケーションサーバ15が、提供するサービスは、例えば、クラウドサービスである。
【0017】
API蓄積装置12は、APIプログラムを蓄積するとともに、ネットワーク17を介して、APIプログラムを他の装置に提供する装置である。ここで、API(Application Program Interface)プログラム(請求項1の第1プログラムに対応する。)は、動作装置13に、ネットワーク17を介してアクセスするための通信手順を実現するプログラムである。ここで、動作装置13に、ネットワーク17を介してアクセスするための通信手順は、動作装置13にアクセスして実現すること(例えば、動作装置13の制御若しくは、動作装置の機能の利用等)によって異なる。そして、動作装置13にアクセスして実現できることは、動作装置13が有する機能によって異なる。したがって、APIプログラムは、動作装置13が有する機能や、動作装置13にアクセスして実現したいことによって、異なるプログラムが割り当てられる。より具体的には、図1のシステムの動作装置13の機種が変わった場合、その機種に応じたAPIプログラムが生成される。また、複数の動作装置13がある場合、その動作装置13毎にAPIプログラムが生成される。また、一つの動作装置13に対して、実現したい目的に応じて、複数のAPIプログラムを生成することもある。
【0018】
プログラム蓄積サーバ16は、APIプログラムを利用するプログラムであって、アプリケーションサーバ15が提供するサービスと動作装置13とを連携させるプログラムであるロジックプログラム(請求項1の第2のプログラムに対応する。)を蓄積するとともに、ネットワーク17を介して他の装置に提供する装置である。
【0019】
プログラム生成装置10は、APIプログラムとロジックプログラムを基に、アプリケーションサーバ15が提供するサービスと動作装置13の機能とを連携させる実行プログラム(請求項1の実行プログラムに対応する。)を生成するとともに、実行プログラムをネットワーク17を介して他の装置に提供する装置である。ここで、実行プログラムは、後述するプログラム実行装置14が実行できるプログラムである。実行プログラムは、プログラム実行装置14が実行可能であればその形式を問わない。バイナリ形式のプログラムでなくてもよい。実行プログラムの形式は、例えば、Perl、Java(登録商標)Script、Ruby(商品名)、Java(登録商標)である。
【0020】
プログラム実行装置14は、実行プログラムを実行する機能を有する。
【0021】
図1では、アプリケーションサーバ15と、プログラム蓄積サーバ16と、プログラム生成装置10と、プログラム実行装置14と、動作装置13と、API蓄積装置12とが各々一台ずつである例を示しているが、各々複数台存在する構成してもよい。
【0022】
次に、図2を用いて、図1のシステムの動作を説明する。図2は、図1のシステムの通信シーケンスを示す図である。
【0023】
プログラム実行装置14と動作装置13とAPI蓄積装置12とは、定期的に、広告メッセージをブロードキャスト又はマルチキャストする(S101〜S103)。広告メッセージは、例えば、装置種別とプロバイダ識別子とモデル識別子と装置IPアドレスとを含む。ここで、広告メッセージは、例えばIPパケットを用いて運ばれる。
【0024】
ここで、広告メッセージが含む各情報の説明を行う。
【0025】
装置種別とは、プログラム実行装置14、API蓄積装置12、動作装置13各々を互いに識別する識別子である。また、装置種別は、動作装置13の種別も識別できる識別子であることが好ましい。動作装置の種別とは、例えば、TVやPVRであるかを示す種別である。
【0026】
プロバイダ識別子は、装置を製造したメーカを識別する識別子である。
【0027】
モデル識別子は、装置のモデルを識別する識別子である。モデル識別子は、例えば、UUID(Universally Unique Identifier)を用いることが好ましい。UUIDを用いることにより、製造メーカが異なるモデルでも異なる識別子を割り当てることができる。
【0028】
個体識別子は、装置を一意に識別する識別子である。個体識別子は、例えば、UUIDを用いることが好ましい。尚、必ずしも、個体識別子単体で、装置を一意に識別する識別子としなくてもよい。例えば、モデル識別子と個体識別子との組み合わせで、装置を一意に識別できるようにしてもよい。
装置IPアドレスは、装置に割り当てられたIPアドレスである。
【0029】
以上が、広告メッセージが含む情報の説明である。
【0030】
次に、図2を用いて、本実施形態のシステムの動作説明を続ける。
【0031】
次に、プログラム生成装置10は、API蓄積装置12から取得した広告メッセージを参照し、API蓄積装置12にAPIプログラムを要求し、APIプログラムを受信する(S104)。プログラム生成装置10は、APIプログラムを要求する際、API蓄積装置12から取得した広告メッセージに含まれる装置IPアドレス(API取得URL:例えば,http://192.168.0.1/api/)に向けて、HTTPを用いて、APIプログラムを要求する。
【0032】
次に、プログラム生成装置10は、プログラム蓄積サーバ16から取得した広告メッセージを参照し、プログラム蓄積サーバ16にロジックプログラムを要求し、ロジックプログラムを受信する(S105)。この際、プログラム生成装置10は、ロジックプログラムを要求する際、プログラム蓄積サーバ16から取得した広告メッセージに含まれる装置IPアドレスにむけて、ロジックプログラムを要求する。
【0033】
次に、プログラム生成装置10は、取得したAPIプログラムとロジックプログラムを用いて、実行プログラムを生成する。そして、生成した実行プログラムをプログラム実行装置14に向けて送信する(S106)。ここで、プログラム生成装置10は、広告メッセージで取得したプログラム実行装置14のIPアドレスに向けて、HTTPを用いて、実行プログラムを送信する。
【0034】
次に、プログラム実行装置14は、受信した実行プログラムを実行する。プログラム実行装置14は、実行プログラムを実行する際に、アプリケーションサーバ15および動作装置13にネットワーク17を介してアクセスする(S107、S108)。
【0035】
プログラム実行装置14が実行プログラムを実行することで、動作装置13とアプリケーションサーバ15との連携を実現することができる。連携動作の詳細については、具体例を用いて、後述する。
【0036】
以上が、図1のシステムの動作シーケンスの説明である。
【0037】
本実施形態では、動作装置13毎に動作装置13にアクセスするための通信手順として、システム全体であらかじめ決められた標準仕様でなく、動作装置13毎に定められたAPIプログラムを用いている。通信仕様が、システム全体で定められていないため、動作装置13とアプリケーションサーバ15とを独立に開発・設置することが可能となる。また、動作装置13の機能に応じたAPIプログラムを実現できるため、APIプログラムを用いた実行プログラムで、動作装置13にアクセスすることで、動作装置13の機能を生かした連携サービスを実現できる。
【0038】
また、本実施形態では、実行プログラムを、動作装置13とは別のプログラム実行装置14にて実行する。この結果、実行プログラムが、動作装置13では扱えない計算量を要求する場合であっても、動作させることができる。特に、アプリケーションサーバ15がASPによるインターネット上のサーバであり、プログラム実行装置14がソフトフォーンやPCのようなASPの提供するサービス(ASPサービス)を利用する装置である場合には、急速に進化するASPサービスに追従する計算能力をプログラム実行装置14が有することが期待できる。
【0039】
次に、APIプログラムの一例を説明する。尚、本実施例では、動作装置13にアクセスするためのプログラムとして、APIを含むプログラムであるAPIプログラムを例にとって説明するが、これに限られない。つまり、動作装置13にアクセスする手順を示すプログラムであればよく、必ずしも、APIを有しているプログラムである必要はない。
【0040】
図3A〜Cは、動作装置13がTVである場合のAPIプログラムの例を示す図である。
【0041】
図3A〜Cで示したAPIプログラムはJava(登録商標)Scriptで書いた疑似コードである。APIプログラム(ファイルapi.js)は、動作装置13毎に設定され、外部の装置(例えば、プログラム実行装置14)は、このAPIプログラムで定められた通信手順に従って、動作装置13にアクセスすることができる。尚、APIプログラムは、本実施例では、APIプログラム蓄積装置12が保持していてもよいし、当該APIプログラムを用いてアクセスできる動作装置13に保持させていてもよい。
【0042】
図3のAPIプログラムでは、<API_Functions>と</API_Functions>との間に、動作装置13にアクセスするためのAPI関数名が記されている。図3の例では、getApiInfo() 、readCurrentCh() 、setCurrentCh() 、readChList() といった関数が定められている。
【0043】
getApiInfo()は、動作装置13にアクセスして、APIプログラムに関する情報を得るためのAPIである。
【0044】
ここで、APIに関する情報とは、具体的には、APIプログラムを識別するAPI識別子と、APIプログラムを用いてアクセスする動作装置のモデル識別子を示すターゲットモデル識別子とを含む情報である。図3の例では、API識別子は、0c91356c-c16a-44c7-9709-448993b6ce07であり、ターゲットモデル識別子は、8699e324-3701-4c31-9a29-abdfe99ea93dである。
【0045】
readCurrentCh()は、動作装置13にアクセスして、動作装置13(本例では、テレビ)が受信している放送の受信チャンネルを得るためのAPIである。このAPIを用いて、例えば、受信チャンネルのチャンネル番号(chNum)と、チャンネル名(chName)と、放送提供者に一意に割り当てられた放送提供者識別子(providerId)を得る。
【0046】
setCurrentCh()は、動作装置13にアクセスして、動作装置13が受信する受信チャネルを設定するためのAPIである。このAPIを用いて、チャンネル番号を与えることで、動作装置13は、指定されたチャンネルに受信チャネルを設定する。
【0047】
readChList()は、動作装置13であるテレビが受信可能な受信チャネルの情報を得るためのAPIである。このAPIを用いることで、具体的には、受信可能な各受信チャネルのチャンネル番号(chNum)とチャンネル名(chName)と放送提供者識別子(providerId)とを得る。
【0048】
図4A〜Bは、ロジックプログラムの例を示す。
【0049】
図4A〜Bで示すロジックプログラムは、ユーザがTVの受信チャンネルを変えた場合に、その旨をtwitter(商品名)に投稿するプログラムの疑似コードである。
【0050】
このロジックプログラムでは、main()を用いて、60秒毎に受信チャネルを取得し、取得した受信チャンネルが、前回取得した受信チャンネルと比べて変更があった場合には、新しい受信チャンネルをtwitter(商品名)に送る。ここで、受信チャンネルのtwitter(商品名)への送信にはsendMessage()を用いており、この中でmakeMessage()により送信するメッセージを作成している。
【0051】
次に、図2を用いて、プログラム生成装置10の動作の詳細を説明する。
【0052】
プログラム生成装置10は、動作装置13から広告メッセージを受信すると、広告メッセージが含む情報(装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス)を記憶する。この記憶した情報を、動作装置情報と称する。また、プログラム生成装置10は、API蓄積装置12から広告メッセージを受信すると、広告メッセージが含む情報(装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス、API取得URL)を記憶する。この記憶した情報を、API蓄積装置情報と呼ぶ。また、プログラム生成装置10は、プログラム実行装置14から広告メッセージを受信すると、広告メッセージに含まれる情報(装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス)を記憶する。この記憶した情報を、プログラム実行装置情報と呼ぶ。
【0053】
次に、プログラム生成装置10の構成を説明する。
【0054】
図5は、にプログラム生成装置10の構成を示すブロック図である。
【0055】
広告メッセージ処理部106は、通信処理部101を介して、広告メッセージを受信する。そして、広告メッセージが含む装置種別を基に、広告メッセージを送信した装置の種別を判断する。広告メッセージに含まれる装置種別が動作装置である場合、動作装置情報を抽出し、動作装置情報保持部107に送信する。広告メッセージに含まれる装置種別がAPI蓄積装置である場合、API蓄積装置情報を抽出し、API蓄積情報保持部108に送信する。広告メッセージに含まれる装置種別がプログラム実行装置である場合、プログラム実行装置情報を抽出し、プログラム実行装置情報を、プログラム実行情報保持部109に送信する。
【0056】
動作装置情報保持部107は、動作装置情報を保持する。また、ヒューマンインタフェース処理部110又はAPIプログラム取得処理部102に、保持している動作装置情報を送信する。
【0057】
API蓄積装置情報保持部108は、API蓄積装置情報を保持する。また、ヒューマンインタフェース処理部110又はAPIプログラム取得処理部102に、保持しているAPI蓄積装置情報を送信する。
【0058】
プログラム実行装置情報保持部109は、プログラム実行装置情報を保持する。また、ヒューマンインタフェース処理部110又は実行プログラム送信処理部105に、保持しているプログラム実行装置情報を送信する。
【0059】
ヒューマンインタフェース処理部110は、ディスプレイへの画面出力やマウスからの入力を処理する。ヒューマンインタフェース処理部110は、例えば、Webブラウザで実現される。
【0060】
ヒューマンインタフェース処理部110は、プログラム蓄積サーバ16が保有するロジックプログラムのリストについて、ロジックプログラム選択画面を生成し、表示する。図6は、ヒューマンインタフェース処理部110が、画面にロジックプログラム選択画面を表示した場合の例を示す。図6では、ロジックプログラム選択画面の例を示す図である。図6の例では、プログラム蓄積サーバ16が、2つのロジックプログラムを保有する場合の例である。2つのロジックプログラムは、「視聴チャンネルをtwitter(商品名)へ投稿」と「Facebook(商品名)で人気の番組を録画予約」である。尚、以後の説明では、いずれかのロジックプログラムを選択したあとの説明をする場合、「視聴チャンネルをtwitter(商品名)へ投稿」の方のロジックプログラムを選択したことを前提とした説明を行う。
【0061】
ヒューマンインタフェース処理部110は、動作装置情報保持部107に蓄積されている動作装置情報を用いて動作装置選択画面を生成し、表示する。ヒューマンインターフェース部110は、例えば、動作装置情報を、プログラム蓄積サーバ16に送信し、プログラム蓄積サーバ16が、モデル識別子から機器種別を表す文字列(TV,PVR,蓄電池、エアコン、太陽電池パネル、電力メータ)とアイコンに変換して画面を生成し、その画面を表示することができる。また、ヒューマンインターフェース部110は、文字列やアイコンを動作装置情報として、動作装置13から取得して、表示することも可能である。
【0062】
図7は、ヒューマンインターフェース処理部110が、画面に動作装置選択画面を表示した場合の例を示す図である。図7の例では、TVとPVRと蓄電池とエアコンと太陽電池パネルと電力メータのアイコンと文字列を表示する例を示している。
【0063】
ヒューマンインターフェース処理部110は、更に、ロジックプログラム選択画面で選択されたロジックプログラム選択された場合に、選択されたロジックプログラムを動作させることができない動作装置13について、動作装置選択画面にて、選択不可能であることを表示してもよい。例えば、選択不可能であることを示す表示として、グレイアウトあるいは非表示とする表示を行う。ロジックプログラムとして「視聴チャンネルをtwitter(商品名)へ投稿」を選択した場合、実行可能であるTVとPVRを通常表示し、それ以外の動作装置をグレイアウト表示又は非表示とする。尚、以降の説明では、動作装置選択画面で、いずれかの装置が選択されたことを前提とした説明をする場合、TVを選択したとして説明する。
【0064】
ヒューマインタフェース処理部110は、ロジックプログラム選択画面で選択された動作装置のAPIプログラムに対応するロジックプログラムを取得するようロジックプログラム取得部103に通知する。
【0065】
ヒューマンインタフェース処理部110は、プログラム実行装置情報保持部109に保持されたプログラム実行装置情報を基に、プログラム実行装置選択画面を表示する。図8に、プログラム実行装置選択画面の一例を示す。ヒューマンインタフェース処理部110は、プロがラム実行装置選択画面を生成する際、プログラム実行装置情報をプログラム蓄積サーバ16に送信し、プログラム蓄積サーバ16にてモデル識別子から機器種別を表す文字列(携帯電話、PC)とアイコンに変換して画面を生成することができる。また、これらのアイコンや文字列の情報も、プログラム実行装置情報として、プログラム実行装置14から取得することも可能である。また、ヒューマンインタフェース処理部110は、更に、機器種別を表す文字列だけでなく、個々のプログラム動作装置13にユーザが付与した名称(健一、健二、Rose)をプログラム実行装置情報に含め、表示することもできる。図8に、その例を示している。
【0066】
ヒューマンインタフェース処理部110は、外部から選択されたプログラム実行装置14に対して、実行プログラムを送信するように、実行プログラム送信処理部105に通知する。
【0067】
以上が、ヒューマンインタフェース処理部110に関する説明である。
【0068】
APIプログラム取得処理部102は、API蓄積情報保持部108に蓄積されているAPI蓄積情報を基に、API蓄積装置12から、APIプログラムを取得する。具体的には、API蓄積情報に含まれるAPI取得URLに、通信処理部101を介してアクセスし、APIプログラムを取得する。APIプログラム取得処理部102は、取得したAPIプログラムを実行プログラム生成部105に送る。また、取得したAPIプログラムのAPI識別子をロジックプログラム取得処理部103に送る。
【0069】
ロジックプログラム取得処理部103は、プログラム蓄積サーバ16から、ヒューマンインタフェース処理部110によりロジックプログラム選択画面で選択されたロジックプログラムを取得する。
【0070】
典型的なケースでは、ロジックプログラム蓄積サーバ16がWebサーバ機能を有し、ロジックプログラム選択画面を提供する。この際、ロジックプログラム取得処理部103は、API識別子をプログラム蓄積サーバ16に送り、プログラム蓄積サーバ16はこのAPI識別子に基づきプログラム生成可能なロジックプログラムのみを表示することが好ましい。
【0071】
ロジックプログラム取得処理部103のアクセスするプログラム蓄積サーバ16のURLは予め与えられているものとする。このURLは、典型的には、Google(商品名)のような検索サービスを用いて得る。
【0072】
ロジックプログラム取得処理部103は、取得したロジックプログラムを実行プログラム生成部105に送信する。
【0073】
実行プログラム生成部105は、APIプログラム取得処理部102から受信したAPIプログラムとロジックプログラム取得処理部103から取得したロジックプログラムとを用いて、実行プログラムを生成し、実行プログラム送信処理部105へ送信する。
【0074】
図9A〜Eは、図3A〜CのAPIプログラムと、図4A〜Bのロジックプログラムとから生成された実行プログラムの例を示す図である。図9A〜Eの例では、Java(登録商標)Scriptを用いているため、図3A〜Cで示したAPIプログラムと図4A〜Bで示したロジックプログラムとを連結するだけで、図9A〜Eの実行プログラムを実現できる。
【0075】
実行プログラムの生成方法には、様々なものがある。例えば、図9A〜Eで示すように、インタプリタ型の言語を用いる場合には、テキストデータで記述されたプログラムの連結で行うことが望ましい。インタプリタ型の言語として、例えば、Java(登録商標)やRuby(商品名)がある。また、実行プログラムの生成に、C言語のようなコンパイラ型の言語を用いる場合には、プログラム実行装置14上にコンパイラを用意する。そして、プログラム生成装置100の実行プログラム生成部105が、APIプログラムとロジックプログラムとをコンパイルする方法を記述したmakefileを生成する。このように、コンパイラ型の言語を用いる場合、実行プログラムは、APIプログラムとロジックプログラムとmakefileとを含む情報としてもよい。
尚、実行プログラムの生成に、コンパイラ型の言語を用いる場合であっても、プログラム実行装置14のプログラム実行環境を示す識別子をプログラム実行装置14からの広告メッセージに含めることで、実行プログラム生成部105にて、プログラム実行装置14で実行プログラムが動作するようクロスコンパイルを行うことも可能である。
【0076】
実行プログラム送信処理部105は、実行プログラム生成部105から受信した実行プログラムを、ヒューマンインタフェース処理部110の指示に従い、プログラム実行装置14に通信処理部101を介して送信する。
【0077】
通信処理部101は、あらかじめ定められた通信手順に従い、ネットワーク17とのデータの送受信を行う。
【0078】
プログラム実行装置14は、プログラム生成装置10から実行プログラムを受信すると、受信した実行プログラムを実行する。図9A〜Eで示した実行プログラムの場合、プログラム実行装置14は、動作装置13(TV)に定期的にアクセスし、前回アクセスしたときと今回アクセスしたときとで、受信チャンネルに変更がある場合に、アプリケーションサーバ15(twitter(商品名))に通知する。通知するメッセージは、例えば、「いま、Nippon TVを見ています」である。
【0079】
以下では、本実施形態にかかるシステムを用いた場合の効果を説明する。
【0080】
例えば、ユーザがTVを買い替えた場合を想定する。つまり、図1のネットワーク17に接続された動作装置13の機能が変わった場合を想定する。例えば、買い替えたTVがEPG(Electronic Program Guide :電子番組表)機能が追加されていた場合を考える。このように、買い換えたTVが、新しい機能が追加されていた場合、APIプログラムとロジックプログラムも、この機能に対応するプログラムとすることで、この機能を活用した実行プログラムを実現できる。例えば、新しいTVのAPIプログラムを、図3A〜Cに示したプログラムにさらに電子番組表データをTVから取得するgetEPGInfo()を追加したプログラムとする。そして、ロジックプログラムを、getEPGInfo()に対応するロジックプログラムとする。プログラム実行装置14は、このような、ロジックプログラムとAPIプログラムとから生成される実行プログラムを用いて、例えば、アプリケーションサーバ15にメッセージを通知する際に、受信チャネルで受信している番組名に変換して、「いま、Nippon TVのドラマ“春来たる”を見ています」というより詳細なメッセージを作成することができる。
【0081】
従来は、実行プログラムは、標準通信仕様に依存したプログラムであったため、標準通信仕様が変化しない限り、このように動作装置13の機能の変化に合わせた柔軟なプログラムを実現できず、動作装置13の機能に合わせたサービス提供を実現できなかった。しかし、本実施例では、動作装置13の機能に応じたAPIプログラムを実現でき、そのAPIプログラムに合わせたロジックプログラムを作ることで、動作装置13の機能を十分に生かした多様な実行プログラムを実現でき、多様なサービスを実現できることとなる。
【0082】
尚、APIプログラムは、動作装置13(TV)の製造メーカが作成することが好ましい。また、ロジックプログラムは、製造メーカを含む不特定多数が作成し、例えばネット上のサーバにアップロードできることが好ましい。APIプログラムを、製造メーカが作成すると、APIプログラムを動作装置13の進化に合わせて作成することができる。また、ロジックプログラムを不特定多数の者が作成すると、動作装置13の進化に合わせて作成することができる。
【0083】
また、本実施例では、実行プログラムを動作装置13と別に設け、プログラム実行装置14が、アプリケーションサーバ15と動作装置13にアクセスし、アプリケーションサーバ15と動作装置13との連携を実現している。このようにすることで、例えば、データサイズが大きすぎて扱えないなどの理由で、旧型の動作装置13では進化したアプリケーションサーバ15と直接連携できない場合でも、プログラム実行装置14が、新しいアプリケーションサーバ15と旧型の動作装置13との連携を実現することができる。尚、プログラム実行装置14は携帯電話やPCのようなアプリケーションサーバ15のサービスを利用する機器であることが望ましい。
【0084】
尚、第1の実施形態では、アプリケーションサーバ15、プログラム蓄積サーバ16、動作装置13、プログラム生成装置10、プログラム蓄積サーバ16、動作装置13、API蓄積装置12各々が一台である例を説明した。しかしながら、各々の装置が複数台ある場合にも本実施形態は適用可能である。
【0085】
例えば、アプリケーションサーバ15が複数台ある場合について説明する。この場合、プログラム実行装置14は、Facebook(商品名)の掲示板にて人気の放送番組を取得し、この放送番組を動作装置13(PVR)に録画予約し、録画したこの番組が再生された場合にその旨をtwitter(商品名)に通知する、という実行プログラムを実行できる。
【0086】
次に、動作装置13が複数存在する場合を説明する。例えば、動作装置13が温度計とエアコンである場合、実行プログラム実行装置14は、温度計から気温を取得し、これが目標値になるようエアコンの設定温度を変更する実行プログラムを実行できる。
【0087】
また、本実施形態では、IPプロトコルを用いた場合を説明したが、IPv6プロトコルなど、その他の通信プロトコルにも適用可能である。
【0088】
また、本実施形態のネットワークのメディアは有線・無線のどちらでも使用することが可能である。
【0089】
また、第1の実施形態に係るプログラム生成装置10は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、通信処理部1とAPIプログラム処理部102とロジックプログラム取得処理部103と実行プログラム生成部104と実行プログラム送信処理部105と広告メッセージ処理部106と動作装置情報保持部107とAPI蓄積装置情報保持部108とプログラム実行装置情報保持部109とヒューマンインタフェース処理部110とは、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、プログラム生成装置10は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD−ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、動作装置情報保持部107とAPI蓄積装置情報保持部108とプログラム実行装置情報保持部とは、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD−R、CD−RW、DVD−RAM、DVD−Rなどの記憶媒体などを適宜利用して実現することができる。
【0090】
<変形例>
次に、第1の実施形態の変形例を説明する。
【0091】
図10は、第1の実施形態の変形例にかかるシステムを示すブロック図である。
【0092】
第1の実施形態の変形例にかかるシステムにおいては、第1の実施形態で説明した動作装置13とAPI蓄積装置12とが一体となっている点と、プログラム実行装置14とプログラム生成装置10とが一体となっている点が異なる。以下では、動作装置13とAPI蓄積装置12とが一体となった装置を、動作装置20と称する。動作装置20は、API蓄積装置12の機能を備えたAPI蓄積部20Aを備えている。また、プログラム実行装置14とプログラム生成装置10とが一体となった装置を、プログラム実行装置22と称する。プログラム実行装置22は、プログラム生成装置10の機能を備えたプログラム生成部22Aを備えている。
【0093】
各々の装置の機能は、第1の実施形態と説明したものと同様であるため、各々の装置の説明は省略する。
【0094】
尚、動作装置20が備えるAPI蓄積部20Aは、動作装置20にアクセスするためのAPIプログラムを蓄積するものとする。第1の実施例のAPI蓄積装置12は、複数の動作装置20がある場合には、複数の動作装置20のAPIプログラムをまとめて蓄積して管理することを想定していたが、本変形例では、動作装置20毎に、動作装置20に対応したAPIプログラムを記憶するものであるからである。尚、動作装置20が、動作装置20自身にアクセスするための複数のAPIプログラムを記憶することは、想定できる。つまり、動作装置20に、アクセスして、実現したい機能により複数のAPIプログラムを想定できるからである。
【0095】
次に、第1の実施形態にかかる変形例のシステムにおける動作を説明する。図11は、図10のシステムにおける動作シーケンスを示す図である。
【0096】
また、尚、本変形例のプログラム実行装置22は、図5に示すような、プログラム生成装置10が備える構成に加えて、プログラム実行装置10が備える機能、つまり、プログラム生成装置10が生成した実行プログラムを実行するプログラム実行部のような機能を備える。尚、プログラム実行装置22は、図5で示した実行プログラム送信処理部105は、備えていなくてもよい。
【0097】
まず、動作装置20は、定期的に広告メッセージをブロードキャストあるいはマルチキャストする(S201)。ここで、広告メッセージは、例えばIPパケットにて運ばれる。広告メッセージは、装置種別とプロバイダ識別子とモデル識別子と個体識別子と装置IPアドレスとを含む。
【0098】
装置種別は、動作装置20の種別(例えば、TVであるかやPVRであるか)を識別する識別子である。
【0099】
プロバイダ識別子は、その装置を製造したメーカを識別する識別子である。
【0100】
モデル識別子は、装置のモデルを識別する識別子である。モデル識別子は、例えば、UUID(Universally Unique Identifier)を用いることが好ましい。UUIDを用いることにより、製造メーカが異なるモデルでも異なる識別子を割り当てることができる。
【0101】
個体識別子は、装置を一意に識別する識別子である。個体識別子は、例えば、UUIDを用いることが好ましい。尚、必ずしも、個体識別子単体で、装置1つを重複なく識別するようにしなくてもよい。例えば、モデル識別子と個体識別子の組で、重複ない値を割り当てることができればよい。
【0102】
装置IPアドレスは、装置に割り当てられたIPアドレスである。
【0103】
以上が、広告メッセージの説明である。
【0104】
次に、第1の実施形態の変形例のシステムの動作説明に戻る。
【0105】
次に、プログラム実行装置22は、動作装置20からAPIプログラムを受信する(S202)。このとき、プログラム実行装置22は、動作装置20からの広告メッセージにてそのAPI取得URL(例えば,http://192.168.0.1/api/)を知り、そのIPアドレスに向けてHTTPにてAPIプログラムを要求する。
【0106】
次に、プログラム実行装置22は、プログラム蓄積装置16からロジックプログラムを受信する(S203)。このとき、プログラム実行装置22は、予めプログラム蓄積装置16のIPアドレスを保持していることが望ましい。
【0107】
次に、プログラム実行装置22は、APIプログラムとロジックプログラムから実行プログラムを生成し、この実行プログラムを実行する。プログラム実行装置22は、実行プログラムを実行する際、アプリケーションサーバ15および動作装置20にネットワーク17を介してアクセスする(S204、S205)。
【0108】
次に、動作装置20の構成を説明する。図12は、動作装置20の構成を示すブロック図である。
【0109】
本体処理部207は、動作装置20の本来の動作に関わる処理を行う。ここで、本来の動作とは、例えば、動作装置20がTVである場合には、リモコン信号および放送波信号および外部ボタンの押下に従い、TV放送信号を受信し、放送信号を復調し、画面表示を行うといった動作である。
【0110】
通信処理部201は、あらかじめ定められた通信手順に従い、ネットワーク17とのデータの送受信を行う。
【0111】
広告メッセージ送信部202は、予め設定されている情報を用いて、広告メッセージを定期的に送信する。ここで、広告メッセージが含むAPI取得URLは、後述するAPIプログラム蓄積部206に複数のAPIプログラムが保持されている場合には、各々のAPIプログラムを指定して取得できるように、APIプログラム毎にURLを用意することが好ましい。
【0112】
APIプログラム蓄積部206は、APIプログラムを保持する。複数のAPIプログラムを保持できることが好ましい。
【0113】
APIプログラム更新処理部203は、APIプログラム蓄積部206内のAPIプログラムの追加・削除・更新処理を、ネットワーク17を介して行う。
【0114】
APIプログラム送信処理部204は、ネットワーク17を介して、APIプログラム取得要求を受信すると、APIプログラム取得要求に含まれるAPI取得URLに従って要求されたAPIプログラムをAPIプログラム蓄積部206より抽出し、ネットワーク17を介して要求者に送信する。
【0115】
動作コマンド処理部205は、ネットワーク17を介して、動作コマンドを受信すると、これに従って本体処理部207へ制御コマンドを送信する。また、動作コマンドが動作状態の取得を要求する場合には、本体処理部207から対応する情報を抽出し、当該抽出した情報を、ネットワーク17を介して動作コマンド送信者に送信する。
【0116】
本実施例の動作装置20では、APIプログラムはプログラム実行装置22に向けて高々一度送信すればよい。これに対して、従来のHTTPサーバを有し、外部のWebブラウザによりネットワークを介して制御される制御装置では、Webブラウザをユーザが操作し、これに対応した制御コマンドを、HTTP POSTあるいはGETデータとして動作装置に送信し、これを受信した動作装置は、制御コマンドに従った動作を行うと同時に、応答を返す。この応答には、続く制御コマンドをWebブラウザから送信するためのプログラムが含まれており、結果として制御コマンドを受信するたびに制御のためのプログラムを動作装置は送信している。本実施例では、APIプログラムは高々一度送信すればよいため、ネットワークに与える負荷を小さくでき、さらに動作装置20の通信処理に要する処理量を削減することができる。
【0117】
以上、第1の実施形態の変形例を説明したが、第1の実施形態の変形例は、上述したように、動作装置20とプログラム実行装置22とが、各々、第1の実施形態で説明した2つの装置を一体とした点が異なり、その他の点は同様の機能である。したがって、本変形例のシステムによれば、第1の実施形態で説明した効果と同様の効果を達成することができる。
【0118】
続けて、第2の実施形態と第3の実施形態を説明するが、第2の実施形態と第3の実施形態は、第1の実施形態で説明したシステムの具体例である。
【0119】
<第2の実施形態>
図13は、第2の実施形態にかかるシステムを示すブロック図である。
【0120】
第2の実施形態にかかるシステムは、プログラム蓄積サーバ16と、アプリケーションサーバ15A及び15Bと、電気自動車30と、がネットワーク17介して接続されている。電気自動車30は、スマートフォン30Aと蓄電池30Bとナビゲーション装置30Cとを有する。蓄電池30Bとスマートフォン30Aとは、車内ネットワーク30D(ex 無線LAN, Bluetooth, CAN(Car area network))を介して接続されている。ナビゲーション装置30Cとスマートフォン30Aとは、車内ネットワーク30Dにて接続されている。尚、図13の例では、蓄電池30Bとスマートフォン30Aとの間、ナビゲーション装置30Cとスマートフォン30Aとの間、各々の間のネットワークが同一の車内ネットワーク30Dであるとしたが、各々のネットワークが異なるネットワークであってもよい。
【0121】
ここで、蓄電池30B及びナビゲーション装置30Cは、図12で示した第1の実施形態の変形例の動作装置20と同様の機能を有する。蓄電池30B及びナビゲーション装置30Cは、動作装置20と同様、APIプログラム蓄積部206を有している。スマートフォン30Aは、第1の実施形態の変形例のプログラム実行装置22と同様の機能を有する。このように第2の実施形態にかかるシステムは、動作装置20が2台ある例を示している。
【0122】
スマートフォン30Aは、蓄電池30BのAPIプログラム蓄積部206に蓄積されているAPIプログラムを用いることにより、ネットワークを介して蓄電池30Bにアクセスすることで、蓄電池30Bの予め定められた短期間毎(例えば、1分毎)の充放電量と、電気残量、温度を取得することができる。
【0123】
また、スマートフォン30Aは、ナビゲーション装置30CのAPIプログラム蓄積部206に蓄積されているAPIプログラムを用いることにより、ネットワークを介してナビゲーション装置30Cにアクセスすることで、電気自動車30の現在の位置情報および速度情報(進行方向を含む)を得ることができる。
【0124】
次に、第2の実施形態のシステムの動作を説明する。
【0125】
図14は、第2の実施形態にかかるシステムの動作を示すシーケンス図である。
【0126】
まず、蓄電池30Bは、広告メッセージを定期的に送信する(S301)。
【0127】
また、ナビゲーション装置30Cは広告メッセージを定期的に送信する(S302)。
【0128】
次に、スマートフォン30Aは、S301及びS302で取得した広告メッセージに含まれるAPI取得URLを用いて、蓄電池30B及びナビゲーション装置30CからAPIプログラムを取得する(S303、S304)。
【0129】
次に、スマートフォン30Aは、予め設定されたプログラム蓄積装置16から、ロジックプログラムを取得する(S305)。そして、スマートフォン30Aは、ロジックプログラムと蓄電池30B及びナビゲーション装置30Cから取得したAPIプログラムとから、実行プログラムを生成する。そして、スマートフォン30Aは、実行プログラムを実行する。実行プログラムの実行の際、スマートフォン30Aは、蓄電池30Bとナビゲーション装置30Cとアプリケーションサーバ15及び15Bにアクセスする(S306〜S309)。
【0130】
より具体的には、スマートフォン30Aは、実行プログラムを実行することで、ナビゲーション装置30Cにアクセスして(S307)、位置情報及び速度情報を取得し、取得した位置情報及び速度情報を、アプリケーションサーバ15Aに送信し、周辺地図情報を取得する(S308)。ここで、アプリケーションサーバ15Aは、周辺地図情報を提供するサービスを行っているとする。
【0131】
また、スマートフォン30Aは、実行プログラムを実行することで、蓄電池30Bから放電量と電気残量と温度とを取得し(S306)、S307で取得する速度情報と併せて、アプリケーションサーバ15Bに送信し、走行可能距離を得る(S309)。ここで、アプリケーションサーバ15Bは、電気自動車30の走行可能距離算出サービスを行っているとする。
【0132】
また、スマートフォン30Aは、実行プログラムを実行することで、周辺地図情報と走行可能距離とから、走行可能範囲31Cをスマートフォン30Aの画面31A上に表示する。
【0133】
図15に、スマートフォン30Aが、画面上に表示する走行可能範囲31Cの例を示す。
【0134】
図15の例では、電気自動車30が右方向に進行していることを前提としているため、現在地31Bを中心とした地図ではなく、現在地31Bより右側の領域を多く表示している。また、図15の例では、右側に表示している道路の混雑が多いことを前提としているため、赤線で囲まれた走行可能領域は、右側は左側と比べて狭くなっている。
【0135】
以上の例のように、複数の電気自動車30が自身の位置をアプリケーションサーバ15Bに送信することで、アプリケーションサーバ15Bは、道路の混雑状況を加味した走行可能距離を計算することができる。また、蓄電池30Bの電気残量を正確に求めることは一般に難しいが、走行可能距離の計算をアプリケーションサーバ側で実行することで、実データの収集およびこれに基づく算出アルゴリズムの改良、そして新しいアルゴリズムの導入が可能である。また、この改良後の算出アルゴリズム若しくは新たに導入したアルゴリズムをロジックプログラムとしてスマートフォン30Aに送信することで、スマートフォン30Aは、電気自動車30設計当時の計算能力では実行できない複雑な算出アルゴリズムを実行することができる。この場合は、スマートフォン30Aがアプリケーションサーバと常に通信する必要が無く、スマートフォン30Aの消費電力を削減するという効果もある。
【0136】
<第3の実施形態>
図16は、第3の実施形態に係るシステムを示すブロック図である。
【0137】
第3の実施形態に係るシステムは、プログラム蓄積サーバ16と、二つのアプリケーションサーバ15A及び15Bと、エネルギー管理サーバ41と建物40Aと建物40Bとが、ネットワーク17を介して接続されている。
【0138】
また、建物40Aは、電力計401Aと蓄熱装置402Aとを備えている。電力系401Aと蓄熱装置402Aとはネットワーク403Aを介して接続されている。建物40Bは、電力系401Bと蓄熱装置402Bとを備えている。電力系401Bと蓄熱装置402Bとは、ネットワーク403Bを介して接続されている。
【0139】
本実施例のエネルギー管理サーバ41は、第1の実施形態の変形例のプログラム実行装置22の機能を有する。また、蓄熱装置402A及び402Bは、動作装置20の機能を有する(図10を参照)。
【0140】
電力計401Aは、建物40Aの消費電力を測定し、測定結果をアプリケーションサーバ15Aへ送信する。電力計401Aの消費電力測定の細かさは様々な形態を考えることができ、建物内のフロア毎や部屋毎やコンセント毎に消費電力を測定できる。電力計401Bも同様の機能を有する。
【0141】
蓄熱装置402Aは、ヒートポンプなどの熱発生部(又は吸熱部)と、水のタンクによる温熱又は冷熱を蓄積する熱蓄積部とを備える。熱蓄積部は、冷熱については、冷水ではなく氷の形で熱を蓄積することも可能である。蓄熱装置402Aは、例えば深夜のような電気料金(あるいはガス料金)の安い時間帯の電力でヒートポンプを駆動し得られた熱を蓄積する。蓄積した熱は、電気料金の高い時間帯に給湯、空調、床暖房等の用途に使用することで、ユーザには電気料金削減、電気会社にはピーク電力の削減の効果を実現できる。時間とともに、蓄積した熱は環境へ散逸する。したがって、次の蓄熱タイミング(一般には翌日の深夜)までに、必要最小限の熱量を見積もり、これを蓄熱することが重要である。蓄熱装置402Bも同様の機能を有する。
【0142】
エネルギー管理サーバ41は、蓄熱量を見積もり、見積もった蓄熱量を蓄熱装置402Aに指示する。
【0143】
アプリケーションサーバ15Bは、例えば気象庁の天気予報サイトであり、本日から翌日までの天気情報を提供している。
【0144】
次に、第3の実施形態にかかるシステムの動作シーケンスを説明する。図17は、第3の実施形態に係るシステムの動作を示すシーケンス図である。
【0145】
まず、電力計401Aと電力計401Bは、定期的に、アプリケーションサーバ15Aに対して消費電力量を通知する(S401、S402)。この消費電力量は、予め定められた期間(例えば、一分)毎に消費した電力量である。この消費電力の測定期間と消費電力量の通知間隔は一致している必要は無い。通知する消費電力量には、電力を消費した時刻情報が記されていることが望ましい。時刻情報は、消費電力測定期間と消費電力量通知間隔とが一致している場合には、省略することが可能である。
【0146】
次に、エネルギー管理サーバ41は、電力計401A及びBのAPIプログラムを、電力計401A及びBから取得する(S403、S404)。尚、本実施例では、説明を省略しているが、電力計401A及びBは、広告メッセージをエネルギー管理サーバ41のアドレス宛てに送信することで、エネルギー管理サーバ41は、電力計401A及びBからAPIプログラムを取得可能となる。尚、APIプログラムの取得先は、必ずしも電力計401A及びBである必要はなく、実施例1で示したように、電力計401A及びB以外の機器から取得する構成も可能である。
【0147】
次に、エネルギー管理サーバ41は、ロジックプログラムをプログラム蓄積サーバ16から取得する(S405、S409)。ここで、エネルギー管理サーバ41が取得するロジックプログラムは、蓄熱装置のユーザが予め選択可能であることが好ましい。例えば、ユーザは、蓄熱装置の使用人数や家族構成(女性が3人いるなど)により、ロジックプログラムを選択する。ユーザは、ロジックプログラムを、例えばWebブラウザを使用して選択する。
【0148】
エネルギー管理サーバ41は、ロジックプログラムとAPIプログラムとから実行プログラムを生成し、実行プログラムを実行する。本実施形態では、蓄熱装置402Aと蓄熱装置402Bのユーザが異なる場合、蓄熱装置ごとに異なる実行プログラムを実行することが望ましい。
【0149】
エネルギー管理サーバ41は、実行プログラムを実行することで、アプリケーションサーバ15B、アプリケーションサーバ15Aより天候情報を取得し(S406、S410)、天気情報を用いて蓄熱装置402B、蓄熱装置402Aの蓄熱量を制御する(S407、S411)。
【0150】
さらに、アプリケーションサーバ15Aは、ユーザ毎の消費電力量の一定期間(例えば、一時間)毎の消費電力量を、例えば一カ月分のデータ提供している。そして、ユーザは、Webブラウザを使って、その一カ月分のデータにアクセスすることが可能である。アプリケーションサーバ15Aがこのような機能を備えることで、例えば、Facebook(商品名)の友達関係のあるユーザ間で、これらの消費電力量を共有することも可能である。これにより、ユーザ間で電力節約のコツや、使用しているロジックプログラムの情報を共有することができる。そして、好みの(典型的には、家屋の大きさや断熱性能、あるいは家屋内の機器構成やライフスタイルの似た友人の中で、最も消費電力の少ない人間の使用しているロジックプログラム)ロジックプログラムを選び直すことも可能である。
【0151】
エネルギー管理サーバ41で実行されている実行プログラムのアルゴリズム例について説明する。図18は、エネルギー管理サーバ41で実行する実行プログラムの蓄熱量制御のアルゴリズムの例を示すフローチャートである。
【0152】
まず、深夜電力期間(例えば、AM0時からAM5時)開始前に、ユーザ家屋地域の翌日の天候情報をアプリケーションサーバ15Aから取得する(S501)。本例では、天候情報として気温を取得する。なお、天候情報は、気温に限られない。例えば、太陽光発電装置や風力発電装置をユーザが使用している場合には、その発電量を考慮するため日照量や風量を天候情報とする。
【0153】
次に、実行プログラムは、翌日の使用熱量を予測する(S502)。実行プログラムは、ユーザの熱使用履歴データ(日付、気温、使用熱量)を保持しており、その履歴データの中から翌日の気温に一致する気温に対応する使用熱量を抽出し、抽出した使用熱量の平均を取ることで、翌日の使用熱量を予測する。ここで、翌日の気温と一致する気温とは、気温が完全一致していなくてもよく、気温差がある一定値以内の気温であってもよい。また、抽出した使用熱量の平均を取る際に、単純な加重平均ではなくてもよい。例えば、新しいデータほど重みが大きい重み付き平均など様々な算出の方法が考えられる。また、熱使用履歴データは、一日毎ではなくより細かい時間粒度(例えば一時間毎)に保持してもよい。
【0154】
次に、実行プログラムは、S502で予測した使用熱量と同じ熱量を蓄熱するよう蓄熱装置に通知する(S503)。
【0155】
次に、実行プログラムは、定期的に蓄熱装置から使用熱量を取得し、これを熱使用履歴データに追加する(S504)。
【0156】
以上が、実行プログラムのアルゴリズムである。
【0157】
以上説明したように、エネルギー管理サーバ41において、ユーザが選んだロジックプログラムを動作させることにより、ユーザの使用機器や使用条件に適したエネルギー制御を実現することができる。また、Facebook(商品名)のようなソーシャルネットワークあるいは掲示板サービスと組み合わせることで、ユーザによる最適なロジックプログラムの選択を実現できる。
【0158】
以上説明した少なくとも1つの実施形態の効果は、機器の標準通信仕様の変更があるか否かにかかわらず、ネットワーク上のサービスを、機器の機能に合わせて、機器の機能を利用したサービスを提供できるようなプログラムを生成するプログラム生成装置を提供することができる。
【0159】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【0160】
10・・・プログラム生成装置、12・・・API蓄積装置、13、20・・・動作装置、14、22・・・プログラム実行装置、15、15A、15B・・・アプリケーションサーバ、16・・・プログラム蓄積サーバ、17、30D、403A、403B・・・ネットワーク、101、201・・・通信処理部、102・・・APIプログラム取得処理部、103・・・ロジックプログラム取得処理部、104・・・実行プログラム生成部、105・・・実行プログラム送信処理部、106・・・広告メッセージ処理部、107・・・動作装置情報保持部、108・・・API蓄積装置情報保持部、109・・・プログラム実行装置情報保持部、110・・・ヒューマンインタフェース処理部、20A・・・API蓄積部、22A・・・プログラム生成部、202・・・広告メッセージ送信部、203・・・API更新処理部、204・・・APIプログラム送信処理部、205・・・動作コマンド処理部、206・・・APIプログラム蓄積部、207・・・本体処理部、30・・・電気自動車、30A・・・スマートフォン、30B・・・蓄電池、30C・・・ナビゲーション装置、30D・・・ネットワーク、31A・・・画面、31B・・・現在地、31C・・・走行可能範囲、41・・・エネルギー管理サーバ、40A、40B・・・建物、401A、401B・・・電力計、402A、402B・・・蓄電装置。
【技術分野】
【0001】
本発明の実施形態は、プログラム生成装置に関する。
【背景技術】
【0002】
インターネットの発達に伴いパソコン以外の様々な機器が通信機能を有するようになってきている。通信機能を有する機器としては、例えば、携帯電話、電力メータ、エアコンやTV等の家電機器、そして車など多様な機器がある。
【0003】
一方、近年、パソコン以外の様々な機器が、通信機能を有するようになることに伴い、クラウドサービス等のネットワーク上のサービスを、通信機能を有する機器と連携した新たなサービス(以下、ネット連携サービスと称する。)を提供する動きがある。このようなネット連携サービスにより、より多様なサービスを、サービス提供を受けるユーザは受け取ることができる。なお、ネットワーク上のサービスは、例えば、当該サービスを提供するASP(Application Service Provider)がインターネット上に配置するサーバが提供する。ネット連携サービスの一例として、ネットワーク上のサービスがクラウド連携サービスである場合を考える。そして、例えば、クラウド連携サービスの一例として、クラウドサービスがtwitter(商品名)である場合であって、かつ通信機能を有する機器がテレビである場合を例に考える。この場合、クラウド連携サービスとして、ユーザのテレビの受信チャネルを自動的に取得して、twitter(商品名)上に、現在、見ているテレビのチャネルを自動的に投稿するサービスを想定できる。
【0004】
従来、機器の通信機能を設計する際に、その通信仕様(通信手順)は、例えばDLNA(Digital Living Alliance)のような標準策定団体にて、標準化が行われてきた。その結果、異なるメーカの機器であっても、同じ標準通信仕様に従うことが一般的であり、同一メーカの新機種と旧機種であっても、同一の通信仕様標準化により各機器が共通した標準通信仕様に従うことが一般的であった。
【0005】
また、従来、ネット連携サービスを実行するためプログラムは、標準通信仕様にしたがった機器と連携するための機能と、その機能を用いて実行するサービスを提供するための機能とを併せ持ったプログラムが生成されていた。つまり、ネット連携サービスを実行するためのプログラムは、標準通信仕様に依存したプログラムとなっていた。
【0006】
一般的に、クラウドサービス等のネットワーク上のサービス進化の速度は非常に速い一方で、機器の標準通信仕様の進化は遅い。機器の通信仕様の進化が遅い理由は、通信仕様の普及には時間がかかるためである。通信仕様の普及にかかる時間は、古い通信仕様との互換性の容易さや通信仕様を備える機器の買い替えサイクルに依存する。例えば、エアコンは10年という長い使用期間のため、同じ通信仕様を長く使い続けることが予想され、標準通信仕様の進化が遅いことが想定される。このため、クラウド連携サービス等のネットワーク上のサービスと通信機能を有する機器と連携したネット連携サービスは、クラウドサービス等のネットワーク上のサービスが進化しても、使用する標準通信仕様が進化しない故に、進化が難しいという課題がある。
【0007】
また、半導体技術の進化の速度は速く機器の機能は急速に進化する一方で、機器の標準通信仕様の進化は遅い。例えば、モデルチェンジにより機器に機能を追加しても、標準通信仕様がその機能をサポートしていない仕様である場合もある。このような場合、ネット連携サービスは、サービス提供に当たり、モデルチェンジにより機器に追加された追加機能を利用できないという課題がある。例えば、先述のクラウド連携サービスの一例を用いて考える。例えば、TVに、番組表を有する機能を追加した場合であって、標準通信仕様には、番組表を取得する機能を有しない場合を考える。この場合、クラウド連携サービスとして、番組表のデータを用いたサービスを提供できない。例えば、twitter(商品名)上に、現在、見ているテレビの番組名を自動的に投稿するサービスを提供できない。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2009-110300号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
本発明の一側面は、機器の標準通信仕様の変更があるか否かにかかわらず、ネットワーク上のサービスを、機器の機能に合わせて、機器の機能を利用したサービスを提供できるようなプログラムを生成するプログラム生成装置を提供することを目的とする。
【課題を解決するための手段】
【0010】
本発明の一観点にかかるプログラム生成装置は、制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第1プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第1サービスとを連携した連携サービスを実現する第2プログラムとを用いて、前記連携サービスを実現する第3プログラムを生成する生成部を有する。
【図面の簡単な説明】
【0011】
【図1】本発明の第1の実施形態にかかるシステムを示すブロック図。
【図2】図1のシステムにおける動作を示すシーケンス図。
【図3A】動作装置13がTVである場合のAPIプログラムの例を示す図。
【図3B】動作装置13がTVである場合のAPIプログラムの例を示す図。
【図3C】動作装置13がTVである場合のAPIプログラムの例を示す図。
【図4A】ロジックプログラムの例を示す図。
【図4B】ロジックプログラムの例を示す図。
【図5】図1のシステムにおけるプログラム生成装置10を示すブロック図。
【図6】ヒューマンインタフェース処理部110が、画面にロジックプログラム選択画面を表示した場合の例を示す図。
【図7】ヒューマンインターフェース処理部110が、画面に動作装置選択画面を表示した場合の例を示す図。
【図8】プログラム実行装置選択画面の一例を示す図。
【図9A】実行プログラムの例を示す図。
【図9B】実行プログラムの例を示す図。
【図9C】実行プログラムの例を示す図。
【図9D】実行プログラムの例を示す図。
【図9E】実行プログラムの例を示す図。
【図10】本発明の第1の実施形態の変形例にかかるシステムを示すブロック図。
【図11】図10のシステムにおける動作を示すシーケンス図。
【図12】図10の動作装置20の構成を示すブロック図。
【図13】本発明の第2の実施形態にかかるシステムを示すブロック図。
【図14】図13のシステムにおけるシーケンス図。
【図15】スマートフォン30Aが、画面上に表示する走行可能範囲31Cの例。
【図16】本発明の第3の実施形態にかかるシステムを示すブロック図。
【図17】図14のシステムにおけるシーケンス図。
【図18】図16のエネルギー管理サーバ41で事項する実行プログラムの蓄熱量制御のアルゴリズムを示すフローチャート。
【発明を実施するための形態】
【0012】
以下、本発明の実施の形態について、図面を参照しながら説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【0013】
<第1の実施形態>
図1は、本発明の第1の実施形態にかかるシステムを示すブロック図である。
【0014】
本発明の第1の実施形態に係るシステムは、プログラム生成装置10と、API蓄積装置12と、動作装置13と、プログラム実行装置14と、アプリケーションサーバ15と、プログラム蓄積サーバ16と、がネットワーク17を介して接続されている。
【0015】
動作装置13とは、ユーザに対してサービス動作を行う装置である。動作装置13は、例えばTVやPVR(Personal Video Recorder:ハードディスクレコーダ)である。
【0016】
アプリケーションサーバ15は、ネットワークを介して、サービス利用者に対して、サービスを提供するサーバである。アプリケーションサーバ15が、提供するサービスは、例えば、クラウドサービスである。
【0017】
API蓄積装置12は、APIプログラムを蓄積するとともに、ネットワーク17を介して、APIプログラムを他の装置に提供する装置である。ここで、API(Application Program Interface)プログラム(請求項1の第1プログラムに対応する。)は、動作装置13に、ネットワーク17を介してアクセスするための通信手順を実現するプログラムである。ここで、動作装置13に、ネットワーク17を介してアクセスするための通信手順は、動作装置13にアクセスして実現すること(例えば、動作装置13の制御若しくは、動作装置の機能の利用等)によって異なる。そして、動作装置13にアクセスして実現できることは、動作装置13が有する機能によって異なる。したがって、APIプログラムは、動作装置13が有する機能や、動作装置13にアクセスして実現したいことによって、異なるプログラムが割り当てられる。より具体的には、図1のシステムの動作装置13の機種が変わった場合、その機種に応じたAPIプログラムが生成される。また、複数の動作装置13がある場合、その動作装置13毎にAPIプログラムが生成される。また、一つの動作装置13に対して、実現したい目的に応じて、複数のAPIプログラムを生成することもある。
【0018】
プログラム蓄積サーバ16は、APIプログラムを利用するプログラムであって、アプリケーションサーバ15が提供するサービスと動作装置13とを連携させるプログラムであるロジックプログラム(請求項1の第2のプログラムに対応する。)を蓄積するとともに、ネットワーク17を介して他の装置に提供する装置である。
【0019】
プログラム生成装置10は、APIプログラムとロジックプログラムを基に、アプリケーションサーバ15が提供するサービスと動作装置13の機能とを連携させる実行プログラム(請求項1の実行プログラムに対応する。)を生成するとともに、実行プログラムをネットワーク17を介して他の装置に提供する装置である。ここで、実行プログラムは、後述するプログラム実行装置14が実行できるプログラムである。実行プログラムは、プログラム実行装置14が実行可能であればその形式を問わない。バイナリ形式のプログラムでなくてもよい。実行プログラムの形式は、例えば、Perl、Java(登録商標)Script、Ruby(商品名)、Java(登録商標)である。
【0020】
プログラム実行装置14は、実行プログラムを実行する機能を有する。
【0021】
図1では、アプリケーションサーバ15と、プログラム蓄積サーバ16と、プログラム生成装置10と、プログラム実行装置14と、動作装置13と、API蓄積装置12とが各々一台ずつである例を示しているが、各々複数台存在する構成してもよい。
【0022】
次に、図2を用いて、図1のシステムの動作を説明する。図2は、図1のシステムの通信シーケンスを示す図である。
【0023】
プログラム実行装置14と動作装置13とAPI蓄積装置12とは、定期的に、広告メッセージをブロードキャスト又はマルチキャストする(S101〜S103)。広告メッセージは、例えば、装置種別とプロバイダ識別子とモデル識別子と装置IPアドレスとを含む。ここで、広告メッセージは、例えばIPパケットを用いて運ばれる。
【0024】
ここで、広告メッセージが含む各情報の説明を行う。
【0025】
装置種別とは、プログラム実行装置14、API蓄積装置12、動作装置13各々を互いに識別する識別子である。また、装置種別は、動作装置13の種別も識別できる識別子であることが好ましい。動作装置の種別とは、例えば、TVやPVRであるかを示す種別である。
【0026】
プロバイダ識別子は、装置を製造したメーカを識別する識別子である。
【0027】
モデル識別子は、装置のモデルを識別する識別子である。モデル識別子は、例えば、UUID(Universally Unique Identifier)を用いることが好ましい。UUIDを用いることにより、製造メーカが異なるモデルでも異なる識別子を割り当てることができる。
【0028】
個体識別子は、装置を一意に識別する識別子である。個体識別子は、例えば、UUIDを用いることが好ましい。尚、必ずしも、個体識別子単体で、装置を一意に識別する識別子としなくてもよい。例えば、モデル識別子と個体識別子との組み合わせで、装置を一意に識別できるようにしてもよい。
装置IPアドレスは、装置に割り当てられたIPアドレスである。
【0029】
以上が、広告メッセージが含む情報の説明である。
【0030】
次に、図2を用いて、本実施形態のシステムの動作説明を続ける。
【0031】
次に、プログラム生成装置10は、API蓄積装置12から取得した広告メッセージを参照し、API蓄積装置12にAPIプログラムを要求し、APIプログラムを受信する(S104)。プログラム生成装置10は、APIプログラムを要求する際、API蓄積装置12から取得した広告メッセージに含まれる装置IPアドレス(API取得URL:例えば,http://192.168.0.1/api/)に向けて、HTTPを用いて、APIプログラムを要求する。
【0032】
次に、プログラム生成装置10は、プログラム蓄積サーバ16から取得した広告メッセージを参照し、プログラム蓄積サーバ16にロジックプログラムを要求し、ロジックプログラムを受信する(S105)。この際、プログラム生成装置10は、ロジックプログラムを要求する際、プログラム蓄積サーバ16から取得した広告メッセージに含まれる装置IPアドレスにむけて、ロジックプログラムを要求する。
【0033】
次に、プログラム生成装置10は、取得したAPIプログラムとロジックプログラムを用いて、実行プログラムを生成する。そして、生成した実行プログラムをプログラム実行装置14に向けて送信する(S106)。ここで、プログラム生成装置10は、広告メッセージで取得したプログラム実行装置14のIPアドレスに向けて、HTTPを用いて、実行プログラムを送信する。
【0034】
次に、プログラム実行装置14は、受信した実行プログラムを実行する。プログラム実行装置14は、実行プログラムを実行する際に、アプリケーションサーバ15および動作装置13にネットワーク17を介してアクセスする(S107、S108)。
【0035】
プログラム実行装置14が実行プログラムを実行することで、動作装置13とアプリケーションサーバ15との連携を実現することができる。連携動作の詳細については、具体例を用いて、後述する。
【0036】
以上が、図1のシステムの動作シーケンスの説明である。
【0037】
本実施形態では、動作装置13毎に動作装置13にアクセスするための通信手順として、システム全体であらかじめ決められた標準仕様でなく、動作装置13毎に定められたAPIプログラムを用いている。通信仕様が、システム全体で定められていないため、動作装置13とアプリケーションサーバ15とを独立に開発・設置することが可能となる。また、動作装置13の機能に応じたAPIプログラムを実現できるため、APIプログラムを用いた実行プログラムで、動作装置13にアクセスすることで、動作装置13の機能を生かした連携サービスを実現できる。
【0038】
また、本実施形態では、実行プログラムを、動作装置13とは別のプログラム実行装置14にて実行する。この結果、実行プログラムが、動作装置13では扱えない計算量を要求する場合であっても、動作させることができる。特に、アプリケーションサーバ15がASPによるインターネット上のサーバであり、プログラム実行装置14がソフトフォーンやPCのようなASPの提供するサービス(ASPサービス)を利用する装置である場合には、急速に進化するASPサービスに追従する計算能力をプログラム実行装置14が有することが期待できる。
【0039】
次に、APIプログラムの一例を説明する。尚、本実施例では、動作装置13にアクセスするためのプログラムとして、APIを含むプログラムであるAPIプログラムを例にとって説明するが、これに限られない。つまり、動作装置13にアクセスする手順を示すプログラムであればよく、必ずしも、APIを有しているプログラムである必要はない。
【0040】
図3A〜Cは、動作装置13がTVである場合のAPIプログラムの例を示す図である。
【0041】
図3A〜Cで示したAPIプログラムはJava(登録商標)Scriptで書いた疑似コードである。APIプログラム(ファイルapi.js)は、動作装置13毎に設定され、外部の装置(例えば、プログラム実行装置14)は、このAPIプログラムで定められた通信手順に従って、動作装置13にアクセスすることができる。尚、APIプログラムは、本実施例では、APIプログラム蓄積装置12が保持していてもよいし、当該APIプログラムを用いてアクセスできる動作装置13に保持させていてもよい。
【0042】
図3のAPIプログラムでは、<API_Functions>と</API_Functions>との間に、動作装置13にアクセスするためのAPI関数名が記されている。図3の例では、getApiInfo() 、readCurrentCh() 、setCurrentCh() 、readChList() といった関数が定められている。
【0043】
getApiInfo()は、動作装置13にアクセスして、APIプログラムに関する情報を得るためのAPIである。
【0044】
ここで、APIに関する情報とは、具体的には、APIプログラムを識別するAPI識別子と、APIプログラムを用いてアクセスする動作装置のモデル識別子を示すターゲットモデル識別子とを含む情報である。図3の例では、API識別子は、0c91356c-c16a-44c7-9709-448993b6ce07であり、ターゲットモデル識別子は、8699e324-3701-4c31-9a29-abdfe99ea93dである。
【0045】
readCurrentCh()は、動作装置13にアクセスして、動作装置13(本例では、テレビ)が受信している放送の受信チャンネルを得るためのAPIである。このAPIを用いて、例えば、受信チャンネルのチャンネル番号(chNum)と、チャンネル名(chName)と、放送提供者に一意に割り当てられた放送提供者識別子(providerId)を得る。
【0046】
setCurrentCh()は、動作装置13にアクセスして、動作装置13が受信する受信チャネルを設定するためのAPIである。このAPIを用いて、チャンネル番号を与えることで、動作装置13は、指定されたチャンネルに受信チャネルを設定する。
【0047】
readChList()は、動作装置13であるテレビが受信可能な受信チャネルの情報を得るためのAPIである。このAPIを用いることで、具体的には、受信可能な各受信チャネルのチャンネル番号(chNum)とチャンネル名(chName)と放送提供者識別子(providerId)とを得る。
【0048】
図4A〜Bは、ロジックプログラムの例を示す。
【0049】
図4A〜Bで示すロジックプログラムは、ユーザがTVの受信チャンネルを変えた場合に、その旨をtwitter(商品名)に投稿するプログラムの疑似コードである。
【0050】
このロジックプログラムでは、main()を用いて、60秒毎に受信チャネルを取得し、取得した受信チャンネルが、前回取得した受信チャンネルと比べて変更があった場合には、新しい受信チャンネルをtwitter(商品名)に送る。ここで、受信チャンネルのtwitter(商品名)への送信にはsendMessage()を用いており、この中でmakeMessage()により送信するメッセージを作成している。
【0051】
次に、図2を用いて、プログラム生成装置10の動作の詳細を説明する。
【0052】
プログラム生成装置10は、動作装置13から広告メッセージを受信すると、広告メッセージが含む情報(装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス)を記憶する。この記憶した情報を、動作装置情報と称する。また、プログラム生成装置10は、API蓄積装置12から広告メッセージを受信すると、広告メッセージが含む情報(装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス、API取得URL)を記憶する。この記憶した情報を、API蓄積装置情報と呼ぶ。また、プログラム生成装置10は、プログラム実行装置14から広告メッセージを受信すると、広告メッセージに含まれる情報(装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス)を記憶する。この記憶した情報を、プログラム実行装置情報と呼ぶ。
【0053】
次に、プログラム生成装置10の構成を説明する。
【0054】
図5は、にプログラム生成装置10の構成を示すブロック図である。
【0055】
広告メッセージ処理部106は、通信処理部101を介して、広告メッセージを受信する。そして、広告メッセージが含む装置種別を基に、広告メッセージを送信した装置の種別を判断する。広告メッセージに含まれる装置種別が動作装置である場合、動作装置情報を抽出し、動作装置情報保持部107に送信する。広告メッセージに含まれる装置種別がAPI蓄積装置である場合、API蓄積装置情報を抽出し、API蓄積情報保持部108に送信する。広告メッセージに含まれる装置種別がプログラム実行装置である場合、プログラム実行装置情報を抽出し、プログラム実行装置情報を、プログラム実行情報保持部109に送信する。
【0056】
動作装置情報保持部107は、動作装置情報を保持する。また、ヒューマンインタフェース処理部110又はAPIプログラム取得処理部102に、保持している動作装置情報を送信する。
【0057】
API蓄積装置情報保持部108は、API蓄積装置情報を保持する。また、ヒューマンインタフェース処理部110又はAPIプログラム取得処理部102に、保持しているAPI蓄積装置情報を送信する。
【0058】
プログラム実行装置情報保持部109は、プログラム実行装置情報を保持する。また、ヒューマンインタフェース処理部110又は実行プログラム送信処理部105に、保持しているプログラム実行装置情報を送信する。
【0059】
ヒューマンインタフェース処理部110は、ディスプレイへの画面出力やマウスからの入力を処理する。ヒューマンインタフェース処理部110は、例えば、Webブラウザで実現される。
【0060】
ヒューマンインタフェース処理部110は、プログラム蓄積サーバ16が保有するロジックプログラムのリストについて、ロジックプログラム選択画面を生成し、表示する。図6は、ヒューマンインタフェース処理部110が、画面にロジックプログラム選択画面を表示した場合の例を示す。図6では、ロジックプログラム選択画面の例を示す図である。図6の例では、プログラム蓄積サーバ16が、2つのロジックプログラムを保有する場合の例である。2つのロジックプログラムは、「視聴チャンネルをtwitter(商品名)へ投稿」と「Facebook(商品名)で人気の番組を録画予約」である。尚、以後の説明では、いずれかのロジックプログラムを選択したあとの説明をする場合、「視聴チャンネルをtwitter(商品名)へ投稿」の方のロジックプログラムを選択したことを前提とした説明を行う。
【0061】
ヒューマンインタフェース処理部110は、動作装置情報保持部107に蓄積されている動作装置情報を用いて動作装置選択画面を生成し、表示する。ヒューマンインターフェース部110は、例えば、動作装置情報を、プログラム蓄積サーバ16に送信し、プログラム蓄積サーバ16が、モデル識別子から機器種別を表す文字列(TV,PVR,蓄電池、エアコン、太陽電池パネル、電力メータ)とアイコンに変換して画面を生成し、その画面を表示することができる。また、ヒューマンインターフェース部110は、文字列やアイコンを動作装置情報として、動作装置13から取得して、表示することも可能である。
【0062】
図7は、ヒューマンインターフェース処理部110が、画面に動作装置選択画面を表示した場合の例を示す図である。図7の例では、TVとPVRと蓄電池とエアコンと太陽電池パネルと電力メータのアイコンと文字列を表示する例を示している。
【0063】
ヒューマンインターフェース処理部110は、更に、ロジックプログラム選択画面で選択されたロジックプログラム選択された場合に、選択されたロジックプログラムを動作させることができない動作装置13について、動作装置選択画面にて、選択不可能であることを表示してもよい。例えば、選択不可能であることを示す表示として、グレイアウトあるいは非表示とする表示を行う。ロジックプログラムとして「視聴チャンネルをtwitter(商品名)へ投稿」を選択した場合、実行可能であるTVとPVRを通常表示し、それ以外の動作装置をグレイアウト表示又は非表示とする。尚、以降の説明では、動作装置選択画面で、いずれかの装置が選択されたことを前提とした説明をする場合、TVを選択したとして説明する。
【0064】
ヒューマインタフェース処理部110は、ロジックプログラム選択画面で選択された動作装置のAPIプログラムに対応するロジックプログラムを取得するようロジックプログラム取得部103に通知する。
【0065】
ヒューマンインタフェース処理部110は、プログラム実行装置情報保持部109に保持されたプログラム実行装置情報を基に、プログラム実行装置選択画面を表示する。図8に、プログラム実行装置選択画面の一例を示す。ヒューマンインタフェース処理部110は、プロがラム実行装置選択画面を生成する際、プログラム実行装置情報をプログラム蓄積サーバ16に送信し、プログラム蓄積サーバ16にてモデル識別子から機器種別を表す文字列(携帯電話、PC)とアイコンに変換して画面を生成することができる。また、これらのアイコンや文字列の情報も、プログラム実行装置情報として、プログラム実行装置14から取得することも可能である。また、ヒューマンインタフェース処理部110は、更に、機器種別を表す文字列だけでなく、個々のプログラム動作装置13にユーザが付与した名称(健一、健二、Rose)をプログラム実行装置情報に含め、表示することもできる。図8に、その例を示している。
【0066】
ヒューマンインタフェース処理部110は、外部から選択されたプログラム実行装置14に対して、実行プログラムを送信するように、実行プログラム送信処理部105に通知する。
【0067】
以上が、ヒューマンインタフェース処理部110に関する説明である。
【0068】
APIプログラム取得処理部102は、API蓄積情報保持部108に蓄積されているAPI蓄積情報を基に、API蓄積装置12から、APIプログラムを取得する。具体的には、API蓄積情報に含まれるAPI取得URLに、通信処理部101を介してアクセスし、APIプログラムを取得する。APIプログラム取得処理部102は、取得したAPIプログラムを実行プログラム生成部105に送る。また、取得したAPIプログラムのAPI識別子をロジックプログラム取得処理部103に送る。
【0069】
ロジックプログラム取得処理部103は、プログラム蓄積サーバ16から、ヒューマンインタフェース処理部110によりロジックプログラム選択画面で選択されたロジックプログラムを取得する。
【0070】
典型的なケースでは、ロジックプログラム蓄積サーバ16がWebサーバ機能を有し、ロジックプログラム選択画面を提供する。この際、ロジックプログラム取得処理部103は、API識別子をプログラム蓄積サーバ16に送り、プログラム蓄積サーバ16はこのAPI識別子に基づきプログラム生成可能なロジックプログラムのみを表示することが好ましい。
【0071】
ロジックプログラム取得処理部103のアクセスするプログラム蓄積サーバ16のURLは予め与えられているものとする。このURLは、典型的には、Google(商品名)のような検索サービスを用いて得る。
【0072】
ロジックプログラム取得処理部103は、取得したロジックプログラムを実行プログラム生成部105に送信する。
【0073】
実行プログラム生成部105は、APIプログラム取得処理部102から受信したAPIプログラムとロジックプログラム取得処理部103から取得したロジックプログラムとを用いて、実行プログラムを生成し、実行プログラム送信処理部105へ送信する。
【0074】
図9A〜Eは、図3A〜CのAPIプログラムと、図4A〜Bのロジックプログラムとから生成された実行プログラムの例を示す図である。図9A〜Eの例では、Java(登録商標)Scriptを用いているため、図3A〜Cで示したAPIプログラムと図4A〜Bで示したロジックプログラムとを連結するだけで、図9A〜Eの実行プログラムを実現できる。
【0075】
実行プログラムの生成方法には、様々なものがある。例えば、図9A〜Eで示すように、インタプリタ型の言語を用いる場合には、テキストデータで記述されたプログラムの連結で行うことが望ましい。インタプリタ型の言語として、例えば、Java(登録商標)やRuby(商品名)がある。また、実行プログラムの生成に、C言語のようなコンパイラ型の言語を用いる場合には、プログラム実行装置14上にコンパイラを用意する。そして、プログラム生成装置100の実行プログラム生成部105が、APIプログラムとロジックプログラムとをコンパイルする方法を記述したmakefileを生成する。このように、コンパイラ型の言語を用いる場合、実行プログラムは、APIプログラムとロジックプログラムとmakefileとを含む情報としてもよい。
尚、実行プログラムの生成に、コンパイラ型の言語を用いる場合であっても、プログラム実行装置14のプログラム実行環境を示す識別子をプログラム実行装置14からの広告メッセージに含めることで、実行プログラム生成部105にて、プログラム実行装置14で実行プログラムが動作するようクロスコンパイルを行うことも可能である。
【0076】
実行プログラム送信処理部105は、実行プログラム生成部105から受信した実行プログラムを、ヒューマンインタフェース処理部110の指示に従い、プログラム実行装置14に通信処理部101を介して送信する。
【0077】
通信処理部101は、あらかじめ定められた通信手順に従い、ネットワーク17とのデータの送受信を行う。
【0078】
プログラム実行装置14は、プログラム生成装置10から実行プログラムを受信すると、受信した実行プログラムを実行する。図9A〜Eで示した実行プログラムの場合、プログラム実行装置14は、動作装置13(TV)に定期的にアクセスし、前回アクセスしたときと今回アクセスしたときとで、受信チャンネルに変更がある場合に、アプリケーションサーバ15(twitter(商品名))に通知する。通知するメッセージは、例えば、「いま、Nippon TVを見ています」である。
【0079】
以下では、本実施形態にかかるシステムを用いた場合の効果を説明する。
【0080】
例えば、ユーザがTVを買い替えた場合を想定する。つまり、図1のネットワーク17に接続された動作装置13の機能が変わった場合を想定する。例えば、買い替えたTVがEPG(Electronic Program Guide :電子番組表)機能が追加されていた場合を考える。このように、買い換えたTVが、新しい機能が追加されていた場合、APIプログラムとロジックプログラムも、この機能に対応するプログラムとすることで、この機能を活用した実行プログラムを実現できる。例えば、新しいTVのAPIプログラムを、図3A〜Cに示したプログラムにさらに電子番組表データをTVから取得するgetEPGInfo()を追加したプログラムとする。そして、ロジックプログラムを、getEPGInfo()に対応するロジックプログラムとする。プログラム実行装置14は、このような、ロジックプログラムとAPIプログラムとから生成される実行プログラムを用いて、例えば、アプリケーションサーバ15にメッセージを通知する際に、受信チャネルで受信している番組名に変換して、「いま、Nippon TVのドラマ“春来たる”を見ています」というより詳細なメッセージを作成することができる。
【0081】
従来は、実行プログラムは、標準通信仕様に依存したプログラムであったため、標準通信仕様が変化しない限り、このように動作装置13の機能の変化に合わせた柔軟なプログラムを実現できず、動作装置13の機能に合わせたサービス提供を実現できなかった。しかし、本実施例では、動作装置13の機能に応じたAPIプログラムを実現でき、そのAPIプログラムに合わせたロジックプログラムを作ることで、動作装置13の機能を十分に生かした多様な実行プログラムを実現でき、多様なサービスを実現できることとなる。
【0082】
尚、APIプログラムは、動作装置13(TV)の製造メーカが作成することが好ましい。また、ロジックプログラムは、製造メーカを含む不特定多数が作成し、例えばネット上のサーバにアップロードできることが好ましい。APIプログラムを、製造メーカが作成すると、APIプログラムを動作装置13の進化に合わせて作成することができる。また、ロジックプログラムを不特定多数の者が作成すると、動作装置13の進化に合わせて作成することができる。
【0083】
また、本実施例では、実行プログラムを動作装置13と別に設け、プログラム実行装置14が、アプリケーションサーバ15と動作装置13にアクセスし、アプリケーションサーバ15と動作装置13との連携を実現している。このようにすることで、例えば、データサイズが大きすぎて扱えないなどの理由で、旧型の動作装置13では進化したアプリケーションサーバ15と直接連携できない場合でも、プログラム実行装置14が、新しいアプリケーションサーバ15と旧型の動作装置13との連携を実現することができる。尚、プログラム実行装置14は携帯電話やPCのようなアプリケーションサーバ15のサービスを利用する機器であることが望ましい。
【0084】
尚、第1の実施形態では、アプリケーションサーバ15、プログラム蓄積サーバ16、動作装置13、プログラム生成装置10、プログラム蓄積サーバ16、動作装置13、API蓄積装置12各々が一台である例を説明した。しかしながら、各々の装置が複数台ある場合にも本実施形態は適用可能である。
【0085】
例えば、アプリケーションサーバ15が複数台ある場合について説明する。この場合、プログラム実行装置14は、Facebook(商品名)の掲示板にて人気の放送番組を取得し、この放送番組を動作装置13(PVR)に録画予約し、録画したこの番組が再生された場合にその旨をtwitter(商品名)に通知する、という実行プログラムを実行できる。
【0086】
次に、動作装置13が複数存在する場合を説明する。例えば、動作装置13が温度計とエアコンである場合、実行プログラム実行装置14は、温度計から気温を取得し、これが目標値になるようエアコンの設定温度を変更する実行プログラムを実行できる。
【0087】
また、本実施形態では、IPプロトコルを用いた場合を説明したが、IPv6プロトコルなど、その他の通信プロトコルにも適用可能である。
【0088】
また、本実施形態のネットワークのメディアは有線・無線のどちらでも使用することが可能である。
【0089】
また、第1の実施形態に係るプログラム生成装置10は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、通信処理部1とAPIプログラム処理部102とロジックプログラム取得処理部103と実行プログラム生成部104と実行プログラム送信処理部105と広告メッセージ処理部106と動作装置情報保持部107とAPI蓄積装置情報保持部108とプログラム実行装置情報保持部109とヒューマンインタフェース処理部110とは、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、プログラム生成装置10は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD−ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、動作装置情報保持部107とAPI蓄積装置情報保持部108とプログラム実行装置情報保持部とは、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD−R、CD−RW、DVD−RAM、DVD−Rなどの記憶媒体などを適宜利用して実現することができる。
【0090】
<変形例>
次に、第1の実施形態の変形例を説明する。
【0091】
図10は、第1の実施形態の変形例にかかるシステムを示すブロック図である。
【0092】
第1の実施形態の変形例にかかるシステムにおいては、第1の実施形態で説明した動作装置13とAPI蓄積装置12とが一体となっている点と、プログラム実行装置14とプログラム生成装置10とが一体となっている点が異なる。以下では、動作装置13とAPI蓄積装置12とが一体となった装置を、動作装置20と称する。動作装置20は、API蓄積装置12の機能を備えたAPI蓄積部20Aを備えている。また、プログラム実行装置14とプログラム生成装置10とが一体となった装置を、プログラム実行装置22と称する。プログラム実行装置22は、プログラム生成装置10の機能を備えたプログラム生成部22Aを備えている。
【0093】
各々の装置の機能は、第1の実施形態と説明したものと同様であるため、各々の装置の説明は省略する。
【0094】
尚、動作装置20が備えるAPI蓄積部20Aは、動作装置20にアクセスするためのAPIプログラムを蓄積するものとする。第1の実施例のAPI蓄積装置12は、複数の動作装置20がある場合には、複数の動作装置20のAPIプログラムをまとめて蓄積して管理することを想定していたが、本変形例では、動作装置20毎に、動作装置20に対応したAPIプログラムを記憶するものであるからである。尚、動作装置20が、動作装置20自身にアクセスするための複数のAPIプログラムを記憶することは、想定できる。つまり、動作装置20に、アクセスして、実現したい機能により複数のAPIプログラムを想定できるからである。
【0095】
次に、第1の実施形態にかかる変形例のシステムにおける動作を説明する。図11は、図10のシステムにおける動作シーケンスを示す図である。
【0096】
また、尚、本変形例のプログラム実行装置22は、図5に示すような、プログラム生成装置10が備える構成に加えて、プログラム実行装置10が備える機能、つまり、プログラム生成装置10が生成した実行プログラムを実行するプログラム実行部のような機能を備える。尚、プログラム実行装置22は、図5で示した実行プログラム送信処理部105は、備えていなくてもよい。
【0097】
まず、動作装置20は、定期的に広告メッセージをブロードキャストあるいはマルチキャストする(S201)。ここで、広告メッセージは、例えばIPパケットにて運ばれる。広告メッセージは、装置種別とプロバイダ識別子とモデル識別子と個体識別子と装置IPアドレスとを含む。
【0098】
装置種別は、動作装置20の種別(例えば、TVであるかやPVRであるか)を識別する識別子である。
【0099】
プロバイダ識別子は、その装置を製造したメーカを識別する識別子である。
【0100】
モデル識別子は、装置のモデルを識別する識別子である。モデル識別子は、例えば、UUID(Universally Unique Identifier)を用いることが好ましい。UUIDを用いることにより、製造メーカが異なるモデルでも異なる識別子を割り当てることができる。
【0101】
個体識別子は、装置を一意に識別する識別子である。個体識別子は、例えば、UUIDを用いることが好ましい。尚、必ずしも、個体識別子単体で、装置1つを重複なく識別するようにしなくてもよい。例えば、モデル識別子と個体識別子の組で、重複ない値を割り当てることができればよい。
【0102】
装置IPアドレスは、装置に割り当てられたIPアドレスである。
【0103】
以上が、広告メッセージの説明である。
【0104】
次に、第1の実施形態の変形例のシステムの動作説明に戻る。
【0105】
次に、プログラム実行装置22は、動作装置20からAPIプログラムを受信する(S202)。このとき、プログラム実行装置22は、動作装置20からの広告メッセージにてそのAPI取得URL(例えば,http://192.168.0.1/api/)を知り、そのIPアドレスに向けてHTTPにてAPIプログラムを要求する。
【0106】
次に、プログラム実行装置22は、プログラム蓄積装置16からロジックプログラムを受信する(S203)。このとき、プログラム実行装置22は、予めプログラム蓄積装置16のIPアドレスを保持していることが望ましい。
【0107】
次に、プログラム実行装置22は、APIプログラムとロジックプログラムから実行プログラムを生成し、この実行プログラムを実行する。プログラム実行装置22は、実行プログラムを実行する際、アプリケーションサーバ15および動作装置20にネットワーク17を介してアクセスする(S204、S205)。
【0108】
次に、動作装置20の構成を説明する。図12は、動作装置20の構成を示すブロック図である。
【0109】
本体処理部207は、動作装置20の本来の動作に関わる処理を行う。ここで、本来の動作とは、例えば、動作装置20がTVである場合には、リモコン信号および放送波信号および外部ボタンの押下に従い、TV放送信号を受信し、放送信号を復調し、画面表示を行うといった動作である。
【0110】
通信処理部201は、あらかじめ定められた通信手順に従い、ネットワーク17とのデータの送受信を行う。
【0111】
広告メッセージ送信部202は、予め設定されている情報を用いて、広告メッセージを定期的に送信する。ここで、広告メッセージが含むAPI取得URLは、後述するAPIプログラム蓄積部206に複数のAPIプログラムが保持されている場合には、各々のAPIプログラムを指定して取得できるように、APIプログラム毎にURLを用意することが好ましい。
【0112】
APIプログラム蓄積部206は、APIプログラムを保持する。複数のAPIプログラムを保持できることが好ましい。
【0113】
APIプログラム更新処理部203は、APIプログラム蓄積部206内のAPIプログラムの追加・削除・更新処理を、ネットワーク17を介して行う。
【0114】
APIプログラム送信処理部204は、ネットワーク17を介して、APIプログラム取得要求を受信すると、APIプログラム取得要求に含まれるAPI取得URLに従って要求されたAPIプログラムをAPIプログラム蓄積部206より抽出し、ネットワーク17を介して要求者に送信する。
【0115】
動作コマンド処理部205は、ネットワーク17を介して、動作コマンドを受信すると、これに従って本体処理部207へ制御コマンドを送信する。また、動作コマンドが動作状態の取得を要求する場合には、本体処理部207から対応する情報を抽出し、当該抽出した情報を、ネットワーク17を介して動作コマンド送信者に送信する。
【0116】
本実施例の動作装置20では、APIプログラムはプログラム実行装置22に向けて高々一度送信すればよい。これに対して、従来のHTTPサーバを有し、外部のWebブラウザによりネットワークを介して制御される制御装置では、Webブラウザをユーザが操作し、これに対応した制御コマンドを、HTTP POSTあるいはGETデータとして動作装置に送信し、これを受信した動作装置は、制御コマンドに従った動作を行うと同時に、応答を返す。この応答には、続く制御コマンドをWebブラウザから送信するためのプログラムが含まれており、結果として制御コマンドを受信するたびに制御のためのプログラムを動作装置は送信している。本実施例では、APIプログラムは高々一度送信すればよいため、ネットワークに与える負荷を小さくでき、さらに動作装置20の通信処理に要する処理量を削減することができる。
【0117】
以上、第1の実施形態の変形例を説明したが、第1の実施形態の変形例は、上述したように、動作装置20とプログラム実行装置22とが、各々、第1の実施形態で説明した2つの装置を一体とした点が異なり、その他の点は同様の機能である。したがって、本変形例のシステムによれば、第1の実施形態で説明した効果と同様の効果を達成することができる。
【0118】
続けて、第2の実施形態と第3の実施形態を説明するが、第2の実施形態と第3の実施形態は、第1の実施形態で説明したシステムの具体例である。
【0119】
<第2の実施形態>
図13は、第2の実施形態にかかるシステムを示すブロック図である。
【0120】
第2の実施形態にかかるシステムは、プログラム蓄積サーバ16と、アプリケーションサーバ15A及び15Bと、電気自動車30と、がネットワーク17介して接続されている。電気自動車30は、スマートフォン30Aと蓄電池30Bとナビゲーション装置30Cとを有する。蓄電池30Bとスマートフォン30Aとは、車内ネットワーク30D(ex 無線LAN, Bluetooth, CAN(Car area network))を介して接続されている。ナビゲーション装置30Cとスマートフォン30Aとは、車内ネットワーク30Dにて接続されている。尚、図13の例では、蓄電池30Bとスマートフォン30Aとの間、ナビゲーション装置30Cとスマートフォン30Aとの間、各々の間のネットワークが同一の車内ネットワーク30Dであるとしたが、各々のネットワークが異なるネットワークであってもよい。
【0121】
ここで、蓄電池30B及びナビゲーション装置30Cは、図12で示した第1の実施形態の変形例の動作装置20と同様の機能を有する。蓄電池30B及びナビゲーション装置30Cは、動作装置20と同様、APIプログラム蓄積部206を有している。スマートフォン30Aは、第1の実施形態の変形例のプログラム実行装置22と同様の機能を有する。このように第2の実施形態にかかるシステムは、動作装置20が2台ある例を示している。
【0122】
スマートフォン30Aは、蓄電池30BのAPIプログラム蓄積部206に蓄積されているAPIプログラムを用いることにより、ネットワークを介して蓄電池30Bにアクセスすることで、蓄電池30Bの予め定められた短期間毎(例えば、1分毎)の充放電量と、電気残量、温度を取得することができる。
【0123】
また、スマートフォン30Aは、ナビゲーション装置30CのAPIプログラム蓄積部206に蓄積されているAPIプログラムを用いることにより、ネットワークを介してナビゲーション装置30Cにアクセスすることで、電気自動車30の現在の位置情報および速度情報(進行方向を含む)を得ることができる。
【0124】
次に、第2の実施形態のシステムの動作を説明する。
【0125】
図14は、第2の実施形態にかかるシステムの動作を示すシーケンス図である。
【0126】
まず、蓄電池30Bは、広告メッセージを定期的に送信する(S301)。
【0127】
また、ナビゲーション装置30Cは広告メッセージを定期的に送信する(S302)。
【0128】
次に、スマートフォン30Aは、S301及びS302で取得した広告メッセージに含まれるAPI取得URLを用いて、蓄電池30B及びナビゲーション装置30CからAPIプログラムを取得する(S303、S304)。
【0129】
次に、スマートフォン30Aは、予め設定されたプログラム蓄積装置16から、ロジックプログラムを取得する(S305)。そして、スマートフォン30Aは、ロジックプログラムと蓄電池30B及びナビゲーション装置30Cから取得したAPIプログラムとから、実行プログラムを生成する。そして、スマートフォン30Aは、実行プログラムを実行する。実行プログラムの実行の際、スマートフォン30Aは、蓄電池30Bとナビゲーション装置30Cとアプリケーションサーバ15及び15Bにアクセスする(S306〜S309)。
【0130】
より具体的には、スマートフォン30Aは、実行プログラムを実行することで、ナビゲーション装置30Cにアクセスして(S307)、位置情報及び速度情報を取得し、取得した位置情報及び速度情報を、アプリケーションサーバ15Aに送信し、周辺地図情報を取得する(S308)。ここで、アプリケーションサーバ15Aは、周辺地図情報を提供するサービスを行っているとする。
【0131】
また、スマートフォン30Aは、実行プログラムを実行することで、蓄電池30Bから放電量と電気残量と温度とを取得し(S306)、S307で取得する速度情報と併せて、アプリケーションサーバ15Bに送信し、走行可能距離を得る(S309)。ここで、アプリケーションサーバ15Bは、電気自動車30の走行可能距離算出サービスを行っているとする。
【0132】
また、スマートフォン30Aは、実行プログラムを実行することで、周辺地図情報と走行可能距離とから、走行可能範囲31Cをスマートフォン30Aの画面31A上に表示する。
【0133】
図15に、スマートフォン30Aが、画面上に表示する走行可能範囲31Cの例を示す。
【0134】
図15の例では、電気自動車30が右方向に進行していることを前提としているため、現在地31Bを中心とした地図ではなく、現在地31Bより右側の領域を多く表示している。また、図15の例では、右側に表示している道路の混雑が多いことを前提としているため、赤線で囲まれた走行可能領域は、右側は左側と比べて狭くなっている。
【0135】
以上の例のように、複数の電気自動車30が自身の位置をアプリケーションサーバ15Bに送信することで、アプリケーションサーバ15Bは、道路の混雑状況を加味した走行可能距離を計算することができる。また、蓄電池30Bの電気残量を正確に求めることは一般に難しいが、走行可能距離の計算をアプリケーションサーバ側で実行することで、実データの収集およびこれに基づく算出アルゴリズムの改良、そして新しいアルゴリズムの導入が可能である。また、この改良後の算出アルゴリズム若しくは新たに導入したアルゴリズムをロジックプログラムとしてスマートフォン30Aに送信することで、スマートフォン30Aは、電気自動車30設計当時の計算能力では実行できない複雑な算出アルゴリズムを実行することができる。この場合は、スマートフォン30Aがアプリケーションサーバと常に通信する必要が無く、スマートフォン30Aの消費電力を削減するという効果もある。
【0136】
<第3の実施形態>
図16は、第3の実施形態に係るシステムを示すブロック図である。
【0137】
第3の実施形態に係るシステムは、プログラム蓄積サーバ16と、二つのアプリケーションサーバ15A及び15Bと、エネルギー管理サーバ41と建物40Aと建物40Bとが、ネットワーク17を介して接続されている。
【0138】
また、建物40Aは、電力計401Aと蓄熱装置402Aとを備えている。電力系401Aと蓄熱装置402Aとはネットワーク403Aを介して接続されている。建物40Bは、電力系401Bと蓄熱装置402Bとを備えている。電力系401Bと蓄熱装置402Bとは、ネットワーク403Bを介して接続されている。
【0139】
本実施例のエネルギー管理サーバ41は、第1の実施形態の変形例のプログラム実行装置22の機能を有する。また、蓄熱装置402A及び402Bは、動作装置20の機能を有する(図10を参照)。
【0140】
電力計401Aは、建物40Aの消費電力を測定し、測定結果をアプリケーションサーバ15Aへ送信する。電力計401Aの消費電力測定の細かさは様々な形態を考えることができ、建物内のフロア毎や部屋毎やコンセント毎に消費電力を測定できる。電力計401Bも同様の機能を有する。
【0141】
蓄熱装置402Aは、ヒートポンプなどの熱発生部(又は吸熱部)と、水のタンクによる温熱又は冷熱を蓄積する熱蓄積部とを備える。熱蓄積部は、冷熱については、冷水ではなく氷の形で熱を蓄積することも可能である。蓄熱装置402Aは、例えば深夜のような電気料金(あるいはガス料金)の安い時間帯の電力でヒートポンプを駆動し得られた熱を蓄積する。蓄積した熱は、電気料金の高い時間帯に給湯、空調、床暖房等の用途に使用することで、ユーザには電気料金削減、電気会社にはピーク電力の削減の効果を実現できる。時間とともに、蓄積した熱は環境へ散逸する。したがって、次の蓄熱タイミング(一般には翌日の深夜)までに、必要最小限の熱量を見積もり、これを蓄熱することが重要である。蓄熱装置402Bも同様の機能を有する。
【0142】
エネルギー管理サーバ41は、蓄熱量を見積もり、見積もった蓄熱量を蓄熱装置402Aに指示する。
【0143】
アプリケーションサーバ15Bは、例えば気象庁の天気予報サイトであり、本日から翌日までの天気情報を提供している。
【0144】
次に、第3の実施形態にかかるシステムの動作シーケンスを説明する。図17は、第3の実施形態に係るシステムの動作を示すシーケンス図である。
【0145】
まず、電力計401Aと電力計401Bは、定期的に、アプリケーションサーバ15Aに対して消費電力量を通知する(S401、S402)。この消費電力量は、予め定められた期間(例えば、一分)毎に消費した電力量である。この消費電力の測定期間と消費電力量の通知間隔は一致している必要は無い。通知する消費電力量には、電力を消費した時刻情報が記されていることが望ましい。時刻情報は、消費電力測定期間と消費電力量通知間隔とが一致している場合には、省略することが可能である。
【0146】
次に、エネルギー管理サーバ41は、電力計401A及びBのAPIプログラムを、電力計401A及びBから取得する(S403、S404)。尚、本実施例では、説明を省略しているが、電力計401A及びBは、広告メッセージをエネルギー管理サーバ41のアドレス宛てに送信することで、エネルギー管理サーバ41は、電力計401A及びBからAPIプログラムを取得可能となる。尚、APIプログラムの取得先は、必ずしも電力計401A及びBである必要はなく、実施例1で示したように、電力計401A及びB以外の機器から取得する構成も可能である。
【0147】
次に、エネルギー管理サーバ41は、ロジックプログラムをプログラム蓄積サーバ16から取得する(S405、S409)。ここで、エネルギー管理サーバ41が取得するロジックプログラムは、蓄熱装置のユーザが予め選択可能であることが好ましい。例えば、ユーザは、蓄熱装置の使用人数や家族構成(女性が3人いるなど)により、ロジックプログラムを選択する。ユーザは、ロジックプログラムを、例えばWebブラウザを使用して選択する。
【0148】
エネルギー管理サーバ41は、ロジックプログラムとAPIプログラムとから実行プログラムを生成し、実行プログラムを実行する。本実施形態では、蓄熱装置402Aと蓄熱装置402Bのユーザが異なる場合、蓄熱装置ごとに異なる実行プログラムを実行することが望ましい。
【0149】
エネルギー管理サーバ41は、実行プログラムを実行することで、アプリケーションサーバ15B、アプリケーションサーバ15Aより天候情報を取得し(S406、S410)、天気情報を用いて蓄熱装置402B、蓄熱装置402Aの蓄熱量を制御する(S407、S411)。
【0150】
さらに、アプリケーションサーバ15Aは、ユーザ毎の消費電力量の一定期間(例えば、一時間)毎の消費電力量を、例えば一カ月分のデータ提供している。そして、ユーザは、Webブラウザを使って、その一カ月分のデータにアクセスすることが可能である。アプリケーションサーバ15Aがこのような機能を備えることで、例えば、Facebook(商品名)の友達関係のあるユーザ間で、これらの消費電力量を共有することも可能である。これにより、ユーザ間で電力節約のコツや、使用しているロジックプログラムの情報を共有することができる。そして、好みの(典型的には、家屋の大きさや断熱性能、あるいは家屋内の機器構成やライフスタイルの似た友人の中で、最も消費電力の少ない人間の使用しているロジックプログラム)ロジックプログラムを選び直すことも可能である。
【0151】
エネルギー管理サーバ41で実行されている実行プログラムのアルゴリズム例について説明する。図18は、エネルギー管理サーバ41で実行する実行プログラムの蓄熱量制御のアルゴリズムの例を示すフローチャートである。
【0152】
まず、深夜電力期間(例えば、AM0時からAM5時)開始前に、ユーザ家屋地域の翌日の天候情報をアプリケーションサーバ15Aから取得する(S501)。本例では、天候情報として気温を取得する。なお、天候情報は、気温に限られない。例えば、太陽光発電装置や風力発電装置をユーザが使用している場合には、その発電量を考慮するため日照量や風量を天候情報とする。
【0153】
次に、実行プログラムは、翌日の使用熱量を予測する(S502)。実行プログラムは、ユーザの熱使用履歴データ(日付、気温、使用熱量)を保持しており、その履歴データの中から翌日の気温に一致する気温に対応する使用熱量を抽出し、抽出した使用熱量の平均を取ることで、翌日の使用熱量を予測する。ここで、翌日の気温と一致する気温とは、気温が完全一致していなくてもよく、気温差がある一定値以内の気温であってもよい。また、抽出した使用熱量の平均を取る際に、単純な加重平均ではなくてもよい。例えば、新しいデータほど重みが大きい重み付き平均など様々な算出の方法が考えられる。また、熱使用履歴データは、一日毎ではなくより細かい時間粒度(例えば一時間毎)に保持してもよい。
【0154】
次に、実行プログラムは、S502で予測した使用熱量と同じ熱量を蓄熱するよう蓄熱装置に通知する(S503)。
【0155】
次に、実行プログラムは、定期的に蓄熱装置から使用熱量を取得し、これを熱使用履歴データに追加する(S504)。
【0156】
以上が、実行プログラムのアルゴリズムである。
【0157】
以上説明したように、エネルギー管理サーバ41において、ユーザが選んだロジックプログラムを動作させることにより、ユーザの使用機器や使用条件に適したエネルギー制御を実現することができる。また、Facebook(商品名)のようなソーシャルネットワークあるいは掲示板サービスと組み合わせることで、ユーザによる最適なロジックプログラムの選択を実現できる。
【0158】
以上説明した少なくとも1つの実施形態の効果は、機器の標準通信仕様の変更があるか否かにかかわらず、ネットワーク上のサービスを、機器の機能に合わせて、機器の機能を利用したサービスを提供できるようなプログラムを生成するプログラム生成装置を提供することができる。
【0159】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【0160】
10・・・プログラム生成装置、12・・・API蓄積装置、13、20・・・動作装置、14、22・・・プログラム実行装置、15、15A、15B・・・アプリケーションサーバ、16・・・プログラム蓄積サーバ、17、30D、403A、403B・・・ネットワーク、101、201・・・通信処理部、102・・・APIプログラム取得処理部、103・・・ロジックプログラム取得処理部、104・・・実行プログラム生成部、105・・・実行プログラム送信処理部、106・・・広告メッセージ処理部、107・・・動作装置情報保持部、108・・・API蓄積装置情報保持部、109・・・プログラム実行装置情報保持部、110・・・ヒューマンインタフェース処理部、20A・・・API蓄積部、22A・・・プログラム生成部、202・・・広告メッセージ送信部、203・・・API更新処理部、204・・・APIプログラム送信処理部、205・・・動作コマンド処理部、206・・・APIプログラム蓄積部、207・・・本体処理部、30・・・電気自動車、30A・・・スマートフォン、30B・・・蓄電池、30C・・・ナビゲーション装置、30D・・・ネットワーク、31A・・・画面、31B・・・現在地、31C・・・走行可能範囲、41・・・エネルギー管理サーバ、40A、40B・・・建物、401A、401B・・・電力計、402A、402B・・・蓄電装置。
【特許請求の範囲】
【請求項1】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第1プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第1サービスとを連携した連携サービスを実現する第2プログラムとを用いて、前記連携サービスを実現する第3プログラムを生成する生成部を有するプログラム生成装置。
【請求項2】
前記第3プログラムを、ネットワークを介して、前記第3プログラムを実行して前記連携サービスを実現する装置に送信する送信部を更に有する請求項1記載のプログラム生成装置。
【請求項3】
前記第3プログラムを実行して、前記連携サービスを実現する実行部を更に有する請求項1記載のプログラム生成装置。
【請求項4】
前記第1プログラムを、ネットワークを介して取得する取得部を有する請求項1記載のプログラム生成装置。
【請求項5】
前記第2プログラムを、ネットワークを介して取得する第2取得部を有する請求項4記載のプログラム生成装置。
【請求項6】
前記第1プログラムは、前記機器が保持し、
前記取得部は、前記機器から取得する請求項4記載のプログラム生成装置。
【請求項7】
前記第1プログラムの通信手順によって利用、若しくは制御を実現される前記機能と連携した連携サービスを実現可能なプログラムを、前記第2プログラムとして選択して取得する第2取得部を有する請求項1記載のプログラム生成装置。
【請求項8】
複数の異なる第3プログラムを生成した場合、複数の異なる第3プログラムを示す表示を画面に表示し、前記画面に表示された表示から、前記複数の異なる第3プログラムの中から、実行したい連携サービスを実現する第3プログラムを選択可能とするヒューマンインタフェース処理部を有する請求項1記載のプログラム生成装置。
【請求項9】
アプリケーションサーバとネットワークを介して接続され、
前記第1サービスは、前記アプリケーションサーバが提供し、
前記実行部は、前記連携サービスを実現する際に、前記アプリケーションサーバと通信を行う請求項3記載のプログラム生成装置。
【請求項10】
前記実行部は、Webブラウザであり、前記アプリケーションサーバからHTMLデータを受信することで画面表示を行う請求項9記載のプログラム生成装置。
【請求項11】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第1プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第1サービスとを連携した連携サービスを実現する第2プログラムとを用いて、前記連携サービスを実現する第3プログラムを生成する生成ステップを有するプログラム生成方法。
【請求項12】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第1プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第1サービスとを連携した連携サービスを実現する第2プログラムとを用いて、前記連携サービスを実現する第3プログラムを生成する生成機能を有するプログラム生成プログラム。
【請求項1】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第1プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第1サービスとを連携した連携サービスを実現する第2プログラムとを用いて、前記連携サービスを実現する第3プログラムを生成する生成部を有するプログラム生成装置。
【請求項2】
前記第3プログラムを、ネットワークを介して、前記第3プログラムを実行して前記連携サービスを実現する装置に送信する送信部を更に有する請求項1記載のプログラム生成装置。
【請求項3】
前記第3プログラムを実行して、前記連携サービスを実現する実行部を更に有する請求項1記載のプログラム生成装置。
【請求項4】
前記第1プログラムを、ネットワークを介して取得する取得部を有する請求項1記載のプログラム生成装置。
【請求項5】
前記第2プログラムを、ネットワークを介して取得する第2取得部を有する請求項4記載のプログラム生成装置。
【請求項6】
前記第1プログラムは、前記機器が保持し、
前記取得部は、前記機器から取得する請求項4記載のプログラム生成装置。
【請求項7】
前記第1プログラムの通信手順によって利用、若しくは制御を実現される前記機能と連携した連携サービスを実現可能なプログラムを、前記第2プログラムとして選択して取得する第2取得部を有する請求項1記載のプログラム生成装置。
【請求項8】
複数の異なる第3プログラムを生成した場合、複数の異なる第3プログラムを示す表示を画面に表示し、前記画面に表示された表示から、前記複数の異なる第3プログラムの中から、実行したい連携サービスを実現する第3プログラムを選択可能とするヒューマンインタフェース処理部を有する請求項1記載のプログラム生成装置。
【請求項9】
アプリケーションサーバとネットワークを介して接続され、
前記第1サービスは、前記アプリケーションサーバが提供し、
前記実行部は、前記連携サービスを実現する際に、前記アプリケーションサーバと通信を行う請求項3記載のプログラム生成装置。
【請求項10】
前記実行部は、Webブラウザであり、前記アプリケーションサーバからHTMLデータを受信することで画面表示を行う請求項9記載のプログラム生成装置。
【請求項11】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第1プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第1サービスとを連携した連携サービスを実現する第2プログラムとを用いて、前記連携サービスを実現する第3プログラムを生成する生成ステップを有するプログラム生成方法。
【請求項12】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第1プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第1サービスとを連携した連携サービスを実現する第2プログラムとを用いて、前記連携サービスを実現する第3プログラムを生成する生成機能を有するプログラム生成プログラム。
【図1】
【図2】
【図3A】
【図3B】
【図3C】
【図4A】
【図4B】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図9C】
【図9D】
【図9E】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図2】
【図3A】
【図3B】
【図3C】
【図4A】
【図4B】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図9C】
【図9D】
【図9E】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【公開番号】特開2013−73458(P2013−73458A)
【公開日】平成25年4月22日(2013.4.22)
【国際特許分類】
【出願番号】特願2011−212684(P2011−212684)
【出願日】平成23年9月28日(2011.9.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVASCRIPT
2.Bluetooth
【出願人】(000003078)株式会社東芝 (54,554)
【Fターム(参考)】
【公開日】平成25年4月22日(2013.4.22)
【国際特許分類】
【出願日】平成23年9月28日(2011.9.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVASCRIPT
2.Bluetooth
【出願人】(000003078)株式会社東芝 (54,554)
【Fターム(参考)】
[ Back to top ]