特開 2024-46101 通信デバイス並びにその通信方法及び通信プログラム

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024046101

(43)【公開日】2024-04-03

(54)【発明の名称】通信デバイス並びにその通信方法及び通信プログラム

(51)【国際特許分類】

   H04L 69/08 20220101AFI20240327BHJP

   H04L 67/02 20220101ALI20240327BHJP

   H04L 67/564 20220101ALI20240327BHJP

【ＦＩ】

H04L69/08

H04L67/02

H04L67/564

【審査請求】未請求

【請求項の数】14

【出願形態】ＯＬ

(21)【出願番号】P 2022151284

(22)【出願日】2022-09-22

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

【国等の委託研究の成果に係る記載事項】（出願人による申告）令和４年度、国立研究開発法人情報通信研究機構、「低遅延・自律性を実現するフローティングサイバーフィジカルシステムと広域連携の研究開発」、産業技術力強化法第１７条の適用を受ける特許出願

(71)【出願人】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100092772

【弁理士】

【氏名又は名称】阪本 清孝

(74)【代理人】

【識別番号】100119688

【弁理士】

【氏名又は名称】田邉 壽二

(72)【発明者】

【氏名】関川 柊

(72)【発明者】

【氏名】佐々木 力

(57)【要約】

【課題】通信デバイス内にプロキシ機能を導入し、通信機能の制約によりWebブラウザが対応しない通信を前記プロキシ機能に代理で実施させることでWebブラウザ内のプログラム実行エンジンの対応プロトコル・ネットワーク機能や双方向通信を実現する通信デバイス並びにその通信方法及び通信プログラムを提供する。
【解決手段】通信機能に制約のあるプログラム実行エンジン101を備えたWebブラウザ10のプログラム実行エンジンにおいて通信を伴うプログラムを実行するデバイス1において、プロキシ機能11を配置し、通信機能の制約によりWebブラウザ10が対応しない通信機能をプロキシ機能11に代理させる。
【選択図】図１

【特許請求の範囲】

【請求項1】

通信機能に制約のあるプログラム実行エンジンを備えたWebブラウザで、通信を伴うプログラムを実行する通信デバイスにおいて、
プロキシ機能を配置し、
前記通信機能の制約によりWebブラウザが対応できない通信機能を前記プロキシ機能が代理して補うことを特徴とする通信デバイス。

【請求項2】

前記プロキシ機能は、前記プログラムが送信しようとするメッセージに対して宛先変更及びプロトコル変換の少なくとも一方の機能を提供することを特徴とする請求項１に記載の通信デバイス。

【請求項3】

前記プロキシ機能は、前記プログラムに対してPushによるメッセージ受信機能を提供することを特徴とする請求項１に記載の通信デバイス。

【請求項4】

前記プロキシ機能は、Webブラウザが対応しないプロトコルの受信メッセージを対応するプロトコルの受信メッセージに変換することを特徴とする請求項３に記載の通信デバイス。

【請求項5】

前記プロキシ機能は、前記プログラムに対してpolingによるメッセージ受信機能を提供することを特徴とする請求項１に記載の通信デバイス。

【請求項6】

前記プロキシ機能は、受信メッセージをキャッシュするサーバ機能を提供し、前記プログラムからのpoling要求に対して、前記キャッシュした受信メッセージを読み出して応答することを特徴とする請求項５に記載の通信デバイス。

【請求項7】

前記プロキシ機能は、前記キャッシュした受信メッセージのプロトコルをWebブラウザが対応するプロトコルに変換することを特徴とする請求項６に記載の通信デバイス。

【請求項8】

前記プログラムは、受信メッセージの少なくともプロトコルを指定する付加情報をプロキシ機能へ提供し、当該プロキシ機能は前記付加情報を用いて少なくとも受信メッセージのプロトコルを変換することを特徴とする請求項１ないし７のいずれかに記載の通信デバイス。

【請求項9】

