プログラム生成装置
【課題】機器の標準通信仕様の変更があるか否かにかかわらず、クラウドサービス等のネットワーク上のサービスを、機器の新機能を利用して提供できるようなプログラムを生成するプログラム生成装置を提供する。
【解決手段】プログラム生成装置１０は、制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第１プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第１サービスとを連携した連携サービスを実現する第２プログラムとを用いて、前記連携サービスを実現する第３プログラムを生成する生成部を有する。
【解決手段】プログラム生成装置１０は、制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第１プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第１サービスとを連携した連携サービスを実現する第２プログラムとを用いて、前記連携サービスを実現する第３プログラムを生成する生成部を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、プログラム生成装置に関する。
【背景技術】
【０００２】
インターネットの発達に伴いパソコン以外の様々な機器が通信機能を有するようになってきている。通信機能を有する機器としては、例えば、携帯電話、電力メータ、エアコンやTV等の家電機器、そして車など多様な機器がある。
【０００３】
一方、近年、パソコン以外の様々な機器が、通信機能を有するようになることに伴い、クラウドサービス等のネットワーク上のサービスを、通信機能を有する機器と連携した新たなサービス（以下、ネット連携サービスと称する。）を提供する動きがある。このようなネット連携サービスにより、より多様なサービスを、サービス提供を受けるユーザは受け取ることができる。なお、ネットワーク上のサービスは、例えば、当該サービスを提供するASP（Application Service Provider）がインターネット上に配置するサーバが提供する。ネット連携サービスの一例として、ネットワーク上のサービスがクラウド連携サービスである場合を考える。そして、例えば、クラウド連携サービスの一例として、クラウドサービスがtwitter（商品名）である場合であって、かつ通信機能を有する機器がテレビである場合を例に考える。この場合、クラウド連携サービスとして、ユーザのテレビの受信チャネルを自動的に取得して、twitter（商品名）上に、現在、見ているテレビのチャネルを自動的に投稿するサービスを想定できる。
【０００４】
従来、機器の通信機能を設計する際に、その通信仕様（通信手順）は、例えばDLNA(Digital Living Alliance)のような標準策定団体にて、標準化が行われてきた。その結果、異なるメーカの機器であっても、同じ標準通信仕様に従うことが一般的であり、同一メーカの新機種と旧機種であっても、同一の通信仕様標準化により各機器が共通した標準通信仕様に従うことが一般的であった。
【０００５】
また、従来、ネット連携サービスを実行するためプログラムは、標準通信仕様にしたがった機器と連携するための機能と、その機能を用いて実行するサービスを提供するための機能とを併せ持ったプログラムが生成されていた。つまり、ネット連携サービスを実行するためのプログラムは、標準通信仕様に依存したプログラムとなっていた。
【０００６】
一般的に、クラウドサービス等のネットワーク上のサービス進化の速度は非常に速い一方で、機器の標準通信仕様の進化は遅い。機器の通信仕様の進化が遅い理由は、通信仕様の普及には時間がかかるためである。通信仕様の普及にかかる時間は、古い通信仕様との互換性の容易さや通信仕様を備える機器の買い替えサイクルに依存する。例えば、エアコンは10年という長い使用期間のため、同じ通信仕様を長く使い続けることが予想され、標準通信仕様の進化が遅いことが想定される。このため、クラウド連携サービス等のネットワーク上のサービスと通信機能を有する機器と連携したネット連携サービスは、クラウドサービス等のネットワーク上のサービスが進化しても、使用する標準通信仕様が進化しない故に、進化が難しいという課題がある。
【０００７】
また、半導体技術の進化の速度は速く機器の機能は急速に進化する一方で、機器の標準通信仕様の進化は遅い。例えば、モデルチェンジにより機器に機能を追加しても、標準通信仕様がその機能をサポートしていない仕様である場合もある。このような場合、ネット連携サービスは、サービス提供に当たり、モデルチェンジにより機器に追加された追加機能を利用できないという課題がある。例えば、先述のクラウド連携サービスの一例を用いて考える。例えば、TVに、番組表を有する機能を追加した場合であって、標準通信仕様には、番組表を取得する機能を有しない場合を考える。この場合、クラウド連携サービスとして、番組表のデータを用いたサービスを提供できない。例えば、twitter（商品名）上に、現在、見ているテレビの番組名を自動的に投稿するサービスを提供できない。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開2009-110300号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の一側面は、機器の標準通信仕様の変更があるか否かにかかわらず、ネットワーク上のサービスを、機器の機能に合わせて、機器の機能を利用したサービスを提供できるようなプログラムを生成するプログラム生成装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一観点にかかるプログラム生成装置は、制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第１プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第１サービスとを連携した連携サービスを実現する第２プログラムとを用いて、前記連携サービスを実現する第３プログラムを生成する生成部を有する。
【図面の簡単な説明】
【００１１】
【図１】本発明の第1の実施形態にかかるシステムを示すブロック図。
【図２】図1のシステムにおける動作を示すシーケンス図。
【図３Ａ】動作装置１３がTVである場合のAPIプログラムの例を示す図。
【図３Ｂ】動作装置１３がTVである場合のAPIプログラムの例を示す図。
【図３Ｃ】動作装置１３がTVである場合のAPIプログラムの例を示す図。
【図４Ａ】ロジックプログラムの例を示す図。
【図４Ｂ】ロジックプログラムの例を示す図。
【図５】図１のシステムにおけるプログラム生成装置１０を示すブロック図。
【図６】ヒューマンインタフェース処理部110が、画面にロジックプログラム選択画面を表示した場合の例を示す図。
【図７】ヒューマンインターフェース処理部１１０が、画面に動作装置選択画面を表示した場合の例を示す図。
【図８】プログラム実行装置選択画面の一例を示す図。
【図９Ａ】実行プログラムの例を示す図。
【図９Ｂ】実行プログラムの例を示す図。
【図９Ｃ】実行プログラムの例を示す図。
【図９Ｄ】実行プログラムの例を示す図。
【図９Ｅ】実行プログラムの例を示す図。
【図１０】本発明の第1の実施形態の変形例にかかるシステムを示すブロック図。
【図１１】図１０のシステムにおける動作を示すシーケンス図。
【図１２】図１０の動作装置２０の構成を示すブロック図。
【図１３】本発明の第2の実施形態にかかるシステムを示すブロック図。
【図１４】図１３のシステムにおけるシーケンス図。
【図１５】スマートフォン３０Ａが、画面上に表示する走行可能範囲３１Ｃの例。
【図１６】本発明の第３の実施形態にかかるシステムを示すブロック図。
【図１７】図１４のシステムにおけるシーケンス図。
【図１８】図１６のエネルギー管理サーバ４１で事項する実行プログラムの蓄熱量制御のアルゴリズムを示すフローチャート。
【発明を実施するための形態】
【００１２】
以下、本発明の実施の形態について、図面を参照しながら説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１３】
＜第１の実施形態＞
図1は、本発明の第1の実施形態にかかるシステムを示すブロック図である。
【００１４】
本発明の第1の実施形態に係るシステムは、プログラム生成装置１０と、API蓄積装置１２と、動作装置１３と、プログラム実行装置１４と、アプリケーションサーバ１５と、プログラム蓄積サーバ１６と、がネットワーク１７を介して接続されている。
【００１５】
動作装置１３とは、ユーザに対してサービス動作を行う装置である。動作装置１３は、例えばTVやPVR（Personal Video Recorder:ハードディスクレコーダ）である。
【００１６】
アプリケーションサーバ１５は、ネットワークを介して、サービス利用者に対して、サービスを提供するサーバである。アプリケーションサーバ１５が、提供するサービスは、例えば、クラウドサービスである。
【００１７】
API蓄積装置１２は、APIプログラムを蓄積するとともに、ネットワーク１７を介して、ＡＰＩプログラムを他の装置に提供する装置である。ここで、ＡＰＩ(Application Program Interface)プログラム（請求項１の第１プログラムに対応する。）は、動作装置１３に、ネットワーク１７を介してアクセスするための通信手順を実現するプログラムである。ここで、動作装置１３に、ネットワーク１７を介してアクセスするための通信手順は、動作装置１３にアクセスして実現すること（例えば、動作装置１３の制御若しくは、動作装置の機能の利用等）によって異なる。そして、動作装置１３にアクセスして実現できることは、動作装置１３が有する機能によって異なる。したがって、ＡＰＩプログラムは、動作装置１３が有する機能や、動作装置１３にアクセスして実現したいことによって、異なるプログラムが割り当てられる。より具体的には、図１のシステムの動作装置１３の機種が変わった場合、その機種に応じたＡＰＩプログラムが生成される。また、複数の動作装置１３がある場合、その動作装置１３毎にＡＰＩプログラムが生成される。また、一つの動作装置１３に対して、実現したい目的に応じて、複数のＡＰＩプログラムを生成することもある。
【００１８】
プログラム蓄積サーバ１６は、ＡＰＩプログラムを利用するプログラムであって、アプリケーションサーバ１５が提供するサービスと動作装置１３とを連携させるプログラムであるロジックプログラム（請求項１の第２のプログラムに対応する。）を蓄積するとともに、ネットワーク１７を介して他の装置に提供する装置である。
【００１９】
プログラム生成装置１０は、APIプログラムとロジックプログラムを基に、アプリケーションサーバ１５が提供するサービスと動作装置１３の機能とを連携させる実行プログラム（請求項１の実行プログラムに対応する。）を生成するとともに、実行プログラムをネットワーク１７を介して他の装置に提供する装置である。ここで、実行プログラムは、後述するプログラム実行装置１４が実行できるプログラムである。実行プログラムは、プログラム実行装置１４が実行可能であればその形式を問わない。バイナリ形式のプログラムでなくてもよい。実行プログラムの形式は、例えば、Perl、Java(登録商標)Script、Ruby(商品名)、Java(登録商標)である。
【００２０】
プログラム実行装置１４は、実行プログラムを実行する機能を有する。
【００２１】
図1では、アプリケーションサーバ１５と、プログラム蓄積サーバ１６と、プログラム生成装置１０と、プログラム実行装置１４と、動作装置１３と、API蓄積装置１２とが各々一台ずつである例を示しているが、各々複数台存在する構成してもよい。
【００２２】
次に、図２を用いて、図１のシステムの動作を説明する。図２は、図１のシステムの通信シーケンスを示す図である。
【００２３】
プログラム実行装置１４と動作装置１３とAPI蓄積装置１２とは、定期的に、広告メッセージをブロードキャスト又はマルチキャストする（Ｓ１０１〜Ｓ１０３）。広告メッセージは、例えば、装置種別とプロバイダ識別子とモデル識別子と装置ＩＰアドレスとを含む。ここで、広告メッセージは、例えばIPパケットを用いて運ばれる。
【００２４】
ここで、広告メッセージが含む各情報の説明を行う。
【００２５】
装置種別とは、プログラム実行装置１４、API蓄積装置１２、動作装置１３各々を互いに識別する識別子である。また、装置種別は、動作装置１３の種別も識別できる識別子であることが好ましい。動作装置の種別とは、例えば、TVやPVRであるかを示す種別である。
【００２６】
プロバイダ識別子は、装置を製造したメーカを識別する識別子である。
【００２７】
モデル識別子は、装置のモデルを識別する識別子である。モデル識別子は、例えば、UUID(Universally Unique Identifier)を用いることが好ましい。UUIDを用いることにより、製造メーカが異なるモデルでも異なる識別子を割り当てることができる。
【００２８】
個体識別子は、装置を一意に識別する識別子である。個体識別子は、例えば、UUIDを用いることが好ましい。尚、必ずしも、個体識別子単体で、装置を一意に識別する識別子としなくてもよい。例えば、モデル識別子と個体識別子との組み合わせで、装置を一意に識別できるようにしてもよい。
装置IPアドレスは、装置に割り当てられたIPアドレスである。
【００２９】
以上が、広告メッセージが含む情報の説明である。
【００３０】
次に、図２を用いて、本実施形態のシステムの動作説明を続ける。
【００３１】
次に、プログラム生成装置１０は、ＡＰＩ蓄積装置12から取得した広告メッセージを参照し、API蓄積装置１２にAPIプログラムを要求し、ＡＰＩプログラムを受信する（Ｓ１０４）。プログラム生成装置１０は、ＡＰＩプログラムを要求する際、API蓄積装置１２から取得した広告メッセージに含まれる装置ＩＰアドレス（API取得URL：例えば,http://192.168.0.1/api/）に向けて、HTTPを用いて、APIプログラムを要求する。
【００３２】
次に、プログラム生成装置１０は、プログラム蓄積サーバ１６から取得した広告メッセージを参照し、プログラム蓄積サーバ１６にロジックプログラムを要求し、ロジックプログラムを受信する（Ｓ１０５）。この際、プログラム生成装置１０は、ロジックプログラムを要求する際、プログラム蓄積サーバ１６から取得した広告メッセージに含まれる装置ＩＰアドレスにむけて、ロジックプログラムを要求する。
【００３３】
次に、プログラム生成装置１０は、取得したAPIプログラムとロジックプログラムを用いて、実行プログラムを生成する。そして、生成した実行プログラムをプログラム実行装置１４に向けて送信する（Ｓ１０６）。ここで、プログラム生成装置１０は、広告メッセージで取得したプログラム実行装置１４のIPアドレスに向けて、HTTPを用いて、実行プログラムを送信する。
【００３４】
次に、プログラム実行装置１４は、受信した実行プログラムを実行する。プログラム実行装置１４は、実行プログラムを実行する際に、アプリケーションサーバ１５および動作装置１３にネットワーク１７を介してアクセスする（Ｓ１０７、Ｓ１０８）。
【００３５】
プログラム実行装置１４が実行プログラムを実行することで、動作装置１３とアプリケーションサーバ１５との連携を実現することができる。連携動作の詳細については、具体例を用いて、後述する。
【００３６】
以上が、図１のシステムの動作シーケンスの説明である。
【００３７】
本実施形態では、動作装置１３毎に動作装置１３にアクセスするための通信手順として、システム全体であらかじめ決められた標準仕様でなく、動作装置１３毎に定められたAPIプログラムを用いている。通信仕様が、システム全体で定められていないため、動作装置１３とアプリケーションサーバ１５とを独立に開発・設置することが可能となる。また、動作装置１３の機能に応じたＡＰＩプログラムを実現できるため、ＡＰＩプログラムを用いた実行プログラムで、動作装置１３にアクセスすることで、動作装置１３の機能を生かした連携サービスを実現できる。
【００３８】
また、本実施形態では、実行プログラムを、動作装置１３とは別のプログラム実行装置１４にて実行する。この結果、実行プログラムが、動作装置１３では扱えない計算量を要求する場合であっても、動作させることができる。特に、アプリケーションサーバ１５がASPによるインターネット上のサーバであり、プログラム実行装置１４がソフトフォーンやPCのようなASPの提供するサービス（ASPサービス）を利用する装置である場合には、急速に進化するASPサービスに追従する計算能力をプログラム実行装置１４が有することが期待できる。
【００３９】
次に、ＡＰＩプログラムの一例を説明する。尚、本実施例では、動作装置１３にアクセスするためのプログラムとして、ＡＰＩを含むプログラムであるＡＰＩプログラムを例にとって説明するが、これに限られない。つまり、動作装置１３にアクセスする手順を示すプログラムであればよく、必ずしも、ＡＰＩを有しているプログラムである必要はない。
【００４０】
図３Ａ〜Ｃは、動作装置１３がTVである場合のAPIプログラムの例を示す図である。
【００４１】
図３Ａ〜Ｃで示したAPIプログラムはJava(登録商標)Scriptで書いた疑似コードである。ＡＰＩプログラム(ファイルapi.js)は、動作装置１３毎に設定され、外部の装置（例えば、プログラム実行装置１４）は、このＡＰＩプログラムで定められた通信手順に従って、動作装置１３にアクセスすることができる。尚、ＡＰＩプログラムは、本実施例では、ＡＰＩプログラム蓄積装置１２が保持していてもよいし、当該ＡＰＩプログラムを用いてアクセスできる動作装置１３に保持させていてもよい。
【００４２】
図３のＡＰＩプログラムでは、<API_Functions>と</API_Functions>との間に、動作装置１３にアクセスするためのAPI関数名が記されている。図３の例では、getApiInfo() 、readCurrentCh() 、setCurrentCh() 、readChList() といった関数が定められている。
【００４３】
getApiInfo()は、動作装置１３にアクセスして、APIプログラムに関する情報を得るためのAPIである。
【００４４】
ここで、ＡＰＩに関する情報とは、具体的には、APIプログラムを識別するAPI識別子と、APIプログラムを用いてアクセスする動作装置のモデル識別子を示すターゲットモデル識別子とを含む情報である。図３の例では、API識別子は、0c91356c-c16a-44c7-9709-448993b6ce07であり、ターゲットモデル識別子は、8699e324-3701-4c31-9a29-abdfe99ea93dである。
【００４５】
readCurrentCh()は、動作装置１３にアクセスして、動作装置１３（本例では、テレビ）が受信している放送の受信チャンネルを得るためのAPIである。このAＰＩを用いて、例えば、受信チャンネルのチャンネル番号（chNum）と、チャンネル名(chName)と、放送提供者に一意に割り当てられた放送提供者識別子（providerId）を得る。
【００４６】
setCurrentCh()は、動作装置１３にアクセスして、動作装置１３が受信する受信チャネルを設定するためのAPIである。このＡＰＩを用いて、チャンネル番号を与えることで、動作装置１３は、指定されたチャンネルに受信チャネルを設定する。
【００４７】
readChList()は、動作装置１３であるテレビが受信可能な受信チャネルの情報を得るためのAPIである。このＡＰＩを用いることで、具体的には、受信可能な各受信チャネルのチャンネル番号（chNum）とチャンネル名(chName)と放送提供者識別子（providerId）とを得る。
【００４８】
図４Ａ〜Ｂは、ロジックプログラムの例を示す。
【００４９】
図４Ａ〜Ｂで示すロジックプログラムは、ユーザがTVの受信チャンネルを変えた場合に、その旨をtwitter（商品名）に投稿するプログラムの疑似コードである。
【００５０】
このロジックプログラムでは、main()を用いて、60秒毎に受信チャネルを取得し、取得した受信チャンネルが、前回取得した受信チャンネルと比べて変更があった場合には、新しい受信チャンネルをtwitter（商品名）に送る。ここで、受信チャンネルのtwitter（商品名）への送信にはsendMessage()を用いており、この中でmakeMessage()により送信するメッセージを作成している。
【００５１】
次に、図２を用いて、プログラム生成装置１０の動作の詳細を説明する。
【００５２】
プログラム生成装置１０は、動作装置１３から広告メッセージを受信すると、広告メッセージが含む情報（装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス）を記憶する。この記憶した情報を、動作装置情報と称する。また、プログラム生成装置１０は、API蓄積装置１２から広告メッセージを受信すると、広告メッセージが含む情報（装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス、API取得URL）を記憶する。この記憶した情報を、API蓄積装置情報と呼ぶ。また、プログラム生成装置10は、プログラム実行装置１４から広告メッセージを受信すると、広告メッセージに含まれる情報（装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス）を記憶する。この記憶した情報を、プログラム実行装置情報と呼ぶ。
【００５３】
次に、プログラム生成装置10の構成を説明する。
【００５４】
図５は、にプログラム生成装置１０の構成を示すブロック図である。
【００５５】
広告メッセージ処理部１０６は、通信処理部１０１を介して、広告メッセージを受信する。そして、広告メッセージが含む装置種別を基に、広告メッセージを送信した装置の種別を判断する。広告メッセージに含まれる装置種別が動作装置である場合、動作装置情報を抽出し、動作装置情報保持部１０７に送信する。広告メッセージに含まれる装置種別がＡＰＩ蓄積装置である場合、API蓄積装置情報を抽出し、API蓄積情報保持部１０８に送信する。広告メッセージに含まれる装置種別がプログラム実行装置である場合、プログラム実行装置情報を抽出し、プログラム実行装置情報を、プログラム実行情報保持部１０９に送信する。
【００５６】
動作装置情報保持部１０７は、動作装置情報を保持する。また、ヒューマンインタフェース処理部１１０又はAPIプログラム取得処理部１０２に、保持している動作装置情報を送信する。
【００５７】
API蓄積装置情報保持部１０８は、API蓄積装置情報を保持する。また、ヒューマンインタフェース処理部１１０又はAPIプログラム取得処理部１０２に、保持しているAPI蓄積装置情報を送信する。
【００５８】
プログラム実行装置情報保持部１０９は、プログラム実行装置情報を保持する。また、ヒューマンインタフェース処理部１１０又は実行プログラム送信処理部１０５に、保持しているプログラム実行装置情報を送信する。
【００５９】
ヒューマンインタフェース処理部１１０は、ディスプレイへの画面出力やマウスからの入力を処理する。ヒューマンインタフェース処理部１１０は、例えば、Webブラウザで実現される。
【００６０】
ヒューマンインタフェース処理部１１０は、プログラム蓄積サーバ１６が保有するロジックプログラムのリストについて、ロジックプログラム選択画面を生成し、表示する。図６は、ヒューマンインタフェース処理部110が、画面にロジックプログラム選択画面を表示した場合の例を示す。図６では、ロジックプログラム選択画面の例を示す図である。図６の例では、プログラム蓄積サーバ１６が、２つのロジックプログラムを保有する場合の例である。２つのロジックプログラムは、「視聴チャンネルをtwitter（商品名）へ投稿」と「Facebook（商品名）で人気の番組を録画予約」である。尚、以後の説明では、いずれかのロジックプログラムを選択したあとの説明をする場合、「視聴チャンネルをtwitter（商品名）へ投稿」の方のロジックプログラムを選択したことを前提とした説明を行う。
【００６１】
ヒューマンインタフェース処理部１１０は、動作装置情報保持部１０７に蓄積されている動作装置情報を用いて動作装置選択画面を生成し、表示する。ヒューマンインターフェース部110は、例えば、動作装置情報を、プログラム蓄積サーバ１６に送信し、プログラム蓄積サーバ１６が、モデル識別子から機器種別を表す文字列（TV,PVR,蓄電池、エアコン、太陽電池パネル、電力メータ）とアイコンに変換して画面を生成し、その画面を表示することができる。また、ヒューマンインターフェース部１１０は、文字列やアイコンを動作装置情報として、動作装置１３から取得して、表示することも可能である。
【００６２】
図７は、ヒューマンインターフェース処理部１１０が、画面に動作装置選択画面を表示した場合の例を示す図である。図７の例では、ＴＶとＰＶＲと蓄電池とエアコンと太陽電池パネルと電力メータのアイコンと文字列を表示する例を示している。
【００６３】
ヒューマンインターフェース処理部１１０は、更に、ロジックプログラム選択画面で選択されたロジックプログラム選択された場合に、選択されたロジックプログラムを動作させることができない動作装置１３について、動作装置選択画面にて、選択不可能であることを表示してもよい。例えば、選択不可能であることを示す表示として、グレイアウトあるいは非表示とする表示を行う。ロジックプログラムとして「視聴チャンネルをtwitter（商品名）へ投稿」を選択した場合、実行可能であるTVとPVRを通常表示し、それ以外の動作装置をグレイアウト表示又は非表示とする。尚、以降の説明では、動作装置選択画面で、いずれかの装置が選択されたことを前提とした説明をする場合、TVを選択したとして説明する。
【００６４】
ヒューマインタフェース処理部１１０は、ロジックプログラム選択画面で選択された動作装置のAPIプログラムに対応するロジックプログラムを取得するようロジックプログラム取得部103に通知する。
【００６５】
ヒューマンインタフェース処理部１１０は、プログラム実行装置情報保持部１０９に保持されたプログラム実行装置情報を基に、プログラム実行装置選択画面を表示する。図８に、プログラム実行装置選択画面の一例を示す。ヒューマンインタフェース処理部１１０は、プロがラム実行装置選択画面を生成する際、プログラム実行装置情報をプログラム蓄積サーバ１６に送信し、プログラム蓄積サーバ１６にてモデル識別子から機器種別を表す文字列（携帯電話、PC）とアイコンに変換して画面を生成することができる。また、これらのアイコンや文字列の情報も、プログラム実行装置情報として、プログラム実行装置１４から取得することも可能である。また、ヒューマンインタフェース処理部１１０は、更に、機器種別を表す文字列だけでなく、個々のプログラム動作装置１３にユーザが付与した名称（健一、健二、Rose）をプログラム実行装置情報に含め、表示することもできる。図８に、その例を示している。
【００６６】
ヒューマンインタフェース処理部１１０は、外部から選択されたプログラム実行装置１４に対して、実行プログラムを送信するように、実行プログラム送信処理部１０５に通知する。
【００６７】
以上が、ヒューマンインタフェース処理部１１０に関する説明である。
【００６８】
APIプログラム取得処理部１０２は、API蓄積情報保持部108に蓄積されているAPI蓄積情報を基に、API蓄積装置12から、APIプログラムを取得する。具体的には、API蓄積情報に含まれるAPI取得URLに、通信処理部１０１を介してアクセスし、APIプログラムを取得する。APIプログラム取得処理部１０２は、取得したAPIプログラムを実行プログラム生成部１０５に送る。また、取得したAPIプログラムのAPI識別子をロジックプログラム取得処理部１０３に送る。
【００６９】
ロジックプログラム取得処理部１０３は、プログラム蓄積サーバ１６から、ヒューマンインタフェース処理部１１０によりロジックプログラム選択画面で選択されたロジックプログラムを取得する。
【００７０】
典型的なケースでは、ロジックプログラム蓄積サーバ１６がWebサーバ機能を有し、ロジックプログラム選択画面を提供する。この際、ロジックプログラム取得処理部１０３は、API識別子をプログラム蓄積サーバ１６に送り、プログラム蓄積サーバ１６はこのAPI識別子に基づきプログラム生成可能なロジックプログラムのみを表示することが好ましい。
【００７１】
ロジックプログラム取得処理部１０３のアクセスするプログラム蓄積サーバ１６のURLは予め与えられているものとする。このURLは、典型的には、Google（商品名）のような検索サービスを用いて得る。
【００７２】
ロジックプログラム取得処理部１０３は、取得したロジックプログラムを実行プログラム生成部１０５に送信する。
【００７３】
実行プログラム生成部１０５は、ＡＰＩプログラム取得処理部102から受信したAPIプログラムとロジックプログラム取得処理部103から取得したロジックプログラムとを用いて、実行プログラムを生成し、実行プログラム送信処理部１０５へ送信する。
【００７４】
図９Ａ〜Ｅは、図３Ａ〜ＣのAPIプログラムと、図４Ａ〜Ｂのロジックプログラムとから生成された実行プログラムの例を示す図である。図９Ａ〜Ｅの例では、Java(登録商標)Scriptを用いているため、図３A〜Ｃで示したＡＰＩプログラムと図４Ａ〜Ｂで示したロジックプログラムとを連結するだけで、図９Ａ〜Ｅの実行プログラムを実現できる。
【００７５】
実行プログラムの生成方法には、様々なものがある。例えば、図９Ａ〜Ｅで示すように、インタプリタ型の言語を用いる場合には、テキストデータで記述されたプログラムの連結で行うことが望ましい。インタプリタ型の言語として、例えば、Java(登録商標)やRuby(商品名)がある。また、実行プログラムの生成に、C言語のようなコンパイラ型の言語を用いる場合には、プログラム実行装置１４上にコンパイラを用意する。そして、プログラム生成装置100の実行プログラム生成部１０５が、APIプログラムとロジックプログラムとをコンパイルする方法を記述したmakefileを生成する。このように、コンパイラ型の言語を用いる場合、実行プログラムは、APIプログラムとロジックプログラムとmakefileとを含む情報としてもよい。
尚、実行プログラムの生成に、コンパイラ型の言語を用いる場合であっても、プログラム実行装置１４のプログラム実行環境を示す識別子をプログラム実行装置１４からの広告メッセージに含めることで、実行プログラム生成部１０５にて、プログラム実行装置１４で実行プログラムが動作するようクロスコンパイルを行うことも可能である。
【００７６】
実行プログラム送信処理部１０５は、実行プログラム生成部１０５から受信した実行プログラムを、ヒューマンインタフェース処理部１１０の指示に従い、プログラム実行装置１４に通信処理部１０１を介して送信する。
【００７７】
通信処理部１０１は、あらかじめ定められた通信手順に従い、ネットワーク17とのデータの送受信を行う。
【００７８】
プログラム実行装置１４は、プログラム生成装置１０から実行プログラムを受信すると、受信した実行プログラムを実行する。図９A〜Ｅで示した実行プログラムの場合、プログラム実行装置14は、動作装置１３（TV）に定期的にアクセスし、前回アクセスしたときと今回アクセスしたときとで、受信チャンネルに変更がある場合に、アプリケーションサーバ１５（twitter（商品名））に通知する。通知するメッセージは、例えば、「いま、Nippon TVを見ています」である。
【００７９】
以下では、本実施形態にかかるシステムを用いた場合の効果を説明する。
【００８０】
例えば、ユーザがTVを買い替えた場合を想定する。つまり、図１のネットワーク１７に接続された動作装置１３の機能が変わった場合を想定する。例えば、買い替えたTVがEPG(Electronic Program Guide :電子番組表)機能が追加されていた場合を考える。このように、買い換えたＴＶが、新しい機能が追加されていた場合、ＡＰＩプログラムとロジックプログラムも、この機能に対応するプログラムとすることで、この機能を活用した実行プログラムを実現できる。例えば、新しいTVのAPIプログラムを、図３Ａ〜Ｃに示したプログラムにさらに電子番組表データをTVから取得するgetEPGInfo()を追加したプログラムとする。そして、ロジックプログラムを、getEPGInfo()に対応するロジックプログラムとする。プログラム実行装置１４は、このような、ロジックプログラムとＡＰＩプログラムとから生成される実行プログラムを用いて、例えば、アプリケーションサーバ１５にメッセージを通知する際に、受信チャネルで受信している番組名に変換して、「いま、Nippon TVのドラマ“春来たる”を見ています」というより詳細なメッセージを作成することができる。
【００８１】
従来は、実行プログラムは、標準通信仕様に依存したプログラムであったため、標準通信仕様が変化しない限り、このように動作装置１３の機能の変化に合わせた柔軟なプログラムを実現できず、動作装置１３の機能に合わせたサービス提供を実現できなかった。しかし、本実施例では、動作装置１３の機能に応じたＡＰＩプログラムを実現でき、そのＡＰＩプログラムに合わせたロジックプログラムを作ることで、動作装置１３の機能を十分に生かした多様な実行プログラムを実現でき、多様なサービスを実現できることとなる。
【００８２】
尚、APIプログラムは、動作装置１３（TV）の製造メーカが作成することが好ましい。また、ロジックプログラムは、製造メーカを含む不特定多数が作成し、例えばネット上のサーバにアップロードできることが好ましい。APIプログラムを、製造メーカが作成すると、ＡＰＩプログラムを動作装置１３の進化に合わせて作成することができる。また、ロジックプログラムを不特定多数の者が作成すると、動作装置１３の進化に合わせて作成することができる。
【００８３】
また、本実施例では、実行プログラムを動作装置13と別に設け、プログラム実行装置14が、アプリケーションサーバ１５と動作装置13にアクセスし、アプリケーションサーバ15と動作装置13との連携を実現している。このようにすることで、例えば、データサイズが大きすぎて扱えないなどの理由で、旧型の動作装置１３では進化したアプリケーションサーバ１５と直接連携できない場合でも、プログラム実行装置１４が、新しいアプリケーションサーバ１５と旧型の動作装置１３との連携を実現することができる。尚、プログラム実行装置１４は携帯電話やPCのようなアプリケーションサーバ１５のサービスを利用する機器であることが望ましい。
【００８４】
尚、第1の実施形態では、アプリケーションサーバ１５、プログラム蓄積サーバ１６、動作装置１３、プログラム生成装置１０、プログラム蓄積サーバ１６、動作装置１３、APＩ蓄積装置１２各々が一台である例を説明した。しかしながら、各々の装置が複数台ある場合にも本実施形態は適用可能である。
【００８５】
例えば、アプリケーションサーバ１５が複数台ある場合について説明する。この場合、プログラム実行装置１４は、Facebook（商品名）の掲示板にて人気の放送番組を取得し、この放送番組を動作装置１３（PVR）に録画予約し、録画したこの番組が再生された場合にその旨をtwitter（商品名）に通知する、という実行プログラムを実行できる。
【００８６】
次に、動作装置１３が複数存在する場合を説明する。例えば、動作装置１３が温度計とエアコンである場合、実行プログラム実行装置14は、温度計から気温を取得し、これが目標値になるようエアコンの設定温度を変更する実行プログラムを実行できる。
【００８７】
また、本実施形態では、IPプロトコルを用いた場合を説明したが、IPv6プロトコルなど、その他の通信プロトコルにも適用可能である。
【００８８】
また、本実施形態のネットワークのメディアは有線・無線のどちらでも使用することが可能である。
【００８９】
また、第1の実施形態に係るプログラム生成装置10は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、通信処理部1とＡＰＩプログラム処理部１０２とロジックプログラム取得処理部１０３と実行プログラム生成部１０４と実行プログラム送信処理部１０５と広告メッセージ処理部１０６と動作装置情報保持部１０７とＡＰＩ蓄積装置情報保持部１０８とプログラム実行装置情報保持部１０９とヒューマンインタフェース処理部１１０とは、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、プログラム生成装置10は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、動作装置情報保持部１０７とＡＰＩ蓄積装置情報保持部１０８とプログラム実行装置情報保持部とは、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。
【００９０】
＜変形例＞
次に、第1の実施形態の変形例を説明する。
【００９１】
図１０は、第1の実施形態の変形例にかかるシステムを示すブロック図である。
【００９２】
第１の実施形態の変形例にかかるシステムにおいては、第1の実施形態で説明した動作装置13とAPI蓄積装置12とが一体となっている点と、プログラム実行装置14とプログラム生成装置10とが一体となっている点が異なる。以下では、動作装置13とAPI蓄積装置12とが一体となった装置を、動作装置20と称する。動作装置20は、API蓄積装置12の機能を備えたAPI蓄積部２０Aを備えている。また、プログラム実行装置14とプログラム生成装置10とが一体となった装置を、プログラム実行装置２２と称する。プログラム実行装置22は、プログラム生成装置10の機能を備えたプログラム生成部２２Ａを備えている。
【００９３】
各々の装置の機能は、第1の実施形態と説明したものと同様であるため、各々の装置の説明は省略する。
【００９４】
尚、動作装置20が備えるAPI蓄積部20Aは、動作装置20にアクセスするためのAPIプログラムを蓄積するものとする。第１の実施例のAPI蓄積装置12は、複数の動作装置20がある場合には、複数の動作装置20のAPIプログラムをまとめて蓄積して管理することを想定していたが、本変形例では、動作装置20毎に、動作装置20に対応したAPIプログラムを記憶するものであるからである。尚、動作装置20が、動作装置20自身にアクセスするための複数のAPIプログラムを記憶することは、想定できる。つまり、動作装置20に、アクセスして、実現したい機能により複数のAPIプログラムを想定できるからである。
【００９５】
次に、第1の実施形態にかかる変形例のシステムにおける動作を説明する。図１１は、図１０のシステムにおける動作シーケンスを示す図である。
【００９６】
また、尚、本変形例のプログラム実行装置22は、図5に示すような、プログラム生成装置10が備える構成に加えて、プログラム実行装置１０が備える機能、つまり、プログラム生成装置10が生成した実行プログラムを実行するプログラム実行部のような機能を備える。尚、プログラム実行装置22は、図５で示した実行プログラム送信処理部105は、備えていなくてもよい。
【００９７】
まず、動作装置２０は、定期的に広告メッセージをブロードキャストあるいはマルチキャストする（Ｓ２０１）。ここで、広告メッセージは、例えばIPパケットにて運ばれる。広告メッセージは、装置種別とプロバイダ識別子とモデル識別子と個体識別子と装置IPアドレスとを含む。
【００９８】
装置種別は、動作装置２０の種別(例えば、TVであるかやPVRであるか)を識別する識別子である。
【００９９】
プロバイダ識別子は、その装置を製造したメーカを識別する識別子である。
【０１００】
モデル識別子は、装置のモデルを識別する識別子である。モデル識別子は、例えば、UUID(Universally Unique Identifier)を用いることが好ましい。UUIDを用いることにより、製造メーカが異なるモデルでも異なる識別子を割り当てることができる。
【０１０１】
個体識別子は、装置を一意に識別する識別子である。個体識別子は、例えば、UUIDを用いることが好ましい。尚、必ずしも、個体識別子単体で、装置１つを重複なく識別するようにしなくてもよい。例えば、モデル識別子と個体識別子の組で、重複ない値を割り当てることができればよい。
【０１０２】
装置IPアドレスは、装置に割り当てられたIPアドレスである。
【０１０３】
以上が、広告メッセージの説明である。
【０１０４】
次に、第1の実施形態の変形例のシステムの動作説明に戻る。
【０１０５】
次に、プログラム実行装置２２は、動作装置２０からAPIプログラムを受信する（Ｓ２０２）。このとき、プログラム実行装置２２は、動作装置２０からの広告メッセージにてそのAPI取得URL（例えば,http://192.168.0.1/api/）を知り、そのIPアドレスに向けてHTTPにてAPIプログラムを要求する。
【０１０６】
次に、プログラム実行装置２２は、プログラム蓄積装置１６からロジックプログラムを受信する（Ｓ２０３）。このとき、プログラム実行装置２２は、予めプログラム蓄積装置１６のIPアドレスを保持していることが望ましい。
【０１０７】
次に、プログラム実行装置２２は、APIプログラムとロジックプログラムから実行プログラムを生成し、この実行プログラムを実行する。プログラム実行装置22は、実行プログラムを実行する際、アプリケーションサーバ１５および動作装置２０にネットワーク17を介してアクセスする（Ｓ２０４、Ｓ２０５）。
【０１０８】
次に、動作装置２０の構成を説明する。図１２は、動作装置２０の構成を示すブロック図である。
【０１０９】
本体処理部２０７は、動作装置２０の本来の動作に関わる処理を行う。ここで、本来の動作とは、例えば、動作装置２０がTVである場合には、リモコン信号および放送波信号および外部ボタンの押下に従い、TV放送信号を受信し、放送信号を復調し、画面表示を行うといった動作である。
【０１１０】
通信処理部２０１は、あらかじめ定められた通信手順に従い、ネットワーク17とのデータの送受信を行う。
【０１１１】
広告メッセージ送信部２０２は、予め設定されている情報を用いて、広告メッセージを定期的に送信する。ここで、広告メッセージが含むAPI取得URLは、後述するAPIプログラム蓄積部２０６に複数のAPIプログラムが保持されている場合には、各々のＡＰＩプログラムを指定して取得できるように、APIプログラム毎にURLを用意することが好ましい。
【０１１２】
APIプログラム蓄積部２０６は、APIプログラムを保持する。複数のAPIプログラムを保持できることが好ましい。
【０１１３】
APIプログラム更新処理部２０３は、APIプログラム蓄積部２０６内のAPIプログラムの追加・削除・更新処理を、ネットワーク17を介して行う。
【０１１４】
APIプログラム送信処理部２０４は、ネットワーク17を介して、APIプログラム取得要求を受信すると、APIプログラム取得要求に含まれるAPI取得URLに従って要求されたAPIプログラムをAPIプログラム蓄積部206より抽出し、ネットワーク17を介して要求者に送信する。
【０１１５】
動作コマンド処理部２０５は、ネットワーク17を介して、動作コマンドを受信すると、これに従って本体処理部２０７へ制御コマンドを送信する。また、動作コマンドが動作状態の取得を要求する場合には、本体処理部２０７から対応する情報を抽出し、当該抽出した情報を、ネットワーク17を介して動作コマンド送信者に送信する。
【０１１６】
本実施例の動作装置２０では、APIプログラムはプログラム実行装置２２に向けて高々一度送信すればよい。これに対して、従来のHTTPサーバを有し、外部のWebブラウザによりネットワークを介して制御される制御装置では、Webブラウザをユーザが操作し、これに対応した制御コマンドを、HTTP POSTあるいはGETデータとして動作装置に送信し、これを受信した動作装置は、制御コマンドに従った動作を行うと同時に、応答を返す。この応答には、続く制御コマンドをWebブラウザから送信するためのプログラムが含まれており、結果として制御コマンドを受信するたびに制御のためのプログラムを動作装置は送信している。本実施例では、APIプログラムは高々一度送信すればよいため、ネットワークに与える負荷を小さくでき、さらに動作装置２０の通信処理に要する処理量を削減することができる。
【０１１７】
以上、第1の実施形態の変形例を説明したが、第1の実施形態の変形例は、上述したように、動作装置２０とプログラム実行装置２２とが、各々、第1の実施形態で説明した２つの装置を一体とした点が異なり、その他の点は同様の機能である。したがって、本変形例のシステムによれば、第1の実施形態で説明した効果と同様の効果を達成することができる。
【０１１８】
続けて、第２の実施形態と第３の実施形態を説明するが、第２の実施形態と第３の実施形態は、第１の実施形態で説明したシステムの具体例である。
【０１１９】
＜第２の実施形態＞
図１３は、第2の実施形態にかかるシステムを示すブロック図である。
【０１２０】
第2の実施形態にかかるシステムは、プログラム蓄積サーバ１６と、アプリケーションサーバ１５Ａ及び１５Ｂと、電気自動車３０と、がネットワーク１７介して接続されている。電気自動車30は、スマートフォン３０Aと蓄電池３０Ｂとナビゲーション装置３０Ｃとを有する。蓄電池３０Ｂとスマートフォン３０Aとは、車内ネットワーク３０Ｄ（ex 無線LAN, Bluetooth, CAN(Car area network)）を介して接続されている。ナビゲーション装置３０Ｃとスマートフォン３０Aとは、車内ネットワーク３０Ｄにて接続されている。尚、図１３の例では、蓄電池３０Ｂとスマートフォン３０Ａとの間、ナビゲーション装置３０Ｃとスマートフォン３０Ａとの間、各々の間のネットワークが同一の車内ネットワーク３０Ｄであるとしたが、各々のネットワークが異なるネットワークであってもよい。
【０１２１】
ここで、蓄電池３０Ｂ及びナビゲーション装置３０Ｃは、図１２で示した第1の実施形態の変形例の動作装置２０と同様の機能を有する。蓄電池３０Ｂ及びナビゲーション装置３０Ｃは、動作装置20と同様、APIプログラム蓄積部206を有している。スマートフォン３０Ａは、第1の実施形態の変形例のプログラム実行装置22と同様の機能を有する。このように第２の実施形態にかかるシステムは、動作装置20が２台ある例を示している。
【０１２２】
スマートフォン30Aは、蓄電池30ＢのAPIプログラム蓄積部206に蓄積されているAPIプログラムを用いることにより、ネットワークを介して蓄電池30Bにアクセスすることで、蓄電池３０Ｂの予め定められた短期間毎（例えば、１分毎）の充放電量と、電気残量、温度を取得することができる。
【０１２３】
また、スマートフォン30Aは、ナビゲーション装置30CのAPIプログラム蓄積部206に蓄積されているAPIプログラムを用いることにより、ネットワークを介してナビゲーション装置30Cにアクセスすることで、電気自動車３０の現在の位置情報および速度情報（進行方向を含む）を得ることができる。
【０１２４】
次に、第2の実施形態のシステムの動作を説明する。
【０１２５】
図１４は、第2の実施形態にかかるシステムの動作を示すシーケンス図である。
【０１２６】
まず、蓄電池３０Ｂは、広告メッセージを定期的に送信する（Ｓ３０１）。
【０１２７】
また、ナビゲーション装置３０Ｃは広告メッセージを定期的に送信する（Ｓ３０２）。
【０１２８】
次に、スマートフォン３０Aは、Ｓ３０１及びＳ３０２で取得した広告メッセージに含まれるAPI取得URLを用いて、蓄電池３０Ｂ及びナビゲーション装置３０ＣからAPIプログラムを取得する（Ｓ３０３、Ｓ３０４）。
【０１２９】
次に、スマートフォン３０Aは、予め設定されたプログラム蓄積装置１６から、ロジックプログラムを取得する（Ｓ３０５）。そして、スマートフォン３０Ａは、ロジックプログラムと蓄電池30B及びナビゲーション装置30Cから取得したAPIプログラムとから、実行プログラムを生成する。そして、スマートフォン３０Ａは、実行プログラムを実行する。実行プログラムの実行の際、スマートフォン３０Ａは、蓄電池３０Ｂとナビゲーション装置３０Ｃとアプリケーションサーバ１５及び１５Ｂにアクセスする（Ｓ３０６〜Ｓ３０９）。
【０１３０】
より具体的には、スマートフォン３０Ａは、実行プログラムを実行することで、ナビゲーション装置３０Ｃにアクセスして（Ｓ３０７）、位置情報及び速度情報を取得し、取得した位置情報及び速度情報を、アプリケーションサーバ15Aに送信し、周辺地図情報を取得する（Ｓ３０８）。ここで、アプリケーションサーバ15Ａは、周辺地図情報を提供するサービスを行っているとする。
【０１３１】
また、スマートフォン３０Ａは、実行プログラムを実行することで、蓄電池３０Ｂから放電量と電気残量と温度とを取得し（Ｓ３０６）、Ｓ３０７で取得する速度情報と併せて、アプリケーションサーバ15Bに送信し、走行可能距離を得る（Ｓ３０９）。ここで、アプリケーションサーバ15Bは、電気自動車３０の走行可能距離算出サービスを行っているとする。
【０１３２】
また、スマートフォン３０Ａは、実行プログラムを実行することで、周辺地図情報と走行可能距離とから、走行可能範囲３１Ｃをスマートフォン３０Aの画面３１Ａ上に表示する。
【０１３３】
図１５に、スマートフォン３０Ａが、画面上に表示する走行可能範囲３１Ｃの例を示す。
【０１３４】
図１５の例では、電気自動車３０が右方向に進行していることを前提としているため、現在地３１Ｂを中心とした地図ではなく、現在地３１Ｂより右側の領域を多く表示している。また、図１５の例では、右側に表示している道路の混雑が多いことを前提としているため、赤線で囲まれた走行可能領域は、右側は左側と比べて狭くなっている。
【０１３５】
以上の例のように、複数の電気自動車３０が自身の位置をアプリケーションサーバ15Bに送信することで、アプリケーションサーバ15Bは、道路の混雑状況を加味した走行可能距離を計算することができる。また、蓄電池３０Ｂの電気残量を正確に求めることは一般に難しいが、走行可能距離の計算をアプリケーションサーバ側で実行することで、実データの収集およびこれに基づく算出アルゴリズムの改良、そして新しいアルゴリズムの導入が可能である。また、この改良後の算出アルゴリズム若しくは新たに導入したアルゴリズムをロジックプログラムとしてスマートフォン３０Aに送信することで、スマートフォン30Ａは、電気自動車３０設計当時の計算能力では実行できない複雑な算出アルゴリズムを実行することができる。この場合は、スマートフォン３０Aがアプリケーションサーバと常に通信する必要が無く、スマートフォン３０Aの消費電力を削減するという効果もある。
【０１３６】
＜第3の実施形態＞
図16は、第3の実施形態に係るシステムを示すブロック図である。
【０１３７】
第3の実施形態に係るシステムは、プログラム蓄積サーバ１６と、二つのアプリケーションサーバ１５Ａ及び１５Ｂと、エネルギー管理サーバ４１と建物４０Ａと建物４０Ｂとが、ネットワーク１７を介して接続されている。
【０１３８】
また、建物４０Ａは、電力計４０１Ａと蓄熱装置４０２Ａとを備えている。電力系４０１Ａと蓄熱装置４０２Ａとはネットワーク４０３Ａを介して接続されている。建物４０Ｂは、電力系４０１Ｂと蓄熱装置４０２Ｂとを備えている。電力系４０１Ｂと蓄熱装置４０２Ｂとは、ネットワーク４０３Ｂを介して接続されている。
【０１３９】
本実施例のエネルギー管理サーバ４１は、第１の実施形態の変形例のプログラム実行装置２２の機能を有する。また、蓄熱装置４０２Ａ及び４０２Ｂは、動作装置２０の機能を有する（図１０を参照）。
【０１４０】
電力計４０１Ａは、建物４０Ａの消費電力を測定し、測定結果をアプリケーションサーバ１５Aへ送信する。電力計４０１Ａの消費電力測定の細かさは様々な形態を考えることができ、建物内のフロア毎や部屋毎やコンセント毎に消費電力を測定できる。電力計４０１Ｂも同様の機能を有する。
【０１４１】
蓄熱装置４０２Ａは、ヒートポンプなどの熱発生部（又は吸熱部）と、水のタンクによる温熱又は冷熱を蓄積する熱蓄積部とを備える。熱蓄積部は、冷熱については、冷水ではなく氷の形で熱を蓄積することも可能である。蓄熱装置４０２Ａは、例えば深夜のような電気料金（あるいはガス料金）の安い時間帯の電力でヒートポンプを駆動し得られた熱を蓄積する。蓄積した熱は、電気料金の高い時間帯に給湯、空調、床暖房等の用途に使用することで、ユーザには電気料金削減、電気会社にはピーク電力の削減の効果を実現できる。時間とともに、蓄積した熱は環境へ散逸する。したがって、次の蓄熱タイミング（一般には翌日の深夜）までに、必要最小限の熱量を見積もり、これを蓄熱することが重要である。蓄熱装置４０２Ｂも同様の機能を有する。
【０１４２】
エネルギー管理サーバ４１は、蓄熱量を見積もり、見積もった蓄熱量を蓄熱装置402Ａに指示する。
【０１４３】
アプリケーションサーバ１５Bは、例えば気象庁の天気予報サイトであり、本日から翌日までの天気情報を提供している。
【０１４４】
次に、第3の実施形態にかかるシステムの動作シーケンスを説明する。図１７は、第3の実施形態に係るシステムの動作を示すシーケンス図である。
【０１４５】
まず、電力計４０１Aと電力計４０１Bは、定期的に、アプリケーションサーバ１５Aに対して消費電力量を通知する（Ｓ４０１、Ｓ４０２）。この消費電力量は、予め定められた期間（例えば、一分）毎に消費した電力量である。この消費電力の測定期間と消費電力量の通知間隔は一致している必要は無い。通知する消費電力量には、電力を消費した時刻情報が記されていることが望ましい。時刻情報は、消費電力測定期間と消費電力量通知間隔とが一致している場合には、省略することが可能である。
【０１４６】
次に、エネルギー管理サーバ４１は、電力計４０１A及びBのAPIプログラムを、電力計４０１A及びBから取得する（Ｓ４０３、Ｓ４０４）。尚、本実施例では、説明を省略しているが、電力計４０１Ａ及びＢは、広告メッセージをエネルギー管理サーバ４１のアドレス宛てに送信することで、エネルギー管理サーバ４１は、電力計４０１Ａ及びＢからAPIプログラムを取得可能となる。尚、APIプログラムの取得先は、必ずしも電力計４０１Ａ及びＢである必要はなく、実施例1で示したように、電力計４０１Ａ及びＢ以外の機器から取得する構成も可能である。
【０１４７】
次に、エネルギー管理サーバ４１は、ロジックプログラムをプログラム蓄積サーバ１６から取得する（Ｓ４０５、Ｓ４０９）。ここで、エネルギー管理サーバ41が取得するロジックプログラムは、蓄熱装置のユーザが予め選択可能であることが好ましい。例えば、ユーザは、蓄熱装置の使用人数や家族構成（女性が3人いるなど）により、ロジックプログラムを選択する。ユーザは、ロジックプログラムを、例えばWebブラウザを使用して選択する。
【０１４８】
エネルギー管理サーバ４１は、ロジックプログラムとAPIプログラムとから実行プログラムを生成し、実行プログラムを実行する。本実施形態では、蓄熱装置４０２Aと蓄熱装置４０２Bのユーザが異なる場合、蓄熱装置ごとに異なる実行プログラムを実行することが望ましい。
【０１４９】
エネルギー管理サーバ４１は、実行プログラムを実行することで、アプリケーションサーバ１５B、アプリケーションサーバ１５Ａより天候情報を取得し（Ｓ４０６、Ｓ４１０）、天気情報を用いて蓄熱装置４０２Ｂ、蓄熱装置４０２Ａの蓄熱量を制御する（Ｓ４０７、Ｓ４１１）。
【０１５０】
さらに、アプリケーションサーバ１５Aは、ユーザ毎の消費電力量の一定期間（例えば、一時間）毎の消費電力量を、例えば一カ月分のデータ提供している。そして、ユーザは、Webブラウザを使って、その一カ月分のデータにアクセスすることが可能である。アプリケーションサーバ１５Ａがこのような機能を備えることで、例えば、Facebook（商品名）の友達関係のあるユーザ間で、これらの消費電力量を共有することも可能である。これにより、ユーザ間で電力節約のコツや、使用しているロジックプログラムの情報を共有することができる。そして、好みの（典型的には、家屋の大きさや断熱性能、あるいは家屋内の機器構成やライフスタイルの似た友人の中で、最も消費電力の少ない人間の使用しているロジックプログラム）ロジックプログラムを選び直すことも可能である。
【０１５１】
エネルギー管理サーバ４１で実行されている実行プログラムのアルゴリズム例について説明する。図１８は、エネルギー管理サーバ４１で実行する実行プログラムの蓄熱量制御のアルゴリズムの例を示すフローチャートである。
【０１５２】
まず、深夜電力期間(例えば、AM０時からAM5時)開始前に、ユーザ家屋地域の翌日の天候情報をアプリケーションサーバ１５Aから取得する（Ｓ５０１）。本例では、天候情報として気温を取得する。なお、天候情報は、気温に限られない。例えば、太陽光発電装置や風力発電装置をユーザが使用している場合には、その発電量を考慮するため日照量や風量を天候情報とする。
【０１５３】
次に、実行プログラムは、翌日の使用熱量を予測する（Ｓ５０２）。実行プログラムは、ユーザの熱使用履歴データ（日付、気温、使用熱量）を保持しており、その履歴データの中から翌日の気温に一致する気温に対応する使用熱量を抽出し、抽出した使用熱量の平均を取ることで、翌日の使用熱量を予測する。ここで、翌日の気温と一致する気温とは、気温が完全一致していなくてもよく、気温差がある一定値以内の気温であってもよい。また、抽出した使用熱量の平均を取る際に、単純な加重平均ではなくてもよい。例えば、新しいデータほど重みが大きい重み付き平均など様々な算出の方法が考えられる。また、熱使用履歴データは、一日毎ではなくより細かい時間粒度（例えば一時間毎）に保持してもよい。
【０１５４】
次に、実行プログラムは、Ｓ５０２で予測した使用熱量と同じ熱量を蓄熱するよう蓄熱装置に通知する（Ｓ５０３）。
【０１５５】
次に、実行プログラムは、定期的に蓄熱装置から使用熱量を取得し、これを熱使用履歴データに追加する（Ｓ５０４）。
【０１５６】
以上が、実行プログラムのアルゴリズムである。
【０１５７】
以上説明したように、エネルギー管理サーバ４１において、ユーザが選んだロジックプログラムを動作させることにより、ユーザの使用機器や使用条件に適したエネルギー制御を実現することができる。また、Facebook（商品名）のようなソーシャルネットワークあるいは掲示板サービスと組み合わせることで、ユーザによる最適なロジックプログラムの選択を実現できる。
【０１５８】
以上説明した少なくとも１つの実施形態の効果は、機器の標準通信仕様の変更があるか否かにかかわらず、ネットワーク上のサービスを、機器の機能に合わせて、機器の機能を利用したサービスを提供できるようなプログラムを生成するプログラム生成装置を提供することができる。
【０１５９】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１６０】
１０・・・プログラム生成装置、１２・・・API蓄積装置、１３、２０・・・動作装置、１４、２２・・・プログラム実行装置、１５、１５A、１５B・・・アプリケーションサーバ、１６・・・プログラム蓄積サーバ、１７、３０Ｄ、４０３Ａ、４０３Ｂ・・・ネットワーク、１０１、２０１・・・通信処理部、１０２・・・APIプログラム取得処理部、１０３・・・ロジックプログラム取得処理部、１０４・・・実行プログラム生成部、１０５・・・実行プログラム送信処理部、１０６・・・広告メッセージ処理部、１０７・・・動作装置情報保持部、１０８・・・API蓄積装置情報保持部、１０９・・・プログラム実行装置情報保持部、１１０・・・ヒューマンインタフェース処理部、２０A・・・API蓄積部、２２A・・・プログラム生成部、２０２・・・広告メッセージ送信部、２０３・・・API更新処理部、２０４・・・APIプログラム送信処理部、２０５・・・動作コマンド処理部、２０６・・・APIプログラム蓄積部、２０７・・・本体処理部、３０・・・電気自動車、３０A・・・スマートフォン、３０Ｂ・・・蓄電池、３０Ｃ・・・ナビゲーション装置、３０Ｄ・・・ネットワーク、３１Ａ・・・画面、３１Ｂ・・・現在地、３１Ｃ・・・走行可能範囲、４１・・・エネルギー管理サーバ、４０A、４０Ｂ・・・建物、４０１A、４０１Ｂ・・・電力計、４０２A、４０２Ｂ・・・蓄電装置。
【技術分野】
【０００１】
本発明の実施形態は、プログラム生成装置に関する。
【背景技術】
【０００２】
インターネットの発達に伴いパソコン以外の様々な機器が通信機能を有するようになってきている。通信機能を有する機器としては、例えば、携帯電話、電力メータ、エアコンやTV等の家電機器、そして車など多様な機器がある。
【０００３】
一方、近年、パソコン以外の様々な機器が、通信機能を有するようになることに伴い、クラウドサービス等のネットワーク上のサービスを、通信機能を有する機器と連携した新たなサービス（以下、ネット連携サービスと称する。）を提供する動きがある。このようなネット連携サービスにより、より多様なサービスを、サービス提供を受けるユーザは受け取ることができる。なお、ネットワーク上のサービスは、例えば、当該サービスを提供するASP（Application Service Provider）がインターネット上に配置するサーバが提供する。ネット連携サービスの一例として、ネットワーク上のサービスがクラウド連携サービスである場合を考える。そして、例えば、クラウド連携サービスの一例として、クラウドサービスがtwitter（商品名）である場合であって、かつ通信機能を有する機器がテレビである場合を例に考える。この場合、クラウド連携サービスとして、ユーザのテレビの受信チャネルを自動的に取得して、twitter（商品名）上に、現在、見ているテレビのチャネルを自動的に投稿するサービスを想定できる。
【０００４】
従来、機器の通信機能を設計する際に、その通信仕様（通信手順）は、例えばDLNA(Digital Living Alliance)のような標準策定団体にて、標準化が行われてきた。その結果、異なるメーカの機器であっても、同じ標準通信仕様に従うことが一般的であり、同一メーカの新機種と旧機種であっても、同一の通信仕様標準化により各機器が共通した標準通信仕様に従うことが一般的であった。
【０００５】
また、従来、ネット連携サービスを実行するためプログラムは、標準通信仕様にしたがった機器と連携するための機能と、その機能を用いて実行するサービスを提供するための機能とを併せ持ったプログラムが生成されていた。つまり、ネット連携サービスを実行するためのプログラムは、標準通信仕様に依存したプログラムとなっていた。
【０００６】
一般的に、クラウドサービス等のネットワーク上のサービス進化の速度は非常に速い一方で、機器の標準通信仕様の進化は遅い。機器の通信仕様の進化が遅い理由は、通信仕様の普及には時間がかかるためである。通信仕様の普及にかかる時間は、古い通信仕様との互換性の容易さや通信仕様を備える機器の買い替えサイクルに依存する。例えば、エアコンは10年という長い使用期間のため、同じ通信仕様を長く使い続けることが予想され、標準通信仕様の進化が遅いことが想定される。このため、クラウド連携サービス等のネットワーク上のサービスと通信機能を有する機器と連携したネット連携サービスは、クラウドサービス等のネットワーク上のサービスが進化しても、使用する標準通信仕様が進化しない故に、進化が難しいという課題がある。
【０００７】
また、半導体技術の進化の速度は速く機器の機能は急速に進化する一方で、機器の標準通信仕様の進化は遅い。例えば、モデルチェンジにより機器に機能を追加しても、標準通信仕様がその機能をサポートしていない仕様である場合もある。このような場合、ネット連携サービスは、サービス提供に当たり、モデルチェンジにより機器に追加された追加機能を利用できないという課題がある。例えば、先述のクラウド連携サービスの一例を用いて考える。例えば、TVに、番組表を有する機能を追加した場合であって、標準通信仕様には、番組表を取得する機能を有しない場合を考える。この場合、クラウド連携サービスとして、番組表のデータを用いたサービスを提供できない。例えば、twitter（商品名）上に、現在、見ているテレビの番組名を自動的に投稿するサービスを提供できない。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開2009-110300号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の一側面は、機器の標準通信仕様の変更があるか否かにかかわらず、ネットワーク上のサービスを、機器の機能に合わせて、機器の機能を利用したサービスを提供できるようなプログラムを生成するプログラム生成装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一観点にかかるプログラム生成装置は、制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第１プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第１サービスとを連携した連携サービスを実現する第２プログラムとを用いて、前記連携サービスを実現する第３プログラムを生成する生成部を有する。
【図面の簡単な説明】
【００１１】
【図１】本発明の第1の実施形態にかかるシステムを示すブロック図。
【図２】図1のシステムにおける動作を示すシーケンス図。
【図３Ａ】動作装置１３がTVである場合のAPIプログラムの例を示す図。
【図３Ｂ】動作装置１３がTVである場合のAPIプログラムの例を示す図。
【図３Ｃ】動作装置１３がTVである場合のAPIプログラムの例を示す図。
【図４Ａ】ロジックプログラムの例を示す図。
【図４Ｂ】ロジックプログラムの例を示す図。
【図５】図１のシステムにおけるプログラム生成装置１０を示すブロック図。
【図６】ヒューマンインタフェース処理部110が、画面にロジックプログラム選択画面を表示した場合の例を示す図。
【図７】ヒューマンインターフェース処理部１１０が、画面に動作装置選択画面を表示した場合の例を示す図。
【図８】プログラム実行装置選択画面の一例を示す図。
【図９Ａ】実行プログラムの例を示す図。
【図９Ｂ】実行プログラムの例を示す図。
【図９Ｃ】実行プログラムの例を示す図。
【図９Ｄ】実行プログラムの例を示す図。
【図９Ｅ】実行プログラムの例を示す図。
【図１０】本発明の第1の実施形態の変形例にかかるシステムを示すブロック図。
【図１１】図１０のシステムにおける動作を示すシーケンス図。
【図１２】図１０の動作装置２０の構成を示すブロック図。
【図１３】本発明の第2の実施形態にかかるシステムを示すブロック図。
【図１４】図１３のシステムにおけるシーケンス図。
【図１５】スマートフォン３０Ａが、画面上に表示する走行可能範囲３１Ｃの例。
【図１６】本発明の第３の実施形態にかかるシステムを示すブロック図。
【図１７】図１４のシステムにおけるシーケンス図。
【図１８】図１６のエネルギー管理サーバ４１で事項する実行プログラムの蓄熱量制御のアルゴリズムを示すフローチャート。
【発明を実施するための形態】
【００１２】
以下、本発明の実施の形態について、図面を参照しながら説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１３】
＜第１の実施形態＞
図1は、本発明の第1の実施形態にかかるシステムを示すブロック図である。
【００１４】
本発明の第1の実施形態に係るシステムは、プログラム生成装置１０と、API蓄積装置１２と、動作装置１３と、プログラム実行装置１４と、アプリケーションサーバ１５と、プログラム蓄積サーバ１６と、がネットワーク１７を介して接続されている。
【００１５】
動作装置１３とは、ユーザに対してサービス動作を行う装置である。動作装置１３は、例えばTVやPVR（Personal Video Recorder:ハードディスクレコーダ）である。
【００１６】
アプリケーションサーバ１５は、ネットワークを介して、サービス利用者に対して、サービスを提供するサーバである。アプリケーションサーバ１５が、提供するサービスは、例えば、クラウドサービスである。
【００１７】
API蓄積装置１２は、APIプログラムを蓄積するとともに、ネットワーク１７を介して、ＡＰＩプログラムを他の装置に提供する装置である。ここで、ＡＰＩ(Application Program Interface)プログラム（請求項１の第１プログラムに対応する。）は、動作装置１３に、ネットワーク１７を介してアクセスするための通信手順を実現するプログラムである。ここで、動作装置１３に、ネットワーク１７を介してアクセスするための通信手順は、動作装置１３にアクセスして実現すること（例えば、動作装置１３の制御若しくは、動作装置の機能の利用等）によって異なる。そして、動作装置１３にアクセスして実現できることは、動作装置１３が有する機能によって異なる。したがって、ＡＰＩプログラムは、動作装置１３が有する機能や、動作装置１３にアクセスして実現したいことによって、異なるプログラムが割り当てられる。より具体的には、図１のシステムの動作装置１３の機種が変わった場合、その機種に応じたＡＰＩプログラムが生成される。また、複数の動作装置１３がある場合、その動作装置１３毎にＡＰＩプログラムが生成される。また、一つの動作装置１３に対して、実現したい目的に応じて、複数のＡＰＩプログラムを生成することもある。
【００１８】
プログラム蓄積サーバ１６は、ＡＰＩプログラムを利用するプログラムであって、アプリケーションサーバ１５が提供するサービスと動作装置１３とを連携させるプログラムであるロジックプログラム（請求項１の第２のプログラムに対応する。）を蓄積するとともに、ネットワーク１７を介して他の装置に提供する装置である。
【００１９】
プログラム生成装置１０は、APIプログラムとロジックプログラムを基に、アプリケーションサーバ１５が提供するサービスと動作装置１３の機能とを連携させる実行プログラム（請求項１の実行プログラムに対応する。）を生成するとともに、実行プログラムをネットワーク１７を介して他の装置に提供する装置である。ここで、実行プログラムは、後述するプログラム実行装置１４が実行できるプログラムである。実行プログラムは、プログラム実行装置１４が実行可能であればその形式を問わない。バイナリ形式のプログラムでなくてもよい。実行プログラムの形式は、例えば、Perl、Java(登録商標)Script、Ruby(商品名)、Java(登録商標)である。
【００２０】
プログラム実行装置１４は、実行プログラムを実行する機能を有する。
【００２１】
図1では、アプリケーションサーバ１５と、プログラム蓄積サーバ１６と、プログラム生成装置１０と、プログラム実行装置１４と、動作装置１３と、API蓄積装置１２とが各々一台ずつである例を示しているが、各々複数台存在する構成してもよい。
【００２２】
次に、図２を用いて、図１のシステムの動作を説明する。図２は、図１のシステムの通信シーケンスを示す図である。
【００２３】
プログラム実行装置１４と動作装置１３とAPI蓄積装置１２とは、定期的に、広告メッセージをブロードキャスト又はマルチキャストする（Ｓ１０１〜Ｓ１０３）。広告メッセージは、例えば、装置種別とプロバイダ識別子とモデル識別子と装置ＩＰアドレスとを含む。ここで、広告メッセージは、例えばIPパケットを用いて運ばれる。
【００２４】
ここで、広告メッセージが含む各情報の説明を行う。
【００２５】
装置種別とは、プログラム実行装置１４、API蓄積装置１２、動作装置１３各々を互いに識別する識別子である。また、装置種別は、動作装置１３の種別も識別できる識別子であることが好ましい。動作装置の種別とは、例えば、TVやPVRであるかを示す種別である。
【００２６】
プロバイダ識別子は、装置を製造したメーカを識別する識別子である。
【００２７】
モデル識別子は、装置のモデルを識別する識別子である。モデル識別子は、例えば、UUID(Universally Unique Identifier)を用いることが好ましい。UUIDを用いることにより、製造メーカが異なるモデルでも異なる識別子を割り当てることができる。
【００２８】
個体識別子は、装置を一意に識別する識別子である。個体識別子は、例えば、UUIDを用いることが好ましい。尚、必ずしも、個体識別子単体で、装置を一意に識別する識別子としなくてもよい。例えば、モデル識別子と個体識別子との組み合わせで、装置を一意に識別できるようにしてもよい。
装置IPアドレスは、装置に割り当てられたIPアドレスである。
【００２９】
以上が、広告メッセージが含む情報の説明である。
【００３０】
次に、図２を用いて、本実施形態のシステムの動作説明を続ける。
【００３１】
次に、プログラム生成装置１０は、ＡＰＩ蓄積装置12から取得した広告メッセージを参照し、API蓄積装置１２にAPIプログラムを要求し、ＡＰＩプログラムを受信する（Ｓ１０４）。プログラム生成装置１０は、ＡＰＩプログラムを要求する際、API蓄積装置１２から取得した広告メッセージに含まれる装置ＩＰアドレス（API取得URL：例えば,http://192.168.0.1/api/）に向けて、HTTPを用いて、APIプログラムを要求する。
【００３２】
次に、プログラム生成装置１０は、プログラム蓄積サーバ１６から取得した広告メッセージを参照し、プログラム蓄積サーバ１６にロジックプログラムを要求し、ロジックプログラムを受信する（Ｓ１０５）。この際、プログラム生成装置１０は、ロジックプログラムを要求する際、プログラム蓄積サーバ１６から取得した広告メッセージに含まれる装置ＩＰアドレスにむけて、ロジックプログラムを要求する。
【００３３】
次に、プログラム生成装置１０は、取得したAPIプログラムとロジックプログラムを用いて、実行プログラムを生成する。そして、生成した実行プログラムをプログラム実行装置１４に向けて送信する（Ｓ１０６）。ここで、プログラム生成装置１０は、広告メッセージで取得したプログラム実行装置１４のIPアドレスに向けて、HTTPを用いて、実行プログラムを送信する。
【００３４】
次に、プログラム実行装置１４は、受信した実行プログラムを実行する。プログラム実行装置１４は、実行プログラムを実行する際に、アプリケーションサーバ１５および動作装置１３にネットワーク１７を介してアクセスする（Ｓ１０７、Ｓ１０８）。
【００３５】
プログラム実行装置１４が実行プログラムを実行することで、動作装置１３とアプリケーションサーバ１５との連携を実現することができる。連携動作の詳細については、具体例を用いて、後述する。
【００３６】
以上が、図１のシステムの動作シーケンスの説明である。
【００３７】
本実施形態では、動作装置１３毎に動作装置１３にアクセスするための通信手順として、システム全体であらかじめ決められた標準仕様でなく、動作装置１３毎に定められたAPIプログラムを用いている。通信仕様が、システム全体で定められていないため、動作装置１３とアプリケーションサーバ１５とを独立に開発・設置することが可能となる。また、動作装置１３の機能に応じたＡＰＩプログラムを実現できるため、ＡＰＩプログラムを用いた実行プログラムで、動作装置１３にアクセスすることで、動作装置１３の機能を生かした連携サービスを実現できる。
【００３８】
また、本実施形態では、実行プログラムを、動作装置１３とは別のプログラム実行装置１４にて実行する。この結果、実行プログラムが、動作装置１３では扱えない計算量を要求する場合であっても、動作させることができる。特に、アプリケーションサーバ１５がASPによるインターネット上のサーバであり、プログラム実行装置１４がソフトフォーンやPCのようなASPの提供するサービス（ASPサービス）を利用する装置である場合には、急速に進化するASPサービスに追従する計算能力をプログラム実行装置１４が有することが期待できる。
【００３９】
次に、ＡＰＩプログラムの一例を説明する。尚、本実施例では、動作装置１３にアクセスするためのプログラムとして、ＡＰＩを含むプログラムであるＡＰＩプログラムを例にとって説明するが、これに限られない。つまり、動作装置１３にアクセスする手順を示すプログラムであればよく、必ずしも、ＡＰＩを有しているプログラムである必要はない。
【００４０】
図３Ａ〜Ｃは、動作装置１３がTVである場合のAPIプログラムの例を示す図である。
【００４１】
図３Ａ〜Ｃで示したAPIプログラムはJava(登録商標)Scriptで書いた疑似コードである。ＡＰＩプログラム(ファイルapi.js)は、動作装置１３毎に設定され、外部の装置（例えば、プログラム実行装置１４）は、このＡＰＩプログラムで定められた通信手順に従って、動作装置１３にアクセスすることができる。尚、ＡＰＩプログラムは、本実施例では、ＡＰＩプログラム蓄積装置１２が保持していてもよいし、当該ＡＰＩプログラムを用いてアクセスできる動作装置１３に保持させていてもよい。
【００４２】
図３のＡＰＩプログラムでは、<API_Functions>と</API_Functions>との間に、動作装置１３にアクセスするためのAPI関数名が記されている。図３の例では、getApiInfo() 、readCurrentCh() 、setCurrentCh() 、readChList() といった関数が定められている。
【００４３】
getApiInfo()は、動作装置１３にアクセスして、APIプログラムに関する情報を得るためのAPIである。
【００４４】
ここで、ＡＰＩに関する情報とは、具体的には、APIプログラムを識別するAPI識別子と、APIプログラムを用いてアクセスする動作装置のモデル識別子を示すターゲットモデル識別子とを含む情報である。図３の例では、API識別子は、0c91356c-c16a-44c7-9709-448993b6ce07であり、ターゲットモデル識別子は、8699e324-3701-4c31-9a29-abdfe99ea93dである。
【００４５】
readCurrentCh()は、動作装置１３にアクセスして、動作装置１３（本例では、テレビ）が受信している放送の受信チャンネルを得るためのAPIである。このAＰＩを用いて、例えば、受信チャンネルのチャンネル番号（chNum）と、チャンネル名(chName)と、放送提供者に一意に割り当てられた放送提供者識別子（providerId）を得る。
【００４６】
setCurrentCh()は、動作装置１３にアクセスして、動作装置１３が受信する受信チャネルを設定するためのAPIである。このＡＰＩを用いて、チャンネル番号を与えることで、動作装置１３は、指定されたチャンネルに受信チャネルを設定する。
【００４７】
readChList()は、動作装置１３であるテレビが受信可能な受信チャネルの情報を得るためのAPIである。このＡＰＩを用いることで、具体的には、受信可能な各受信チャネルのチャンネル番号（chNum）とチャンネル名(chName)と放送提供者識別子（providerId）とを得る。
【００４８】
図４Ａ〜Ｂは、ロジックプログラムの例を示す。
【００４９】
図４Ａ〜Ｂで示すロジックプログラムは、ユーザがTVの受信チャンネルを変えた場合に、その旨をtwitter（商品名）に投稿するプログラムの疑似コードである。
【００５０】
このロジックプログラムでは、main()を用いて、60秒毎に受信チャネルを取得し、取得した受信チャンネルが、前回取得した受信チャンネルと比べて変更があった場合には、新しい受信チャンネルをtwitter（商品名）に送る。ここで、受信チャンネルのtwitter（商品名）への送信にはsendMessage()を用いており、この中でmakeMessage()により送信するメッセージを作成している。
【００５１】
次に、図２を用いて、プログラム生成装置１０の動作の詳細を説明する。
【００５２】
プログラム生成装置１０は、動作装置１３から広告メッセージを受信すると、広告メッセージが含む情報（装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス）を記憶する。この記憶した情報を、動作装置情報と称する。また、プログラム生成装置１０は、API蓄積装置１２から広告メッセージを受信すると、広告メッセージが含む情報（装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス、API取得URL）を記憶する。この記憶した情報を、API蓄積装置情報と呼ぶ。また、プログラム生成装置10は、プログラム実行装置１４から広告メッセージを受信すると、広告メッセージに含まれる情報（装置種別、プロバイダ識別子、モデル識別子、個体識別子、装置IPアドレス）を記憶する。この記憶した情報を、プログラム実行装置情報と呼ぶ。
【００５３】
次に、プログラム生成装置10の構成を説明する。
【００５４】
図５は、にプログラム生成装置１０の構成を示すブロック図である。
【００５５】
広告メッセージ処理部１０６は、通信処理部１０１を介して、広告メッセージを受信する。そして、広告メッセージが含む装置種別を基に、広告メッセージを送信した装置の種別を判断する。広告メッセージに含まれる装置種別が動作装置である場合、動作装置情報を抽出し、動作装置情報保持部１０７に送信する。広告メッセージに含まれる装置種別がＡＰＩ蓄積装置である場合、API蓄積装置情報を抽出し、API蓄積情報保持部１０８に送信する。広告メッセージに含まれる装置種別がプログラム実行装置である場合、プログラム実行装置情報を抽出し、プログラム実行装置情報を、プログラム実行情報保持部１０９に送信する。
【００５６】
動作装置情報保持部１０７は、動作装置情報を保持する。また、ヒューマンインタフェース処理部１１０又はAPIプログラム取得処理部１０２に、保持している動作装置情報を送信する。
【００５７】
API蓄積装置情報保持部１０８は、API蓄積装置情報を保持する。また、ヒューマンインタフェース処理部１１０又はAPIプログラム取得処理部１０２に、保持しているAPI蓄積装置情報を送信する。
【００５８】
プログラム実行装置情報保持部１０９は、プログラム実行装置情報を保持する。また、ヒューマンインタフェース処理部１１０又は実行プログラム送信処理部１０５に、保持しているプログラム実行装置情報を送信する。
【００５９】
ヒューマンインタフェース処理部１１０は、ディスプレイへの画面出力やマウスからの入力を処理する。ヒューマンインタフェース処理部１１０は、例えば、Webブラウザで実現される。
【００６０】
ヒューマンインタフェース処理部１１０は、プログラム蓄積サーバ１６が保有するロジックプログラムのリストについて、ロジックプログラム選択画面を生成し、表示する。図６は、ヒューマンインタフェース処理部110が、画面にロジックプログラム選択画面を表示した場合の例を示す。図６では、ロジックプログラム選択画面の例を示す図である。図６の例では、プログラム蓄積サーバ１６が、２つのロジックプログラムを保有する場合の例である。２つのロジックプログラムは、「視聴チャンネルをtwitter（商品名）へ投稿」と「Facebook（商品名）で人気の番組を録画予約」である。尚、以後の説明では、いずれかのロジックプログラムを選択したあとの説明をする場合、「視聴チャンネルをtwitter（商品名）へ投稿」の方のロジックプログラムを選択したことを前提とした説明を行う。
【００６１】
ヒューマンインタフェース処理部１１０は、動作装置情報保持部１０７に蓄積されている動作装置情報を用いて動作装置選択画面を生成し、表示する。ヒューマンインターフェース部110は、例えば、動作装置情報を、プログラム蓄積サーバ１６に送信し、プログラム蓄積サーバ１６が、モデル識別子から機器種別を表す文字列（TV,PVR,蓄電池、エアコン、太陽電池パネル、電力メータ）とアイコンに変換して画面を生成し、その画面を表示することができる。また、ヒューマンインターフェース部１１０は、文字列やアイコンを動作装置情報として、動作装置１３から取得して、表示することも可能である。
【００６２】
図７は、ヒューマンインターフェース処理部１１０が、画面に動作装置選択画面を表示した場合の例を示す図である。図７の例では、ＴＶとＰＶＲと蓄電池とエアコンと太陽電池パネルと電力メータのアイコンと文字列を表示する例を示している。
【００６３】
ヒューマンインターフェース処理部１１０は、更に、ロジックプログラム選択画面で選択されたロジックプログラム選択された場合に、選択されたロジックプログラムを動作させることができない動作装置１３について、動作装置選択画面にて、選択不可能であることを表示してもよい。例えば、選択不可能であることを示す表示として、グレイアウトあるいは非表示とする表示を行う。ロジックプログラムとして「視聴チャンネルをtwitter（商品名）へ投稿」を選択した場合、実行可能であるTVとPVRを通常表示し、それ以外の動作装置をグレイアウト表示又は非表示とする。尚、以降の説明では、動作装置選択画面で、いずれかの装置が選択されたことを前提とした説明をする場合、TVを選択したとして説明する。
【００６４】
ヒューマインタフェース処理部１１０は、ロジックプログラム選択画面で選択された動作装置のAPIプログラムに対応するロジックプログラムを取得するようロジックプログラム取得部103に通知する。
【００６５】
ヒューマンインタフェース処理部１１０は、プログラム実行装置情報保持部１０９に保持されたプログラム実行装置情報を基に、プログラム実行装置選択画面を表示する。図８に、プログラム実行装置選択画面の一例を示す。ヒューマンインタフェース処理部１１０は、プロがラム実行装置選択画面を生成する際、プログラム実行装置情報をプログラム蓄積サーバ１６に送信し、プログラム蓄積サーバ１６にてモデル識別子から機器種別を表す文字列（携帯電話、PC）とアイコンに変換して画面を生成することができる。また、これらのアイコンや文字列の情報も、プログラム実行装置情報として、プログラム実行装置１４から取得することも可能である。また、ヒューマンインタフェース処理部１１０は、更に、機器種別を表す文字列だけでなく、個々のプログラム動作装置１３にユーザが付与した名称（健一、健二、Rose）をプログラム実行装置情報に含め、表示することもできる。図８に、その例を示している。
【００６６】
ヒューマンインタフェース処理部１１０は、外部から選択されたプログラム実行装置１４に対して、実行プログラムを送信するように、実行プログラム送信処理部１０５に通知する。
【００６７】
以上が、ヒューマンインタフェース処理部１１０に関する説明である。
【００６８】
APIプログラム取得処理部１０２は、API蓄積情報保持部108に蓄積されているAPI蓄積情報を基に、API蓄積装置12から、APIプログラムを取得する。具体的には、API蓄積情報に含まれるAPI取得URLに、通信処理部１０１を介してアクセスし、APIプログラムを取得する。APIプログラム取得処理部１０２は、取得したAPIプログラムを実行プログラム生成部１０５に送る。また、取得したAPIプログラムのAPI識別子をロジックプログラム取得処理部１０３に送る。
【００６９】
ロジックプログラム取得処理部１０３は、プログラム蓄積サーバ１６から、ヒューマンインタフェース処理部１１０によりロジックプログラム選択画面で選択されたロジックプログラムを取得する。
【００７０】
典型的なケースでは、ロジックプログラム蓄積サーバ１６がWebサーバ機能を有し、ロジックプログラム選択画面を提供する。この際、ロジックプログラム取得処理部１０３は、API識別子をプログラム蓄積サーバ１６に送り、プログラム蓄積サーバ１６はこのAPI識別子に基づきプログラム生成可能なロジックプログラムのみを表示することが好ましい。
【００７１】
ロジックプログラム取得処理部１０３のアクセスするプログラム蓄積サーバ１６のURLは予め与えられているものとする。このURLは、典型的には、Google（商品名）のような検索サービスを用いて得る。
【００７２】
ロジックプログラム取得処理部１０３は、取得したロジックプログラムを実行プログラム生成部１０５に送信する。
【００７３】
実行プログラム生成部１０５は、ＡＰＩプログラム取得処理部102から受信したAPIプログラムとロジックプログラム取得処理部103から取得したロジックプログラムとを用いて、実行プログラムを生成し、実行プログラム送信処理部１０５へ送信する。
【００７４】
図９Ａ〜Ｅは、図３Ａ〜ＣのAPIプログラムと、図４Ａ〜Ｂのロジックプログラムとから生成された実行プログラムの例を示す図である。図９Ａ〜Ｅの例では、Java(登録商標)Scriptを用いているため、図３A〜Ｃで示したＡＰＩプログラムと図４Ａ〜Ｂで示したロジックプログラムとを連結するだけで、図９Ａ〜Ｅの実行プログラムを実現できる。
【００７５】
実行プログラムの生成方法には、様々なものがある。例えば、図９Ａ〜Ｅで示すように、インタプリタ型の言語を用いる場合には、テキストデータで記述されたプログラムの連結で行うことが望ましい。インタプリタ型の言語として、例えば、Java(登録商標)やRuby(商品名)がある。また、実行プログラムの生成に、C言語のようなコンパイラ型の言語を用いる場合には、プログラム実行装置１４上にコンパイラを用意する。そして、プログラム生成装置100の実行プログラム生成部１０５が、APIプログラムとロジックプログラムとをコンパイルする方法を記述したmakefileを生成する。このように、コンパイラ型の言語を用いる場合、実行プログラムは、APIプログラムとロジックプログラムとmakefileとを含む情報としてもよい。
尚、実行プログラムの生成に、コンパイラ型の言語を用いる場合であっても、プログラム実行装置１４のプログラム実行環境を示す識別子をプログラム実行装置１４からの広告メッセージに含めることで、実行プログラム生成部１０５にて、プログラム実行装置１４で実行プログラムが動作するようクロスコンパイルを行うことも可能である。
【００７６】
実行プログラム送信処理部１０５は、実行プログラム生成部１０５から受信した実行プログラムを、ヒューマンインタフェース処理部１１０の指示に従い、プログラム実行装置１４に通信処理部１０１を介して送信する。
【００７７】
通信処理部１０１は、あらかじめ定められた通信手順に従い、ネットワーク17とのデータの送受信を行う。
【００７８】
プログラム実行装置１４は、プログラム生成装置１０から実行プログラムを受信すると、受信した実行プログラムを実行する。図９A〜Ｅで示した実行プログラムの場合、プログラム実行装置14は、動作装置１３（TV）に定期的にアクセスし、前回アクセスしたときと今回アクセスしたときとで、受信チャンネルに変更がある場合に、アプリケーションサーバ１５（twitter（商品名））に通知する。通知するメッセージは、例えば、「いま、Nippon TVを見ています」である。
【００７９】
以下では、本実施形態にかかるシステムを用いた場合の効果を説明する。
【００８０】
例えば、ユーザがTVを買い替えた場合を想定する。つまり、図１のネットワーク１７に接続された動作装置１３の機能が変わった場合を想定する。例えば、買い替えたTVがEPG(Electronic Program Guide :電子番組表)機能が追加されていた場合を考える。このように、買い換えたＴＶが、新しい機能が追加されていた場合、ＡＰＩプログラムとロジックプログラムも、この機能に対応するプログラムとすることで、この機能を活用した実行プログラムを実現できる。例えば、新しいTVのAPIプログラムを、図３Ａ〜Ｃに示したプログラムにさらに電子番組表データをTVから取得するgetEPGInfo()を追加したプログラムとする。そして、ロジックプログラムを、getEPGInfo()に対応するロジックプログラムとする。プログラム実行装置１４は、このような、ロジックプログラムとＡＰＩプログラムとから生成される実行プログラムを用いて、例えば、アプリケーションサーバ１５にメッセージを通知する際に、受信チャネルで受信している番組名に変換して、「いま、Nippon TVのドラマ“春来たる”を見ています」というより詳細なメッセージを作成することができる。
【００８１】
従来は、実行プログラムは、標準通信仕様に依存したプログラムであったため、標準通信仕様が変化しない限り、このように動作装置１３の機能の変化に合わせた柔軟なプログラムを実現できず、動作装置１３の機能に合わせたサービス提供を実現できなかった。しかし、本実施例では、動作装置１３の機能に応じたＡＰＩプログラムを実現でき、そのＡＰＩプログラムに合わせたロジックプログラムを作ることで、動作装置１３の機能を十分に生かした多様な実行プログラムを実現でき、多様なサービスを実現できることとなる。
【００８２】
尚、APIプログラムは、動作装置１３（TV）の製造メーカが作成することが好ましい。また、ロジックプログラムは、製造メーカを含む不特定多数が作成し、例えばネット上のサーバにアップロードできることが好ましい。APIプログラムを、製造メーカが作成すると、ＡＰＩプログラムを動作装置１３の進化に合わせて作成することができる。また、ロジックプログラムを不特定多数の者が作成すると、動作装置１３の進化に合わせて作成することができる。
【００８３】
また、本実施例では、実行プログラムを動作装置13と別に設け、プログラム実行装置14が、アプリケーションサーバ１５と動作装置13にアクセスし、アプリケーションサーバ15と動作装置13との連携を実現している。このようにすることで、例えば、データサイズが大きすぎて扱えないなどの理由で、旧型の動作装置１３では進化したアプリケーションサーバ１５と直接連携できない場合でも、プログラム実行装置１４が、新しいアプリケーションサーバ１５と旧型の動作装置１３との連携を実現することができる。尚、プログラム実行装置１４は携帯電話やPCのようなアプリケーションサーバ１５のサービスを利用する機器であることが望ましい。
【００８４】
尚、第1の実施形態では、アプリケーションサーバ１５、プログラム蓄積サーバ１６、動作装置１３、プログラム生成装置１０、プログラム蓄積サーバ１６、動作装置１３、APＩ蓄積装置１２各々が一台である例を説明した。しかしながら、各々の装置が複数台ある場合にも本実施形態は適用可能である。
【００８５】
例えば、アプリケーションサーバ１５が複数台ある場合について説明する。この場合、プログラム実行装置１４は、Facebook（商品名）の掲示板にて人気の放送番組を取得し、この放送番組を動作装置１３（PVR）に録画予約し、録画したこの番組が再生された場合にその旨をtwitter（商品名）に通知する、という実行プログラムを実行できる。
【００８６】
次に、動作装置１３が複数存在する場合を説明する。例えば、動作装置１３が温度計とエアコンである場合、実行プログラム実行装置14は、温度計から気温を取得し、これが目標値になるようエアコンの設定温度を変更する実行プログラムを実行できる。
【００８７】
また、本実施形態では、IPプロトコルを用いた場合を説明したが、IPv6プロトコルなど、その他の通信プロトコルにも適用可能である。
【００８８】
また、本実施形態のネットワークのメディアは有線・無線のどちらでも使用することが可能である。
【００８９】
また、第1の実施形態に係るプログラム生成装置10は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、通信処理部1とＡＰＩプログラム処理部１０２とロジックプログラム取得処理部１０３と実行プログラム生成部１０４と実行プログラム送信処理部１０５と広告メッセージ処理部１０６と動作装置情報保持部１０７とＡＰＩ蓄積装置情報保持部１０８とプログラム実行装置情報保持部１０９とヒューマンインタフェース処理部１１０とは、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、プログラム生成装置10は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、動作装置情報保持部１０７とＡＰＩ蓄積装置情報保持部１０８とプログラム実行装置情報保持部とは、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。
【００９０】
＜変形例＞
次に、第1の実施形態の変形例を説明する。
【００９１】
図１０は、第1の実施形態の変形例にかかるシステムを示すブロック図である。
【００９２】
第１の実施形態の変形例にかかるシステムにおいては、第1の実施形態で説明した動作装置13とAPI蓄積装置12とが一体となっている点と、プログラム実行装置14とプログラム生成装置10とが一体となっている点が異なる。以下では、動作装置13とAPI蓄積装置12とが一体となった装置を、動作装置20と称する。動作装置20は、API蓄積装置12の機能を備えたAPI蓄積部２０Aを備えている。また、プログラム実行装置14とプログラム生成装置10とが一体となった装置を、プログラム実行装置２２と称する。プログラム実行装置22は、プログラム生成装置10の機能を備えたプログラム生成部２２Ａを備えている。
【００９３】
各々の装置の機能は、第1の実施形態と説明したものと同様であるため、各々の装置の説明は省略する。
【００９４】
尚、動作装置20が備えるAPI蓄積部20Aは、動作装置20にアクセスするためのAPIプログラムを蓄積するものとする。第１の実施例のAPI蓄積装置12は、複数の動作装置20がある場合には、複数の動作装置20のAPIプログラムをまとめて蓄積して管理することを想定していたが、本変形例では、動作装置20毎に、動作装置20に対応したAPIプログラムを記憶するものであるからである。尚、動作装置20が、動作装置20自身にアクセスするための複数のAPIプログラムを記憶することは、想定できる。つまり、動作装置20に、アクセスして、実現したい機能により複数のAPIプログラムを想定できるからである。
【００９５】
次に、第1の実施形態にかかる変形例のシステムにおける動作を説明する。図１１は、図１０のシステムにおける動作シーケンスを示す図である。
【００９６】
また、尚、本変形例のプログラム実行装置22は、図5に示すような、プログラム生成装置10が備える構成に加えて、プログラム実行装置１０が備える機能、つまり、プログラム生成装置10が生成した実行プログラムを実行するプログラム実行部のような機能を備える。尚、プログラム実行装置22は、図５で示した実行プログラム送信処理部105は、備えていなくてもよい。
【００９７】
まず、動作装置２０は、定期的に広告メッセージをブロードキャストあるいはマルチキャストする（Ｓ２０１）。ここで、広告メッセージは、例えばIPパケットにて運ばれる。広告メッセージは、装置種別とプロバイダ識別子とモデル識別子と個体識別子と装置IPアドレスとを含む。
【００９８】
装置種別は、動作装置２０の種別(例えば、TVであるかやPVRであるか)を識別する識別子である。
【００９９】
プロバイダ識別子は、その装置を製造したメーカを識別する識別子である。
【０１００】
モデル識別子は、装置のモデルを識別する識別子である。モデル識別子は、例えば、UUID(Universally Unique Identifier)を用いることが好ましい。UUIDを用いることにより、製造メーカが異なるモデルでも異なる識別子を割り当てることができる。
【０１０１】
個体識別子は、装置を一意に識別する識別子である。個体識別子は、例えば、UUIDを用いることが好ましい。尚、必ずしも、個体識別子単体で、装置１つを重複なく識別するようにしなくてもよい。例えば、モデル識別子と個体識別子の組で、重複ない値を割り当てることができればよい。
【０１０２】
装置IPアドレスは、装置に割り当てられたIPアドレスである。
【０１０３】
以上が、広告メッセージの説明である。
【０１０４】
次に、第1の実施形態の変形例のシステムの動作説明に戻る。
【０１０５】
次に、プログラム実行装置２２は、動作装置２０からAPIプログラムを受信する（Ｓ２０２）。このとき、プログラム実行装置２２は、動作装置２０からの広告メッセージにてそのAPI取得URL（例えば,http://192.168.0.1/api/）を知り、そのIPアドレスに向けてHTTPにてAPIプログラムを要求する。
【０１０６】
次に、プログラム実行装置２２は、プログラム蓄積装置１６からロジックプログラムを受信する（Ｓ２０３）。このとき、プログラム実行装置２２は、予めプログラム蓄積装置１６のIPアドレスを保持していることが望ましい。
【０１０７】
次に、プログラム実行装置２２は、APIプログラムとロジックプログラムから実行プログラムを生成し、この実行プログラムを実行する。プログラム実行装置22は、実行プログラムを実行する際、アプリケーションサーバ１５および動作装置２０にネットワーク17を介してアクセスする（Ｓ２０４、Ｓ２０５）。
【０１０８】
次に、動作装置２０の構成を説明する。図１２は、動作装置２０の構成を示すブロック図である。
【０１０９】
本体処理部２０７は、動作装置２０の本来の動作に関わる処理を行う。ここで、本来の動作とは、例えば、動作装置２０がTVである場合には、リモコン信号および放送波信号および外部ボタンの押下に従い、TV放送信号を受信し、放送信号を復調し、画面表示を行うといった動作である。
【０１１０】
通信処理部２０１は、あらかじめ定められた通信手順に従い、ネットワーク17とのデータの送受信を行う。
【０１１１】
広告メッセージ送信部２０２は、予め設定されている情報を用いて、広告メッセージを定期的に送信する。ここで、広告メッセージが含むAPI取得URLは、後述するAPIプログラム蓄積部２０６に複数のAPIプログラムが保持されている場合には、各々のＡＰＩプログラムを指定して取得できるように、APIプログラム毎にURLを用意することが好ましい。
【０１１２】
APIプログラム蓄積部２０６は、APIプログラムを保持する。複数のAPIプログラムを保持できることが好ましい。
【０１１３】
APIプログラム更新処理部２０３は、APIプログラム蓄積部２０６内のAPIプログラムの追加・削除・更新処理を、ネットワーク17を介して行う。
【０１１４】
APIプログラム送信処理部２０４は、ネットワーク17を介して、APIプログラム取得要求を受信すると、APIプログラム取得要求に含まれるAPI取得URLに従って要求されたAPIプログラムをAPIプログラム蓄積部206より抽出し、ネットワーク17を介して要求者に送信する。
【０１１５】
動作コマンド処理部２０５は、ネットワーク17を介して、動作コマンドを受信すると、これに従って本体処理部２０７へ制御コマンドを送信する。また、動作コマンドが動作状態の取得を要求する場合には、本体処理部２０７から対応する情報を抽出し、当該抽出した情報を、ネットワーク17を介して動作コマンド送信者に送信する。
【０１１６】
本実施例の動作装置２０では、APIプログラムはプログラム実行装置２２に向けて高々一度送信すればよい。これに対して、従来のHTTPサーバを有し、外部のWebブラウザによりネットワークを介して制御される制御装置では、Webブラウザをユーザが操作し、これに対応した制御コマンドを、HTTP POSTあるいはGETデータとして動作装置に送信し、これを受信した動作装置は、制御コマンドに従った動作を行うと同時に、応答を返す。この応答には、続く制御コマンドをWebブラウザから送信するためのプログラムが含まれており、結果として制御コマンドを受信するたびに制御のためのプログラムを動作装置は送信している。本実施例では、APIプログラムは高々一度送信すればよいため、ネットワークに与える負荷を小さくでき、さらに動作装置２０の通信処理に要する処理量を削減することができる。
【０１１７】
以上、第1の実施形態の変形例を説明したが、第1の実施形態の変形例は、上述したように、動作装置２０とプログラム実行装置２２とが、各々、第1の実施形態で説明した２つの装置を一体とした点が異なり、その他の点は同様の機能である。したがって、本変形例のシステムによれば、第1の実施形態で説明した効果と同様の効果を達成することができる。
【０１１８】
続けて、第２の実施形態と第３の実施形態を説明するが、第２の実施形態と第３の実施形態は、第１の実施形態で説明したシステムの具体例である。
【０１１９】
＜第２の実施形態＞
図１３は、第2の実施形態にかかるシステムを示すブロック図である。
【０１２０】
第2の実施形態にかかるシステムは、プログラム蓄積サーバ１６と、アプリケーションサーバ１５Ａ及び１５Ｂと、電気自動車３０と、がネットワーク１７介して接続されている。電気自動車30は、スマートフォン３０Aと蓄電池３０Ｂとナビゲーション装置３０Ｃとを有する。蓄電池３０Ｂとスマートフォン３０Aとは、車内ネットワーク３０Ｄ（ex 無線LAN, Bluetooth, CAN(Car area network)）を介して接続されている。ナビゲーション装置３０Ｃとスマートフォン３０Aとは、車内ネットワーク３０Ｄにて接続されている。尚、図１３の例では、蓄電池３０Ｂとスマートフォン３０Ａとの間、ナビゲーション装置３０Ｃとスマートフォン３０Ａとの間、各々の間のネットワークが同一の車内ネットワーク３０Ｄであるとしたが、各々のネットワークが異なるネットワークであってもよい。
【０１２１】
ここで、蓄電池３０Ｂ及びナビゲーション装置３０Ｃは、図１２で示した第1の実施形態の変形例の動作装置２０と同様の機能を有する。蓄電池３０Ｂ及びナビゲーション装置３０Ｃは、動作装置20と同様、APIプログラム蓄積部206を有している。スマートフォン３０Ａは、第1の実施形態の変形例のプログラム実行装置22と同様の機能を有する。このように第２の実施形態にかかるシステムは、動作装置20が２台ある例を示している。
【０１２２】
スマートフォン30Aは、蓄電池30ＢのAPIプログラム蓄積部206に蓄積されているAPIプログラムを用いることにより、ネットワークを介して蓄電池30Bにアクセスすることで、蓄電池３０Ｂの予め定められた短期間毎（例えば、１分毎）の充放電量と、電気残量、温度を取得することができる。
【０１２３】
また、スマートフォン30Aは、ナビゲーション装置30CのAPIプログラム蓄積部206に蓄積されているAPIプログラムを用いることにより、ネットワークを介してナビゲーション装置30Cにアクセスすることで、電気自動車３０の現在の位置情報および速度情報（進行方向を含む）を得ることができる。
【０１２４】
次に、第2の実施形態のシステムの動作を説明する。
【０１２５】
図１４は、第2の実施形態にかかるシステムの動作を示すシーケンス図である。
【０１２６】
まず、蓄電池３０Ｂは、広告メッセージを定期的に送信する（Ｓ３０１）。
【０１２７】
また、ナビゲーション装置３０Ｃは広告メッセージを定期的に送信する（Ｓ３０２）。
【０１２８】
次に、スマートフォン３０Aは、Ｓ３０１及びＳ３０２で取得した広告メッセージに含まれるAPI取得URLを用いて、蓄電池３０Ｂ及びナビゲーション装置３０ＣからAPIプログラムを取得する（Ｓ３０３、Ｓ３０４）。
【０１２９】
次に、スマートフォン３０Aは、予め設定されたプログラム蓄積装置１６から、ロジックプログラムを取得する（Ｓ３０５）。そして、スマートフォン３０Ａは、ロジックプログラムと蓄電池30B及びナビゲーション装置30Cから取得したAPIプログラムとから、実行プログラムを生成する。そして、スマートフォン３０Ａは、実行プログラムを実行する。実行プログラムの実行の際、スマートフォン３０Ａは、蓄電池３０Ｂとナビゲーション装置３０Ｃとアプリケーションサーバ１５及び１５Ｂにアクセスする（Ｓ３０６〜Ｓ３０９）。
【０１３０】
より具体的には、スマートフォン３０Ａは、実行プログラムを実行することで、ナビゲーション装置３０Ｃにアクセスして（Ｓ３０７）、位置情報及び速度情報を取得し、取得した位置情報及び速度情報を、アプリケーションサーバ15Aに送信し、周辺地図情報を取得する（Ｓ３０８）。ここで、アプリケーションサーバ15Ａは、周辺地図情報を提供するサービスを行っているとする。
【０１３１】
また、スマートフォン３０Ａは、実行プログラムを実行することで、蓄電池３０Ｂから放電量と電気残量と温度とを取得し（Ｓ３０６）、Ｓ３０７で取得する速度情報と併せて、アプリケーションサーバ15Bに送信し、走行可能距離を得る（Ｓ３０９）。ここで、アプリケーションサーバ15Bは、電気自動車３０の走行可能距離算出サービスを行っているとする。
【０１３２】
また、スマートフォン３０Ａは、実行プログラムを実行することで、周辺地図情報と走行可能距離とから、走行可能範囲３１Ｃをスマートフォン３０Aの画面３１Ａ上に表示する。
【０１３３】
図１５に、スマートフォン３０Ａが、画面上に表示する走行可能範囲３１Ｃの例を示す。
【０１３４】
図１５の例では、電気自動車３０が右方向に進行していることを前提としているため、現在地３１Ｂを中心とした地図ではなく、現在地３１Ｂより右側の領域を多く表示している。また、図１５の例では、右側に表示している道路の混雑が多いことを前提としているため、赤線で囲まれた走行可能領域は、右側は左側と比べて狭くなっている。
【０１３５】
以上の例のように、複数の電気自動車３０が自身の位置をアプリケーションサーバ15Bに送信することで、アプリケーションサーバ15Bは、道路の混雑状況を加味した走行可能距離を計算することができる。また、蓄電池３０Ｂの電気残量を正確に求めることは一般に難しいが、走行可能距離の計算をアプリケーションサーバ側で実行することで、実データの収集およびこれに基づく算出アルゴリズムの改良、そして新しいアルゴリズムの導入が可能である。また、この改良後の算出アルゴリズム若しくは新たに導入したアルゴリズムをロジックプログラムとしてスマートフォン３０Aに送信することで、スマートフォン30Ａは、電気自動車３０設計当時の計算能力では実行できない複雑な算出アルゴリズムを実行することができる。この場合は、スマートフォン３０Aがアプリケーションサーバと常に通信する必要が無く、スマートフォン３０Aの消費電力を削減するという効果もある。
【０１３６】
＜第3の実施形態＞
図16は、第3の実施形態に係るシステムを示すブロック図である。
【０１３７】
第3の実施形態に係るシステムは、プログラム蓄積サーバ１６と、二つのアプリケーションサーバ１５Ａ及び１５Ｂと、エネルギー管理サーバ４１と建物４０Ａと建物４０Ｂとが、ネットワーク１７を介して接続されている。
【０１３８】
また、建物４０Ａは、電力計４０１Ａと蓄熱装置４０２Ａとを備えている。電力系４０１Ａと蓄熱装置４０２Ａとはネットワーク４０３Ａを介して接続されている。建物４０Ｂは、電力系４０１Ｂと蓄熱装置４０２Ｂとを備えている。電力系４０１Ｂと蓄熱装置４０２Ｂとは、ネットワーク４０３Ｂを介して接続されている。
【０１３９】
本実施例のエネルギー管理サーバ４１は、第１の実施形態の変形例のプログラム実行装置２２の機能を有する。また、蓄熱装置４０２Ａ及び４０２Ｂは、動作装置２０の機能を有する（図１０を参照）。
【０１４０】
電力計４０１Ａは、建物４０Ａの消費電力を測定し、測定結果をアプリケーションサーバ１５Aへ送信する。電力計４０１Ａの消費電力測定の細かさは様々な形態を考えることができ、建物内のフロア毎や部屋毎やコンセント毎に消費電力を測定できる。電力計４０１Ｂも同様の機能を有する。
【０１４１】
蓄熱装置４０２Ａは、ヒートポンプなどの熱発生部（又は吸熱部）と、水のタンクによる温熱又は冷熱を蓄積する熱蓄積部とを備える。熱蓄積部は、冷熱については、冷水ではなく氷の形で熱を蓄積することも可能である。蓄熱装置４０２Ａは、例えば深夜のような電気料金（あるいはガス料金）の安い時間帯の電力でヒートポンプを駆動し得られた熱を蓄積する。蓄積した熱は、電気料金の高い時間帯に給湯、空調、床暖房等の用途に使用することで、ユーザには電気料金削減、電気会社にはピーク電力の削減の効果を実現できる。時間とともに、蓄積した熱は環境へ散逸する。したがって、次の蓄熱タイミング（一般には翌日の深夜）までに、必要最小限の熱量を見積もり、これを蓄熱することが重要である。蓄熱装置４０２Ｂも同様の機能を有する。
【０１４２】
エネルギー管理サーバ４１は、蓄熱量を見積もり、見積もった蓄熱量を蓄熱装置402Ａに指示する。
【０１４３】
アプリケーションサーバ１５Bは、例えば気象庁の天気予報サイトであり、本日から翌日までの天気情報を提供している。
【０１４４】
次に、第3の実施形態にかかるシステムの動作シーケンスを説明する。図１７は、第3の実施形態に係るシステムの動作を示すシーケンス図である。
【０１４５】
まず、電力計４０１Aと電力計４０１Bは、定期的に、アプリケーションサーバ１５Aに対して消費電力量を通知する（Ｓ４０１、Ｓ４０２）。この消費電力量は、予め定められた期間（例えば、一分）毎に消費した電力量である。この消費電力の測定期間と消費電力量の通知間隔は一致している必要は無い。通知する消費電力量には、電力を消費した時刻情報が記されていることが望ましい。時刻情報は、消費電力測定期間と消費電力量通知間隔とが一致している場合には、省略することが可能である。
【０１４６】
次に、エネルギー管理サーバ４１は、電力計４０１A及びBのAPIプログラムを、電力計４０１A及びBから取得する（Ｓ４０３、Ｓ４０４）。尚、本実施例では、説明を省略しているが、電力計４０１Ａ及びＢは、広告メッセージをエネルギー管理サーバ４１のアドレス宛てに送信することで、エネルギー管理サーバ４１は、電力計４０１Ａ及びＢからAPIプログラムを取得可能となる。尚、APIプログラムの取得先は、必ずしも電力計４０１Ａ及びＢである必要はなく、実施例1で示したように、電力計４０１Ａ及びＢ以外の機器から取得する構成も可能である。
【０１４７】
次に、エネルギー管理サーバ４１は、ロジックプログラムをプログラム蓄積サーバ１６から取得する（Ｓ４０５、Ｓ４０９）。ここで、エネルギー管理サーバ41が取得するロジックプログラムは、蓄熱装置のユーザが予め選択可能であることが好ましい。例えば、ユーザは、蓄熱装置の使用人数や家族構成（女性が3人いるなど）により、ロジックプログラムを選択する。ユーザは、ロジックプログラムを、例えばWebブラウザを使用して選択する。
【０１４８】
エネルギー管理サーバ４１は、ロジックプログラムとAPIプログラムとから実行プログラムを生成し、実行プログラムを実行する。本実施形態では、蓄熱装置４０２Aと蓄熱装置４０２Bのユーザが異なる場合、蓄熱装置ごとに異なる実行プログラムを実行することが望ましい。
【０１４９】
エネルギー管理サーバ４１は、実行プログラムを実行することで、アプリケーションサーバ１５B、アプリケーションサーバ１５Ａより天候情報を取得し（Ｓ４０６、Ｓ４１０）、天気情報を用いて蓄熱装置４０２Ｂ、蓄熱装置４０２Ａの蓄熱量を制御する（Ｓ４０７、Ｓ４１１）。
【０１５０】
さらに、アプリケーションサーバ１５Aは、ユーザ毎の消費電力量の一定期間（例えば、一時間）毎の消費電力量を、例えば一カ月分のデータ提供している。そして、ユーザは、Webブラウザを使って、その一カ月分のデータにアクセスすることが可能である。アプリケーションサーバ１５Ａがこのような機能を備えることで、例えば、Facebook（商品名）の友達関係のあるユーザ間で、これらの消費電力量を共有することも可能である。これにより、ユーザ間で電力節約のコツや、使用しているロジックプログラムの情報を共有することができる。そして、好みの（典型的には、家屋の大きさや断熱性能、あるいは家屋内の機器構成やライフスタイルの似た友人の中で、最も消費電力の少ない人間の使用しているロジックプログラム）ロジックプログラムを選び直すことも可能である。
【０１５１】
エネルギー管理サーバ４１で実行されている実行プログラムのアルゴリズム例について説明する。図１８は、エネルギー管理サーバ４１で実行する実行プログラムの蓄熱量制御のアルゴリズムの例を示すフローチャートである。
【０１５２】
まず、深夜電力期間(例えば、AM０時からAM5時)開始前に、ユーザ家屋地域の翌日の天候情報をアプリケーションサーバ１５Aから取得する（Ｓ５０１）。本例では、天候情報として気温を取得する。なお、天候情報は、気温に限られない。例えば、太陽光発電装置や風力発電装置をユーザが使用している場合には、その発電量を考慮するため日照量や風量を天候情報とする。
【０１５３】
次に、実行プログラムは、翌日の使用熱量を予測する（Ｓ５０２）。実行プログラムは、ユーザの熱使用履歴データ（日付、気温、使用熱量）を保持しており、その履歴データの中から翌日の気温に一致する気温に対応する使用熱量を抽出し、抽出した使用熱量の平均を取ることで、翌日の使用熱量を予測する。ここで、翌日の気温と一致する気温とは、気温が完全一致していなくてもよく、気温差がある一定値以内の気温であってもよい。また、抽出した使用熱量の平均を取る際に、単純な加重平均ではなくてもよい。例えば、新しいデータほど重みが大きい重み付き平均など様々な算出の方法が考えられる。また、熱使用履歴データは、一日毎ではなくより細かい時間粒度（例えば一時間毎）に保持してもよい。
【０１５４】
次に、実行プログラムは、Ｓ５０２で予測した使用熱量と同じ熱量を蓄熱するよう蓄熱装置に通知する（Ｓ５０３）。
【０１５５】
次に、実行プログラムは、定期的に蓄熱装置から使用熱量を取得し、これを熱使用履歴データに追加する（Ｓ５０４）。
【０１５６】
以上が、実行プログラムのアルゴリズムである。
【０１５７】
以上説明したように、エネルギー管理サーバ４１において、ユーザが選んだロジックプログラムを動作させることにより、ユーザの使用機器や使用条件に適したエネルギー制御を実現することができる。また、Facebook（商品名）のようなソーシャルネットワークあるいは掲示板サービスと組み合わせることで、ユーザによる最適なロジックプログラムの選択を実現できる。
【０１５８】
以上説明した少なくとも１つの実施形態の効果は、機器の標準通信仕様の変更があるか否かにかかわらず、ネットワーク上のサービスを、機器の機能に合わせて、機器の機能を利用したサービスを提供できるようなプログラムを生成するプログラム生成装置を提供することができる。
【０１５９】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１６０】
１０・・・プログラム生成装置、１２・・・API蓄積装置、１３、２０・・・動作装置、１４、２２・・・プログラム実行装置、１５、１５A、１５B・・・アプリケーションサーバ、１６・・・プログラム蓄積サーバ、１７、３０Ｄ、４０３Ａ、４０３Ｂ・・・ネットワーク、１０１、２０１・・・通信処理部、１０２・・・APIプログラム取得処理部、１０３・・・ロジックプログラム取得処理部、１０４・・・実行プログラム生成部、１０５・・・実行プログラム送信処理部、１０６・・・広告メッセージ処理部、１０７・・・動作装置情報保持部、１０８・・・API蓄積装置情報保持部、１０９・・・プログラム実行装置情報保持部、１１０・・・ヒューマンインタフェース処理部、２０A・・・API蓄積部、２２A・・・プログラム生成部、２０２・・・広告メッセージ送信部、２０３・・・API更新処理部、２０４・・・APIプログラム送信処理部、２０５・・・動作コマンド処理部、２０６・・・APIプログラム蓄積部、２０７・・・本体処理部、３０・・・電気自動車、３０A・・・スマートフォン、３０Ｂ・・・蓄電池、３０Ｃ・・・ナビゲーション装置、３０Ｄ・・・ネットワーク、３１Ａ・・・画面、３１Ｂ・・・現在地、３１Ｃ・・・走行可能範囲、４１・・・エネルギー管理サーバ、４０A、４０Ｂ・・・建物、４０１A、４０１Ｂ・・・電力計、４０２A、４０２Ｂ・・・蓄電装置。
【特許請求の範囲】
【請求項１】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第１プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第１サービスとを連携した連携サービスを実現する第２プログラムとを用いて、前記連携サービスを実現する第３プログラムを生成する生成部を有するプログラム生成装置。
【請求項２】
前記第３プログラムを、ネットワークを介して、前記第３プログラムを実行して前記連携サービスを実現する装置に送信する送信部を更に有する請求項１記載のプログラム生成装置。
【請求項３】
前記第３プログラムを実行して、前記連携サービスを実現する実行部を更に有する請求項１記載のプログラム生成装置。
【請求項４】
前記第１プログラムを、ネットワークを介して取得する取得部を有する請求項１記載のプログラム生成装置。
【請求項５】
前記第２プログラムを、ネットワークを介して取得する第２取得部を有する請求項４記載のプログラム生成装置。
【請求項６】
前記第１プログラムは、前記機器が保持し、
前記取得部は、前記機器から取得する請求項４記載のプログラム生成装置。
【請求項７】
前記第１プログラムの通信手順によって利用、若しくは制御を実現される前記機能と連携した連携サービスを実現可能なプログラムを、前記第２プログラムとして選択して取得する第２取得部を有する請求項１記載のプログラム生成装置。
【請求項８】
複数の異なる第３プログラムを生成した場合、複数の異なる第３プログラムを示す表示を画面に表示し、前記画面に表示された表示から、前記複数の異なる第３プログラムの中から、実行したい連携サービスを実現する第３プログラムを選択可能とするヒューマンインタフェース処理部を有する請求項１記載のプログラム生成装置。
【請求項９】
アプリケーションサーバとネットワークを介して接続され、
前記第１サービスは、前記アプリケーションサーバが提供し、
前記実行部は、前記連携サービスを実現する際に、前記アプリケーションサーバと通信を行う請求項３記載のプログラム生成装置。
【請求項１０】
前記実行部は、Webブラウザであり、前記アプリケーションサーバからHTMLデータを受信することで画面表示を行う請求項９記載のプログラム生成装置。
【請求項１１】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第１プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第１サービスとを連携した連携サービスを実現する第２プログラムとを用いて、前記連携サービスを実現する第３プログラムを生成する生成ステップを有するプログラム生成方法。
【請求項１２】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第１プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第１サービスとを連携した連携サービスを実現する第２プログラムとを用いて、前記連携サービスを実現する第３プログラムを生成する生成機能を有するプログラム生成プログラム。
【請求項１】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第１プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第１サービスとを連携した連携サービスを実現する第２プログラムとを用いて、前記連携サービスを実現する第３プログラムを生成する生成部を有するプログラム生成装置。
【請求項２】
前記第３プログラムを、ネットワークを介して、前記第３プログラムを実行して前記連携サービスを実現する装置に送信する送信部を更に有する請求項１記載のプログラム生成装置。
【請求項３】
前記第３プログラムを実行して、前記連携サービスを実現する実行部を更に有する請求項１記載のプログラム生成装置。
【請求項４】
前記第１プログラムを、ネットワークを介して取得する取得部を有する請求項１記載のプログラム生成装置。
【請求項５】
前記第２プログラムを、ネットワークを介して取得する第２取得部を有する請求項４記載のプログラム生成装置。
【請求項６】
前記第１プログラムは、前記機器が保持し、
前記取得部は、前記機器から取得する請求項４記載のプログラム生成装置。
【請求項７】
前記第１プログラムの通信手順によって利用、若しくは制御を実現される前記機能と連携した連携サービスを実現可能なプログラムを、前記第２プログラムとして選択して取得する第２取得部を有する請求項１記載のプログラム生成装置。
【請求項８】
複数の異なる第３プログラムを生成した場合、複数の異なる第３プログラムを示す表示を画面に表示し、前記画面に表示された表示から、前記複数の異なる第３プログラムの中から、実行したい連携サービスを実現する第３プログラムを選択可能とするヒューマンインタフェース処理部を有する請求項１記載のプログラム生成装置。
【請求項９】
アプリケーションサーバとネットワークを介して接続され、
前記第１サービスは、前記アプリケーションサーバが提供し、
前記実行部は、前記連携サービスを実現する際に、前記アプリケーションサーバと通信を行う請求項３記載のプログラム生成装置。
【請求項１０】
前記実行部は、Webブラウザであり、前記アプリケーションサーバからHTMLデータを受信することで画面表示を行う請求項９記載のプログラム生成装置。
【請求項１１】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第１プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第１サービスとを連携した連携サービスを実現する第２プログラムとを用いて、前記連携サービスを実現する第３プログラムを生成する生成ステップを有するプログラム生成方法。
【請求項１２】
制御対象の機器に対して定められたプログラムであって、かつ前記機器の機能を利用、若しくは制御を実現するための前記機器との間の通信手順を定める第１プログラムと、前記機器との間の通信手順を含まないプログラムであって、かつ前記機器との間の通信手順を定めるプログラムを利用することで、前記機器の機能とネットワーク上で提供される第１サービスとを連携した連携サービスを実現する第２プログラムとを用いて、前記連携サービスを実現する第３プログラムを生成する生成機能を有するプログラム生成プログラム。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【図９Ａ】
【図９Ｂ】
【図９Ｃ】
【図９Ｄ】
【図９Ｅ】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【図９Ａ】
【図９Ｂ】
【図９Ｃ】
【図９Ｄ】
【図９Ｅ】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１３−７３４５８（Ｐ２０１３−７３４５８Ａ）
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願番号】特願２０１１−２１２６８４（Ｐ２０１１−２１２６８４）
【出願日】平成２３年９月２８日（２０１１．９．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
２．Ｂｌｕｅｔｏｏｔｈ
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願日】平成２３年９月２８日（２０１１．９．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
２．Ｂｌｕｅｔｏｏｔｈ
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]