前記プロキシ機能が送信メッセージに対して暗号化機能を提供することを特徴とする請求項１に記載の通信デバイス。

【請求項10】

前記プロキシ機能が送信メッセージに対して認証機能を提供することを特徴とする請求項１に記載の通信デバイス。

【請求項11】

前記プロキシ機能は、プログラムが送信しようとするメッセージの宛先及び内容に基づいて当該メッセージの送信を許可又は禁止することを特徴とする請求項１に記載の通信デバイス。

【請求項12】

前記プロキシ機能は、プログラムが送信しようとするメッセージを予め登録されている複数の宛先へ送信することを特徴とする請求項１に記載の通信デバイス。

【請求項13】

通信機能に制約のあるプログラム実行エンジンを備えたWebブラウザで、通信を伴うプログラムを実行する通信デバイスの通信方法において、
通信デバイスにプロキシ機能を実装し、
前記通信機能の制約によりWebブラウザが対応できない通信機能を前記プロキシ機能が代理して補うことを特徴とする通信デバイスの通信方法。

【請求項14】

通信機能に制約のあるプログラム実行エンジンを備えたWebブラウザで、通信を伴うプログラムを実行する通信デバイスの通信プログラムにおいて、
通信デバイスのコンピュータにプロキシ機能を実装し、
前記通信機能の制約によりWebブラウザが対応できない通信機能を前記プロキシ機能が代理して補うことを特徴とする通信デバイスの通信プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信デバイス並びにその通信方法及び通信プログラムに係り、特に、通信機能に制約のあるプログラム実行エンジンを備えたWebブラウザで、通信を伴うプログラムを実行する通信デバイス並びにその通信方法及び通信プログラムに関する。

【背景技術】

【0002】

Webブラウザのプログラム実行エンジンには、プログラムが使用できる通信機能に制約があり、一部のプロトコルや双方向通信、外部デバイスからの通信待受といった通信機能の一部が制限される。

【0003】

非特許文献１には、単一のTCPコネクション上に双方向通信のチャネルを作成するプロトコルの標準化技術としてWebSocketが開示されている。WebSocketは、Webで使用されるHTTPを用いて予め確立したHTTPコネクションを利用してTCPコネクションを確立し、WebブラウザとWebサーバとの間でHTTPに比べてヘッダ長が短いフレームの非HTTPメッセージを双方向で交換するプロトコルである。

【0004】

特許文献１には、デバイスで動作するブラウザ内でローカルプロキシを動作させることで通信経路をブラウザに集約させ、端末内で動作しているアプリケーションに対して認証の代行機能やブラウザに対して表示するページデータの加工等の機能を実現する技術が開示されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特許第4353487号公報

【非特許文献】

【0006】

【非特許文献1】IETF RFC 6455

【発明の概要】

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

【0007】

非特許文献１が開示するWebSocket技術は、コネクションの確立にHTTPを利用するのでWebサーバとWebブラウザとの間の通信に制約がある。したがって、Webブラウザ同士の通信やHTTPに対応しないDBサーバ等との接続には利用できない。

【0008】

特許文献１では、ローカルプロキシによる通信にHTTPが想定されており、ローカルプロキシにおいてプロトコルの変換あるいは宛先情報の変更を行うものではない。そのため、Webブラウザ内のプログラム実行エンジン上で動作するプログラムからプログラム実行エンジンでサポートなされないHTTP以外のプロトコルを用いた通信、あるいは外部デバイスからプログラムに対して直接接続を行って双方向通信を実現することはできない。

【0009】

このように、Webブラウザ内のプログラム実行エンジンで実行されるプログラムが外部デバイスと双方向通信を実現するためには次の課題が存在する。

【0010】

第1に、Webブラウザ内のプログラム実行エンジンで実行されるプログラムにおいて利用できるプロトコルやネットワーク機能を拡張する手段が必要となる。

【0011】

第2に、Webブラウザ内のプログラム実行エンジンで実行されるプログラムに対して外部デバイスからメッセージの送信が行われた際に、当該プログラムに対してメッセージ内容の通知を実施する手段が必要となる。

【0012】

本発明の目的は、上記の技術課題を解決し、通信デバイス内にプロキシ機能を配置し、通信機能の制約によりWebブラウザが対応できない通信を前記プロキシ機能に代理で実施させることで、Webブラウザ内のプログラム実行エンジンの対応プロトコル・ネットワーク機能や双方向通信を実現する通信デバイス並びにその通信方法及び通信プログラムを提供することにある。

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

【0013】

上記の目的を達成するために、本発明は、デバイス内にプロキシ機能を配置し、外部デバイスとの間で送受信されるメッセージにプロトコル変換や宛先情報の変更などの加工処理を実施するなどして、通信機能の制約によりWebブラウザが対応できない通信機能を補うことで、プログラム実行エンジンが提供しないプロコトルや通信方法を用いたメッセージ交換を実施できるようにした。

【0014】

Webブラウザ上で動作するプログラムのメッセージ送信はデバイス内で動作するプロキシ機能との間でHTTPを利用して実施され、プロキシ機能においてプロトコル変換や宛先変更等の処理を行って所望のプロトコルで外部デバイスとの通信を行う。

【0015】

なお、本発明はこのような特徴的な処理部を備える通信デバイスとして実現することができるだけでなく、かかる特徴的な処理をステップとする通信デバイスの通信方法として実現したり、かかるステップをコンピュータに実行させる通信デバイスの通信プログラムとして実現したりすることができる。

【発明の効果】

【0016】

本発明によれば、以下のような効果が達成される。

【0017】

(1) デバイス内に配置したプロキシ機能がメッセージの加工処理を実施することで、Webブラウザ内で動作するプログラムは、プログラム実行エンジンが提供しないプロコトルを用いて外部デバイスとのメッセージ交換を実施できるようになる。

【0018】

(2) デバイス内に配置したプロキシ機能がメッセージの加工処理および一時保持を実施することで、外部デバイスから送信したメッセージをWebブラウザ内で動作するプログラムが受信できるようになる。

【0019】

(3) デバイス内に配置されたプロキシ機能がメッセージを加工し、かつ予め確立された双方向通信チャネルへ転送することで、外部デバイスから送信したメッセージをWebブラウザ内で動作するプログラムが受信できるようになる。

【0020】

(4) プログラムがプロキシ機能に対してメッセージを送信する際に付加情報を付与することで、プロキシ機能において宛先や使用するプロトコルなど、メッセージの加工処理の内容、方法を選択することが可能となる。

【0021】

(5) プログラムに対して識別子を付与し、プロキシ機能がWebブラウザ内で実行されている複数のプログラムを識別できるようにし、外部デバイスが識別したプログラムに対してメッセージ送信を行うので、プログラム実行エンジンとプロキシ機能との間に確立されたコネクションが破棄された場合でも、識別子に基づいて正しいプログラムへメッセージを送信することができる。

【0022】

(6) プロキシ機能は自身のメッセージ処理部の制御方法を外部サーバから取得できるので、多数のデバイスが存在する場合でも外部のサーバから制御方法を一括変更できるようになる。

【0023】

(7) プロキシ機能が制御インタフェースを具備することで外部デバイスあるいはWebブラウザで実行されるプログラムから制御方法を変更することができるので、プロキシ機能が実施するメッセージ加工の内容や方法をプログラム単位で変更できるようになる。

【図面の簡単な説明】

【0024】

【図1】本発明の一実施形態に係る通信デバイスの主要部の構成を示した機能ブロック図である。

【図2A】プログラムが外部デバイスへメッセージを送信する手順を示したシーケンスフロー（その１）である。

【図2B】プログラムが外部デバイスへメッセージを送信する手順を示したシーケンスフロー（その２）である。

【図3】プログラムによるメッセージ受信（Push）の機能ブロック図である。

【図4A】プログラムによるメッセージ受信（Push）の手順を示したシーケンスフロー（その１）である。

【図4B】プログラムによるメッセージ受信（Push）の手順を示したシーケンスフロー（その２）である。

【図5】プログラムによるメッセージ受信（Poling）の機能ブロック図である。

【図6A】プログラムによるメッセージ受信（Poling）の手順を示したシーケンスフロー（その１）である。

【図6B】プログラムによるメッセージ受信（Poling）の手順を示したシーケンスフロー（その２）である。

【図6C】プログラムによるメッセージ受信（Poling）の手順を示したシーケンスフロー（その３）である。

【図6D】プログラムによるメッセージ受信（Poling）の手順を示したシーケンスフロー（その４）である。

【図7】本発明の利用シーンの一例を示した図である。

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

【0025】

以下、図面を参照して本発明の実施の形態について詳細に説明する。図1は、本発明の一実施形態に係る通信デバイス1の主要部の構成を示した機能ブロック図であり、Webブラウザ10及びプロキシ機能11を備える。前記デバイス1にはネットワーク経由でWebサーバ2及び外部デバイス3が接続されている。

【0026】

このようなデバイス1は、CPU、ROM、RAM、バス、インタフェース等を備えた汎用のコンピュータやサーバに、以下に詳述する各機能を実現するアプリケーション（プログラム）を実装することで構成できる。あるいはアプリケーションの一部をハードウェア化またはソフトウェア化した専用機や単能機としても構成できる。

【0027】

Webブラウザ10は、Webサーバ2から読み込んだプログラムを実行するためのプログラム実行エンジン101を備える。プログラム実行エンジン101は、Web標準技術として広く使用されるECMAScript・JavaScriptやWeb Assembly(WASM)等で記述されたプログラムを実行する従来のエンジンである。

【0028】

プログラムP1，P2はWebサーバ2から取得され、プログラム実行エンジン101に読み込まれて当該プログラム内に記述された所定の処理を実行する。プログラムP1，P2は処理を実行する際、プログラム実行エンジン101が具備する通信機能を、プログラム実行エンジン101が提供するインタフェースを介して呼び出すことで外部デバイス3とメッセージ交換を行うことができる。ただし、プログラムP1，P2が利用できる通信機能には制約があり、プログラム実行エンジン101がインタフェースを提供する通信機能（以降、ブラウザ対応通信機能）に限定される。

【0029】

ブラウザ対応通信機能には、Webの通信に使用されるHTTP ( Hypertext Transfer Protocol ) やHTTP上でWebサーバとWebブラウザ間が双方向通信を実施する規格であるWebSocket等のプロトコルが含まれる。ブラウザ対応通信機能は原則として、外部のサーバに対して接続を行うクライアント型の通信機能に限られるため、外部デバイス3からプログラムP1，P2に対して直接接続を行うことはできない。

【0030】

プロキシ機能11は、ローカル送受信部111、メッセージ処理部112及びリモート送受信部113を主要な構成とし、前記通信機能の制約によりWebブラウザが対応しない通信機能を代理で実行することにより、制約されている通信機能を補うことができる。

【0031】

ローカル送受信部111は、デバイス内のローカルループバックアドレスの単一あるいは複数のポートで待受を行い、ブラウザ対応通信機能に含まれるプロトコルのサーバ機能を実行する。プログラムP1，P2は外部デバイス3に代わり、ローカルループバックアドレスのローカル送受信部が待受を行なっているポートに対してメッセージ送信を行う。この際、メッセージ内容に本来の接続先である外部デバイス3の宛先情報や変換後のプロトコル等の付加情報をプログラムP1，P2で付加し、プロキシ機能11に対して必要となる情報を通知することができる。

【0032】

ローカル送受信部111は、プログラムP1，P2から受け取ったメッセージをメッセージ処理部112に転送する。メッセージ処理部112は、あらかじめ決められた処理内容又はプログラムP1，P2が付加した付加情報に従って、プロトコル変換や宛先変更等のメッセージ加工処理を実施してリモート送受信部113に転送する。

【0033】

リモート送受信部113は、メッセージ処理部112が加工したメッセージをデバイス10のネットワークインタフェースから送出する。これにより、外部デバイス3に対してWebブラウザ10が対応しない任意のプロトコルを用いてメッセージを送信できる。また、リモート送受信部113はWebブラウザ10が対応しない任意のプロトコルを用いたサーバ機能を実行し、外部デバイス3からの接続を待ち受けることもできる。

【0034】

図2A，2Bは、プログラムP1による外部デバイス3へのメッセージ送信の手順を示したシーケンスフローである。

【0035】

時刻t1において、デバイス1のユーザがWebブラウザ10からWebサーバ2のプログラムP1を起動するためのURLへアクセスすると、時刻t2では、Webブラウザ10がWebサーバ2へプログラムP1をリクエストする。時刻t3では、Webサーバ2が当該要求に応答してプログラムP1をWebブラウザ10へ提供する。

【0036】

時刻t4において、Webブラウザ10がプログラム実行エンジン101に対してプログラムP1の起動を要求すると、プログラム実行エンジン101は、時刻t5においてプログラムP1を起動する。プログラムP1は、時刻t6において既定の処理を実施し、時刻t7においてプログラム実行エンジン101へ通信機能の呼び出しを要求する。

【0037】

プログラム実行エンジン101は、時刻t8において前記呼び出し要求に応答し、ローカル送受信部111へHTTPでメッセージを送信する。ローカル送受信部111は、時刻t9において前記メッセージをメッセージ処理部112へ転送する。

【0038】

メッセージ処理部112は、時刻t10において前記メッセージの宛先を外部デバイス3に変更し、プロトコルをHTTPからMQTTに変換し、時刻t11においてリモート送受信部113へ転送する。リモート送受信部113は、転送されたメッセージを時刻t12において外部デバイス3へMQTTで送信する。

【0039】

外部デバイス3は、時刻t13においてメッセージ応答をMQTTでリモート送受信部113へ送信する。リモート送受信部113は、前記メッセージ応答を時刻t14においてメッセージ処理部112へ転送する。

【0040】

メッセージ処理部112は、時刻t15において前記転送されたメッセージ応答の宛先をプログラムP1に変更し、プロトコルをMQTTからHTTPへ変換し、更に応答コードを設定する。応答コードには、受信した応答メッセージの内容に応じて任意のコードを設定することができる。例えば、MQTTにおいてメッセージの受信を意味するPUBACKメッセージを応答として受信した場合には、HTTPの応答コードとしてリクエスト成功を示す200 OKを設定する。また一定時間以内に応答メッセージを受信できなかった場合にはHTTP応答コードとして408 Request Timeoutを設定することができる。前記応答メッセージは、時刻t16においてメッセージ処理部112からローカル送受信部111へ転送される。

【0041】

ローカル送受信部111は、時刻t17において前記応答メッセージをプログラム実行エンジン101へHTTPプロトコルで転送する。プログラム実行エンジン101は、時刻t18においてプログラムP1へ通信機能を応答する。プログラムP1は、時刻t19において前記応答結果を処理する。

【0042】

本実施形態によれば、Webブラウザ内で動作するプログラムは、 デバイス1内に配置したプロキシ機能11がメッセージの加工処理を実施することで、プログラム実行エンジンが提供しないプロコトルを用いて外部デバイス3とのメッセージ交換を実施できるようになる。

【0043】

図3は、プログラムP1によるメッセージ受信の機能ブロック図であり、図4A，4Bは、メッセージ受信の手順を示したシーケンスフローである。ここでは、外部デバイス3が送信したメッセージをデバイス1がPush動作で受信する場合を例にして説明する。本実施形態では、予めローカル送受信部111においてHTTPサーバ機能が起動されており、リモート送受信部113においてMQTTサーバ機能が起動されている。

【0044】

時刻t31において、デバイス1のユーザがWebブラウザ10からWebサーバ2のプログラムP1を起動するためのURLへアクセスすると、時刻t32では、Webブラウザ10がWebサーバ2へプログラムP1をリクエストする。時刻t33では、Webサーバ2が当該要求に応答して送信したプログラムP1をWebブラウザ10が取得する。

【0045】

時刻t34において、Webブラウザ10がプログラム実行エンジン101に対してプログラムP1の起動を要求すると、プログラム実行エンジン101は、時刻t35においてプログラムP1を起動する。時刻t36において、プログラムP1がプログラム実行エンジン101に対して通信機能の呼び出しを要求すると、プログラム実行エンジン101は、時刻t37においてローカル送受信部111へプログラム登録メッセージをHTTPで送信する。

【0046】

ローカル送受信部111は、時刻t38においてメッセージ処理部112へプログラムを登録する。メッセージ処理部112は、時刻t39においてプログラム登録メッセージ応答をローカル送受信へ送信する。ローカル送受信部111は、時刻t40においてプログラム登録メッセージ応答をHTTPでプログラム実行エンジン101へ送信する。

【0047】

プログラム実行エンジン101は、時刻t41において登録結果をプログラムP1へ応答する。プログラムP1は、時刻t42においてWebSocketをプログラム実行エンジン101へ要求する。プログラム実行エンジン101は、時刻t43においてローカル送受信部111へWebSocketコネクション要求をHTTPで送信する。ローカル送受信部111は、時刻t44においてWebSocketコネクション応答をHTTPでプログラム実行エンジン101へ送信する。プログラム実行エンジン101は、時刻t45においてWebSocketの確立をプログラムP1へ報告する。

【0048】

その後、外部デバイス3が時刻t51においてメッセージ送信のためにコネクションの確立をMQTTでリモート送受信部113へ要求すると、リモート送受信部113は、時刻t52においてコネクション確立応答をMQTTで返信する。外部デバイス3は、時刻t53においてメッセージM1をMQTTでリモート送受信部113へ送信する。本実施形態では、図3に示すように、プロトコルが「MQTT」、宛先が「デバイス1」、識別子が「86f021」、データが「abc」のメッセージM1が送信される。

【0049】

リモート送受信部113は、時刻t54において前記メッセージM1をメッセージ処理部112へ転送する。メッセージ処理部112は、図3に示すように、時刻t55において前記メッセージM1のプロトコルをMQTTからWebSocketに変換し、宛先をプログラムP1[local host:35001]に変更し、時刻t56において、前記プロトコルや宛先が加工されたメッセージm1をローカル送受信部111へ転送する。

【0050】

ローカル送受信部111は、受信したメッセージm1を時刻57においてWebSocketでプログラム実行エンジン101へ送信する。プログラム実行エンジン101は、時刻t58において前記メッセージm1をプログラムP1へ通知する。プログラムP1は、時刻t59において前記メッセージm1を処理し、時刻t60において処理結果をプログラム実行エンジン101へWebSocketで送信する。

【0051】

プログラム実行エンジン101は、時刻t61において前記処理結果をWebSocketでローカル送受信部111へ送信する。ローカル送受信部111は、時刻t62において前記処理結果をメッセージ処理部112へ転送する。メッセージ処理部112は、時刻t63において前記処理結果の宛先を外部デバイス3に変更し、プロトコルをMQTTに変換し、時刻t64においてリモート送受信部113へ転送する。リモート送受信部113は、時刻t65においてメッセージ応答完了をMQTTで外部デバイス3へ応答する。

【0052】

図5は、プログラムP1によるメッセージ受信の他の機能ブロック図であり、図6A～6Dは、メッセージ受信の手順を示したシーケンスフローである。ここでは外部デバイス3が送信したメッセージをデバイス1がPoling動作で受信する場合を例にして説明する。本実施形態では、予めローカル送受信部111においてHTTPサーバ機能が起動され、リモート送受信部113においてMQTTサーバ機能が起動される。

【0053】

時刻t71において、デバイス1のユーザがWebブラウザ10からWebサーバ2のプログラムP1を起動するためのURLへアクセスすると、時刻t72では、Webブラウザ10がWebサーバ2へプログラムP1をリクエストする。時刻t73では、Webサーバ2が当該要求に応答して送信したプログラムP1をWebブラウザ10が取得する。

【0054】

時刻t74において、Webブラウザ10がプログラム実行エンジン101に対してプログラムP1の起動を要求すると、プログラム実行エンジン101は時刻t75においてプログラムP1を起動する。

【0055】

時刻t76において、プログラムP1がプログラム実行エンジン101に対して通信機能の呼び出しを要求すると、プログラム実行エンジン101は、時刻t77において前記呼び出し要求に応答し、プログラム登録メッセージをHTTPでローカル送受信部111へ送信する。ローカル送受信部111は、時刻t78においてメッセージ処理部112へプログラムを登録する。

【0056】

メッセージ処理部112は、時刻t79においてプログラム登録メッセージ応答をローカル送受信部111へ送信する。ローカル送受信部111は、時刻t80においてプログラム登録メッセージの応答をHTTPでプログラム実行エンジン101へ送信する。プログラム実行エンジン101は、時刻t81において登録結果応答をプログラムP1へ送信する。

【0057】

その後、外部デバイス3が時刻t91において、メッセージ送信のためにデバイス1に対してコネクションの確立をMQTTで要求し、時刻t92においてリモート送受信部113がコネクション確立応答をMQTTで返信すると、外部デバイス3は時刻t93において、メッセージをMQTTでリモート送受信部113へ送信する。本実施形態では、図5に示すように、プロトコルが「MQTT」、宛先が「デバイス1」、識別子が「86f021」、データが「abc」のメッセージM1が送信される。

【0058】

リモート送受信部113は、時刻t94において前記メッセージM1をメッセージ処理部112へ転送する。メッセージ処理部112は時刻t95において、図5に示すように、前記メッセージM1から識別子「86f021」及びデータ「abc」を抽出し、時刻t96においてメッセージキャッシュ114へ格納する。更に時刻t97において、メッセージの処理結果をリモート送受信部113へ通知する。なお、通知された処理結果が失敗であると、リモート送受信部113は無応答で当該処理を終了する。

【0059】

その後、プログラムP1は所定の周期でプログラム実行エンジン101へ通信機能呼出しの要求を繰り返してPolingによるメッセージ受信を繰り返す。本実施形態では、時刻t101においてプログラムP1がプログラム実行エンジン101へ通信機能呼出しを要求すると、時刻t102において、プログラム実行エンジン101からローカル送受信部111へ受信確認メッセージ送信がHTTPで送信される。時刻t103では、ローカル送受信部111からメッセージ処理部112へ受信確認が行われる。

【0060】

時刻t104において、メッセージ処理部112がメッセージキャッシュ114に対してメッセージの取得を要求した際、メッセージキャッシュ114にメッセージが蓄積されていれば、時刻t105においてメッセージキャッシュ114がメッセージ応答をメッセージ処理部112へ送信する。時刻t106では、メッセージ処理部112が前記メッセージの宛先をプログラムP1に変更し、メッセージ応答へHTTPヘッダを付加する。当該メッセージは時刻t107においてローカル送受信部111へ転送される。

【0061】

ローカル送受信部111は、時刻t108において前記メッセージをプログラム実行エンジン101へHTTPで送信する。プログラム実行エンジン101は、時刻t109において通信機能応答をプログラムP1へ送信する。プログラムP1は、時刻t110において応答結果を処理する。

【0062】

メッセージ処理部112は、前記時刻t107においてメッセージをローカル送受信部111へ送信した後、時刻t111において、メッセージの送信結果をリモート送受信部113へ通知する。リモート送受信部113は、時刻t112においてメッセージ送信完了応答をMQTTで外部デバイス3へ送信する。

【0063】

これに対して、メッセージキャッシュ114にメッセージが蓄積されていなければ、メッセージキャッシュ114は時刻t113において、メッセージ無しをメッセージ処理部112へ通知する。

【0064】

メッセージ処理部112は、時刻t114においてメッセージ無しをローカル送受信部111へ通知する。ローカル送受信部111は、時刻t115においてメッセージ無しをHTTPでプログラム実行エンジン101へ通知する。プログラム実行エンジン101は、時刻t116において通信機能応答をプログラムP1へ送信する。

【0065】

本実施形態によれば、デバイス1内に配置したプロキシ機能11がメッセージの加工処理および一時保持を実施するので、外部デバイス3から送信したメッセージをWebブラウザ10内で動作するプログラムが受信できるようになる。

【0066】

図7は、本発明の利用シーンの一例を示した図であり、ユーザは前記デバイス1としてスマートフォン4及びパソコン5を所有する。スマートフォン4にはWebブラウザ及びプロキシ機能と共にVRプログラムが実装され、パソコン5にはWebブラウザ及びプロキシ機能と共に映像処理サーバプログラムが実装されている。

【0067】

スマートフォン4のVRプログラムはWebブラウザ上で動作し、IoT端末としてのカメラ6とは、プロキシ機能を用いることでWebブラウザが対応しないMQTTで映像や制御信号を送受信できる。また、クラウド上のコンテナ仮想化基盤等のアプリケーションとは、プロキシ機能を用いることでWebブラウザが対応しないgRPCプロトコルで連携動作できる。パソコン5とはHTTPでデータやメッセージを送受信できる。

【0068】

同様に、パソコン5の映像処理サーバプログラムもWebブラウザ上で動作し、カメラ6とはMQTTで、クラウド上のコンテナ仮想化基盤とはgRPCプロトコルで、パソコン5とはHTTPで、それぞれ各種のデータやメッセージを送受信できる。

【0069】

なお、プロキシ機能11の用途はメッセージ等の送受信を可能化する代理処理に限定されるものではなく、プログラムP1，P2が送信するメッセージに対する暗号化機能や認証機能の提供にも利用できる。これにより、プログラムごとに暗号化機能や認証機能を実装する必要がなくなり、プロキシ機能11で一括処理することができるようになる。

【0070】

また、プログラムP1，P2が送信しようとするメッセージの宛先及び内容に基づいて当該メッセージの送信を許可又は禁止する機能や、プログラムP1，P2が送信するメッセージを、予め登録されている複数の宛先へ送信する機能をプロキシ機能11に提供させるようにしても良い。

【0071】

なお、上記の実施形態では双方向通信チャネルとしてWebSocketを例にして説明したが、本発明はこれのみに限定されるものではなく、WebRTC等の他の双方向通信チャネル技術を用いても同様に実現できる。

【0072】

そして、上記の実施形態によれば、Webブラウザを備えたデバイスにプロキシ機能を実装することで、Webブラウザのプログラム実行エンジンでは制限されるプロトコル、双方向通信及び外部のデバイスからの通信待受といった通信機能を使用できるようになる。したがって、国連が主導する持続可能な開発目標（SDGs）の目標9「レジリエントなインフラを整備し、包括的で持続可能な産業化を推進する」や目標11「都市を包摂的、安全、レジリエントかつ持続可能にする」に貢献することが可能となる。

【符号の説明】

【0073】

1…デバイス，2…Webサーバ，3…外部デバイス，10…Webブラウザ，11…プロキシ機能，101…プログラム実行エンジン，111…ローカル送受信部，112…メッセージ処理部，113…リモート送受信部，114…メッセージキャッシュ

【図1】

【図2A】

【図2B】

【図3】

【図4A】

【図4B】

【図5】

【図6A】

【図6B】

【図6C】

【図6D】

【図7】