特開 2023-136875 通信制御装置、通信制御方法及びプログラム

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

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

(11)【公開番号】P2023136875

(43)【公開日】2023-09-29

(54)【発明の名称】通信制御装置、通信制御方法及びプログラム

(51)【国際特許分類】

   H04L 67/568 20220101AFI20230922BHJP

   H04L 67/12 20220101ALI20230922BHJP

   H04M 11/00 20060101ALI20230922BHJP

   H04Q 9/00 20060101ALI20230922BHJP

【ＦＩ】

H04L67/568

H04L67/12

H04M11/00 302

H04Q9/00 311H

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2022042804

(22)【出願日】2022-03-17

(71)【出願人】

【識別番号】000006747

【氏名又は名称】株式会社リコー

(74)【代理人】

【識別番号】100089118

【弁理士】

【氏名又は名称】酒井 宏明

(72)【発明者】

【氏名】鷹野 友英

【テーマコード（参考）】

5K048

5K201

【Ｆターム（参考）】

5K048BA34

5K201BA02

5K201ED09

(57)【要約】

【課題】より簡易な構成で、システムリソースの無駄な消費を低減させる。
【解決手段】実施形態の通信制御装置は、センサにより取得されたセンサ情報を受信する受信部と、未送信の前記センサ情報を記憶するバッファと、前記センサ情報を記憶する第１のデータファイルの書込可否状態に基づいて、前記センサ情報を送信するタイミングを制御する送信タイミング制御部と、前記第１のデータファイルに前記センサ情報を記憶するサーバ装置へ、前記バッファに記憶されたセンサ情報を送信する送信部と、を備える。
【選択図】図５

【特許請求の範囲】

【請求項1】

センサにより取得されたセンサ情報を受信する受信部と、
未送信の前記センサ情報を記憶するバッファと、
前記センサ情報を記憶する第１のデータファイルの書込可否状態に基づいて、前記センサ情報を送信するタイミングを制御する送信タイミング制御部と、
前記第１のデータファイルに前記センサ情報を記憶するサーバ装置へ、前記バッファに記憶されたセンサ情報を送信する送信部と、
を備える通信制御装置。

【請求項2】

前記送信タイミング制御部は、前記サーバ装置から前記第１のデータファイルの書込不可を示す状態情報を受信した場合、前記センサ情報を送信するタイミングの間隔の長さを増加させる、
請求項１に記載の通信制御装置。

【請求項3】

前記第１のデータファイルは、クラウド環境のストレージに記憶され、
前記センサ情報は、前記サーバ装置によるクラウドサービスにより前記ストレージの第１のデータファイルに記憶され、
前記送信タイミング制御部は、前記クラウドサービスのＷｅｂフックによって、前記第１のデータファイルの書込不可を示す状態情報を受信した場合、前記センサ情報を送信するタイミングの間隔の長さを増加させる、
請求項１に記載の通信制御装置。

【請求項4】

前記送信タイミング制御部は、前記バッファに記憶されたセンサ情報のデータサイズが第１閾値より大きい場合、ユーザによって書込不可にされることのない第２のデータファイルに、前記センサ情報を記憶することを決定し、
前記送信部は、前記センサ情報の記憶先を、前記第２のデータファイルに変更して、前記サーバ装置へ前記センサ情報を送信する、
請求項１乃至３のいずれか１項に記載の通信制御装置。

【請求項5】

前記書込不可を示す状態情報は、前記第１のデータファイルを閲覧しているユーザを識別する識別情報を更に含み、
前記送信部は、前記識別情報に基づいて前記ユーザが利用する端末を特定し、前記端末へ、前記第１のデータファイルのクローズを促す通知を送信する、
請求項２乃至４のいずれか１項に記載の通信制御装置。

【請求項6】

前記第１のデータファイルが書込不可であり、かつ、前記バッファに記憶されたセンサ情報のデータサイズが第２閾値より大きい場合、前記センサによる前記センサ情報の取得処理を停止させるデバイス制御部、
を更に備える請求項１乃至５のいずれか１項に記載の通信制御装置。

【請求項7】

前記センサは、検温対象の温度を検出する検温デバイスである、
請求項１乃至６のいずれか１項に記載の通信制御装置。

【請求項8】

通信制御装置が、センサにより取得されたセンサ情報を受信するステップと、
前記通信制御装置が、未送信の前記センサ情報を記憶するステップと、
前記通信制御装置が、前記センサ情報を記憶する第１のデータファイルの書込可否状態に基づいて、前記センサ情報を送信するタイミングを制御するステップと、
前記通信制御装置が、前記第１のデータファイルに前記センサ情報を記憶するサーバ装置へ、前記記憶するステップで記憶されたセンサ情報を送信するステップと、
を含む通信制御方法。

【請求項9】

コンピュータを、
センサにより取得されたセンサ情報を受信する受信部と、
未送信の前記センサ情報を記憶するバッファと、
前記センサ情報を記憶する第１のデータファイルの書込可否状態に基づいて、前記センサ情報を送信するタイミングを制御する送信タイミング制御部と、
前記第１のデータファイルに前記センサ情報を記憶するサーバ装置へ、前記バッファに記憶されたセンサ情報を送信する送信部、
として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信制御装置、通信制御方法及びプログラムに関する。

【背景技術】

【0002】

近年、企業が、事業環境変化の中で、ＩＣＴ（Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）活用による事業創出、業務プロセス改革、及び、顧客サービス改善等に取り組む活動が、ＤＸ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ）として注目されている。そのＤＸ活動を支えるＩＣＴ技術の一つにＩｏＴ及びＡＩを用いたデータプラットフォームがあり、ＩｏＴによりこれまで収集できていなかったデータを獲得し、ＡＩを用いた分析によりデータからの価値を引き出すことで、データをビジネスに活かすことが可能となる。

【0003】

例えば特許文献１には、ログアップロード処理の実行に先だって、サーバにおけるログアップロード処理に係る実行の可否を事前に確認するに関する技術が開示されている。

【発明の概要】

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

【0004】

しかしながら、従来の技術では、より簡易な構成で、システムリソースの無駄な消費を低減させることが難しかった。

【0005】

本発明は、上記に鑑みてなされたものであって、より簡易な構成で、システムリソースの無駄な消費を低減させることができる通信制御装置、通信制御方法及びプログラムを提供することを目的とする。

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

【0006】

上述した課題を解決し、目的を達成するために、本発明は、センサにより取得されたセンサ情報を受信する受信部と、未送信の前記センサ情報を記憶するバッファと、前記センサ情報を記憶する第１のデータファイルの書込可否状態に基づいて、前記センサ情報を送信するタイミングを制御する送信タイミング制御部と、前記第１のデータファイルに前記センサ情報を記憶するサーバ装置へ、前記バッファに記憶されたセンサ情報を送信する送信部と、を備えることを特徴とする。

【発明の効果】

【0007】

本発明によれば、より簡易な構成で、システムリソースの無駄な消費を低減させることができるという効果を奏する。

【図面の簡単な説明】

【0008】

【図1】図１は、実施形態の情報処理システムの装置構成の例を示す図である。

【図2】図２は、実施形態の通信制御装置、サーバ装置及び端末のハードウェア構成の例を示す図である。

【図3】図３は、クラウドサービスの問題点及び副作用について説明するための図である。

【図4】図４は、実施形態のエラー通知の例を示す図である。

【図5】図５は、実施形態の情報処理システムの機能構成の例を示す図である。

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

【0009】

以下に添付図面を参照して、通信制御装置、通信制御方法及びプログラムの実施形態を詳細に説明する。

【0010】

情報処理システムに用いられるデータプラットフォームは、多様化、多機能化しており、クラウドサービスとして提供される形態が一般化している。例えば、情報処理システムに用いられるデータプラットフォームは、Ｍｉｃｒｏｓｏｆｔ（登録商標）のＰｏｗｅｒＢＩ、及び、ＡＷＳ（登録商標）のＱｕｉｃｋＳｉｇｈｔ等がある。

【0011】

中小企業においてはＤＸ（デジタルトランスフォーメーション）が進んでいない、またはそこまで大掛かりなデータプラットフォームを必要としないケースも存在する。例えば日常業務の改善として、コロナ禍の付帯業務である従業員の検温記録について、紙ベースの台帳に記録していたものを表計算ファイル等による電子記録に置き換えるだけでも十分なケースもある。

【0012】

このように必ずしも大規模なデータプラットフォームは必要ではなく、ケースバイケースにＩｏＴで収取したデータをクラウド上のストレージに表計算ファイル保存するだけでも働き方改革としての効果を期待できる。

【0013】

小規模な働き方改革の一例として、検温業務の自動記録化が考えられる。例えば、顔認証＆検温して、クラウドストレージに自動記録するサービスが存在する。大規模なデータプラットフォームは必要なく、検温デバイスで収集した検温記録をクラウドストレージ状の表計算ファイルに出力するシンプルな構成である。

【0014】

ＩｏＴクラウドサービスは、ＩｏＴ Ｇａｔｅｗａｙとストレージサービスの橋渡しをする役割（ＩｏＴ Ｇａｔｅｗａｙのデバイス認証、サービスの課金、データ加工、及び、他システム連携による機能拡張等）で必要となる。

【0015】

しかしながら表計算ファイルに出力する関係上、ユーザが任意のタイミングでファイルを閲覧（ロック）し、自動記録ができなくなるケースが発生する。この自動記録できなかったデータはリトライが必要となるが、無駄にリトライすると、ストレージサービスのＡＰＩコール上限に抵触してストレージ自体の書込が一定期間不可といった副作用が発生してしまう可能性が存在する。

【0016】

実施形態の情報処理システムは、ＩｏＴセンサ等の端末機器からのセンサ値、タイムスタンプ及び画像データ等を情報収集して管理するシステムにおいて、クラウド上の蓄積先（例えば、ストレージ等）の状態変化に応じて記録タイミングを変更するシステムである。クラウド上の蓄積先（例えば、ストレージ等）の状態は、例えば出力先の表計算ソフトウェア（例えば、Ｅｘｃｅｌ（登録商標））に作成されたスプレッドシートがユーザによりロックされている状態等である。

【0017】

［装置構成の例］
図１は、実施形態の情報処理システムの装置構成の例を示す図である。実施形態の情報処理システムは、センサ１、通信制御装置２、サーバ装置３、ストレージ４及び端末５を備える。

【0018】

センサ１は、センサ情報を取得するデバイスである。例えば、センサ１は、検温対象の温度を検出する検温デバイスである。具体的には、センサ１は、例えばサーマルカメラを備え、事前登録した人物写真をもとに個人を特定した上で検温結果を含むセンサ情報を生成する検温デバイスである。以下、センサ１が検温デバイスである場合を例にして説明する。

【0019】

通信制御装置２は、センサ１からセンサ情報を受信し（ステップＳ１）、当該センサ情報をサーバ装置３へ送信する（ステップＳ２）。通信制御装置２は、例えばＩｏＴ Ｇａｔｅｗａｙである。例えば、通信制御装置２は、センサ１のＷｅｂＡＰＩ経由で、検温結果を含むセンサ情報を取得する。このＷｅｂＡＰＩには、例えばアクティブモード（自動ＰＯＳＴ）とポーリングモードとがある。

【0020】

アクティブモード（自動ＰＯＳＴ）では、ＷｅｂＡＰＩが、データの取得スタート制御を行うと、これ以降に検温データが生成され、当該検温データを含むセンサ情報が、通信制御装置２へＨＴＴＰ（ＨＴＴＰＳ）で自動的にＰＯＳＴされる。また、ＷｅｂＡＰＩが、取得停止制御するとＰＯＳＴが停止する。

【0021】

ポーリングモードでは、ＷｅｂＡＰＩが取得制御を行うと、生成された検温記録が存在すれば、センサ情報として、通信制御装置２によって取得される。

【0022】

なお、ネットワークトポロジー上、センサ１と通信制御装置２とは１：ｎの関係である。

【0023】

また、通信制御装置２は、センサ１から取得されたセンサ情報を、サーバ装置３へ送信する。この際、通信制御装置２は、データバッファリング及び不要なデータのフィルタリングを行い、また、センサ１と通信制御装置２とは１：ｎの関係であることから、Ｐｒｏｘｙとして効率的なデータ送信を実現する。

【0024】

なお、図１では、通信制御装置２は、オンプレミス環境に配置することを想定しているが、クラウド環境に配置してもよい。

【0025】

サーバ装置３は、通信制御装置２から受信したデータを、適宜、加工し、ストレージ４に記憶するＩｏＴクラウドサービスを実現する装置である（ステップＳ３）。

【0026】

ストレージ４は、情報を記憶するクラウドストレージである。クラウドストレージは、例えばｏｎｅ ｄｒｉｖｅ（登録商標）、ｇｏｏｇｌｅ ｄｒｉｖｅ（登録商標）、及び、ｂｏｘ（登録商標）といったサービスを利用できる。これらのクラウドストレージサービスは、単位時間（例：一日）あたりのアクセス回数に上限があり、負荷の上限を抑制している。そのため、少ないアクセス数で活用することが望ましい。

【0027】

ストレージ４には、センサ情報に基づくデータを、例えば表計算ファイル（第１のデータファイルの例）と、ＣＳＶファイル（第２のデータファイルの例）とで記憶する。表計算ファイルは、ユーザ閲覧用のセンサ情報（例えば、検温データ）を示すデータである。ＣＳＶファイルは、ストレージサービスの永続化用のデータ（表計算ファイルへのコンバート用のマスタデータ）である。

【0028】

端末５は、ストレージ４を利用するユーザが、ストレージ４の表計算ファイルを任意のタイミングで閲覧するときに使用される端末である（ステップＳ４）。

【0029】

［ハードウェア構成の例］
図２は、実施形態の通信制御装置２、サーバ装置３及び端末５のハードウェア構成の例を示す図である。

【0030】

図２に示されているように、通信制御装置２、サーバ装置３及び端末５は、コンピュータによって構築されており、図２に示されているように、ＣＰＵ５０１、ＲＯＭ５０２、ＲＡＭ５０３、ＨＤ５０４、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）コントローラ５０５、ディスプレイ５０６、外部機器接続Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）５０８、ネットワークＩ／Ｆ５０９、バスライン５１０、キーボード５１１、ポインティングデバイス５１２、ＤＶＤ－ＲＷ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ Ｒｅｗｒｉｔａｂｌｅ）ドライブ５１４、メディアＩ／Ｆ５１６を備えている。

【0031】

これらのうち、ＣＰＵ５０１は、通信制御装置２、サーバ装置３及び端末５全体の動作を制御する。ＲＯＭ５０２は、ＩＰＬ等のＣＰＵ５０１の駆動に用いられるプログラムを記憶する。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。ＨＤ５０４は、プログラム等の各種データを記憶する。ＨＤＤコントローラ５０５は、ＣＰＵ５０１の制御にしたがってＨＤ５０４に対する各種データの読み出し又は書き込みを制御する。ディスプレイ５０６は、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。外部機器接続Ｉ／Ｆ５０８は、各種の外部機器を接続するためのインターフェースである。この場合の外部機器は、例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリやプリンタ等である。ネットワークＩ／Ｆ５０９は、通信ネットワーク１００を利用してデータ通信をするためのインターフェースである。バスライン５１０は、図２に示されているＣＰＵ５０１等の各構成要素を電気的に接続するためのアドレスバスやデータバス等である。

【0032】

また、キーボード５１１は、文字、数値、各種指示などの入力のための複数のキーを備えた入力手段の一種である。ポインティングデバイス５１２は、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行う入力手段の一種である。ＤＶＤ－ＲＷドライブ５１４は、着脱可能な記録媒体の一例としてのＤＶＤ－ＲＷ５１３に対する各種データの読み出し又は書き込みを制御する。なお、ＤＶＤ－ＲＷに限らず、ＤＶＤ－Ｒ等であってもよい。メディアＩ／Ｆ５１６は、フラッシュメモリ等の記録メディア５１５に対するデータの読み出し又は書き込み（記憶）を制御する。

【0033】

なお、図２の構成は一例であり、通信制御装置２、サーバ装置３及び端末５の構成は、適宜、変更されてもよい。例えば、通信制御装置２及びサーバ装置３については、一部の構成（例えば、ディスプレイ５０６、キーボード５１１、ポインティングデバイス５１２及びＤＶＤ－ＲＷドライブ５１４等）を備えていなくてもよい。

【0034】

［問題点及び副作用］
図３は、クラウドサービスの問題点及び副作用について説明するための図である。図３の例は、センサ１（例えば検温デバイス）が、クラウド上のストレージ４にある帳票ファイル（図３の例では、表計算ファイル）に、センサ情報を自動的に記録するサービスの流れを示す。

【0035】

はじめに、通信制御装置２が、センサ情報を取得する（ステップＳ１１）。次に、通信制御装置２が、ステップＳ１１で取得されたセンサ情報をフィルタリングする（ステップＳ１２）。

【0036】

一方、端末５は、ストレージ４の帳票ファイルを閲覧するため、ファイルオープンする（ステップＳ１５）。

【0037】

次に、通信制御装置２が、ステップＳ１２でフィルタリングされたセンサ情報をサーバ装置３へ送信する（ステップＳ１３）。次に、サーバ装置３が、ステップＳ１３で受信されたセンサ情報を、適宜、加工する（ステップＳ１４）。次に、サーバ装置３が、ファイル書き込みをＣＳＶファイルに行い（ステップＳ１６）、当該ＣＳＶファイルを取得し（ステップＳ１７）、ＣＳＶファイルから表計算ファイルへのファイル書き込みを行う（ステップＳ１８）と、ステップＳ１８の処理が失敗する。

【0038】

これは、ユーザが、表計算ファイルをオープンしていると、表計算ファイルはロックされ、自動書き込みが不可となるためである（問題点）。この書き込み失敗に対して自動的にリトライを繰り返すと、クラウドストレージのＷｅｂＡＰＩコール数を無駄に消費することになり、上限を超えるとＣＳＶファイルへの書き込みも合わせて不可となる（問題点の副作用）。

【0039】

なお、端末５が、表計算ファイルをクローズした後に（ステップＳ１９）、ステップＳ１８の処理を実行すると、ステップＳ１８の処理は成功する。

【0040】

［エラー通知の例］
図４は、実施形態のエラー通知の例を示す図である。図４の例は、図３のステップＳ１８で処理が失敗したときに、サーバ装置３及び端末５等に通知されるエラー通知の例である。図４の例は、ストレージ４の帳票ファイルが、Ｅｘｃｅｌ（登録商標）ファイルである場合を示す。

【0041】

［機能構成の例］
図５は、実施形態の情報処理システムの機能構成の例を示す図である。実施形態の情報処理システムの通信制御装置２は、デバイス制御部２１、受信部２２、バッファ２３、記憶部２４、送信タイミング制御部２５、タイマー２６及び送信部２７を備える。

【0042】

デバイス制御部２１は、センサ１のセンサ情報の取得処理の開始制御を行う。また、デバイス制御部２１は、バッファ２３及び表計算ファイルの状態に基づいて、センサ情報の取得処理の停止制御を行う。

【0043】

例えば、１分間に１回、表計算ファイルへの書き込み処理が行われる場合、ユーザが１０分ほど表計算ファイルを閲覧すると、１０回分の無駄な書き込み処理が施行されることになる。さらにこのロック期間中、センサ１で生成されたセンサ情報がサーバ装置３へ通信されると、通信制御装置２では未送信のセンサ情報をバッファ２３へバッファリングしなくてはならなくなり、余計なストレージ容量を消費することとなる。

【0044】

このキャッシュあふれ（データロス）対策として、デバイス制御部２１は、書き込みエラー検知時およびバッファ２３上にバッファされたセンサ情報のサイズが一定量以上に達した場合（スレッショルドオーバー）に、センサ１のＷｅｂＡＰＩ経由でセンサ情報取得の停止処理をする。例えば、デバイス制御部２１は、表計算ファイル（第１のデータファイルの例）が書込不可であり、かつ、バッファ２３に記憶されたセンサ情報のデータサイズが第２閾値より大きい場合、センサ１によるセンサ情報の取得処理を停止させる。

【0045】

受信部２２は、センサ１からセンサ情報を受信する。バッファ２３は、センサ情報をバッファする。

【0046】

記憶部２４は情報を記憶する。例えば、記憶部２４は、ストレージ４の表計算ファイルの状態を記憶する。表計算ファイルの状態（書込可否）は、書き込み処理のトライ結果が、サーバ装置３経由で通信制御装置２に通知され、記憶部２４に保持される。

【0047】

送信タイミング制御部２５は、サーバ装置３へのセンサ情報の送信タイミングを最適化する。例えば、送信タイミング制御部２５は、所定時間が経過するまで、センサ情報の送信を停止することで無駄な書き込みトライの発生を抑制する。具体的には、送信タイミング制御部２５は、センサ情報がバッファ２３にバッファされていれば、即時通知し、その後、５分間は送信を禁止する。この停止の解除は、例えばタイマー２６による一定期間の他、ストレージ４（クラウドストレージ）が提供するＷｅｂｈｏｏｋを使用してもよい。

【0048】

なお、送信タイミング制御部２５が、エラー検知をするバリエーションとしては、例えば表計算ファイルの書き込みエラーの受信、及び、クラウドサービスのＷｅｂｈｏｏｋ機能がある。例えば、表計算ファイル（第１のデータファイルの例）が、クラウド環境のストレージ４に記憶され、センサ情報が、サーバ装置３によるクラウドサービスによりストレージ４の表計算ファイルに記憶される場合、当該クラウドサービスのＷｅｂｈｏｏｋ機能を利用できる。この場合、送信タイミング制御部２５は、クラウドサービスのＷｅｂフックによって、表計算ファイルの書込不可を示す状態情報を受信した場合、センサ情報を送信するタイミングの間隔の長さを増加させる。

【0049】

また、送信タイミングの変更処理は、通信制御装置２からサーバ装置３へセンサ情報を送信する送信処理の実行条件を変更する処理を含む。例えば、通信制御装置２において、通常時の送信処理の実行条件は、バッファ２３に送信対象のセンサ情報が存在し、かつ、前回の送信から１分経過していることである。エラー発生時の送信処理の実行条件は、バッファ２３に送信対象のセンサ情報が存在し、かつ、前回の送信から５分経過していることである。すなわち、送信タイミング制御部２５は、サーバ装置３から表計算ファイル（第１のデータファイルの例）の書込不可を示す状態情報を受信した場合、センサ情報を送信するタイミングの間隔の長さを増加させる。

【0050】

また、送信タイミング制御部２５は、バッファ２３に記憶されたセンサ情報のデータサイズが第１閾値より大きい場合、ユーザによって書込不可にされることのないＣＳＶファイル（第２のデータファイルの例）に、センサ情報を記憶することを決定してもよい。この場合、送信部２７は、センサ情報の記憶先を、第２のデータファイルに変更して、サーバ装置３へセンサ情報を送信する。例えば図５の例では、ＣＳＶファイル（クラウド上のロックされないキャッシュ）に、センサ情報を保存することでデータロスの確率を軽減することができる。

【0051】

送信部２７は、センサ情報に認証トークンを付与し、認証トークンが付与されたセンサ情報をサーバ装置３に送信する。

【0052】

なお、サーバ装置から受信される表計算ファイル（第１のデータファイルの例）の書込不可を示す状態情報は、表計算ファイルを閲覧しているユーザを識別する識別情報を更に含んでいてもよい。この場合、送信部２７は、識別情報に基づいてユーザが利用する端末５を特定し、端末５へ、表計算ファイルのクローズを促す通知（例えば、図４参照）を送信する。なお、表計算ファイルのクローズを促す通知は、例えばダイアログ、メール及びメッセージ等の任意の通知方法でよい。

【0053】

サーバ装置３（ＩｏＴクラウドサービス）は、認証部３１とワークフロー部３２とを備える。認証部３１は、通信制御装置２から受信されたセンサ情報に付与された認証トークンを判定することによって、センサ情報の送信元の通信制御装置２を認証する。

【0054】

ワークフロー部３２は、例えばＷｅｂＡＰＩ経由で通信制御装置２から受信されたセンサ情報を、他のストレージサービス（ストレージ４）へ橋渡しする中間モジュールである。ワークフロー部３２は、永続的な記憶領域を備えない簡易な機能部として構築されていてもよい。

【0055】

以上、説明したように、実施形態の通信制御装置２では、受信部２２が、センサ１により取得されたセンサ情報を受信する。バッファ２３が、未送信のセンサ情報を記憶する。送信タイミング制御部２５が、センサ情報を記憶する表計算ファイル（第１のデータファイルの例）の書込可否状態に基づいて、センサ情報を送信するタイミングを制御する。そして、送信部２７が、表計算ファイルにセンサ情報を記憶するサーバ装置３へ、バッファ２３に記憶されたセンサ情報を送信する。

【0056】

これにより実施形態の通信制御装置２によれば、より簡易な構成で、システムリソースの無駄な消費を低減させることができる。

【0057】

例えば、上記図５に示す構成によれば、複数のクラウドサービス（実施形態では、サーバ装置３によるＩｏｔクラウトサービス、及び、ストレージ４によるストレージサービス）を流用して構築した簡易なデータプラットフォームにおいて、流用するクラウドサービスのシステムリソース消費を低減することができる。

【0058】

例えば、複数のクラウドサービスを流用して構築した簡易なデータプラットフォームにおいて、データ転送経路上の中間に存在するＩｏＴクラウドサービスに大きな変更を加えず、流用するクラウドサービスのリソース（ＷｅｂＡＰＩコール数）消費を低減できる。

【0059】

具体的には、ＩｏＴクラウドサービスに大きな変更を加える必要がないという効果については、下記により実現される。
・データ転送経路上の中間に存在するＩｏＴクラウドサービス（実施形態では、サーバ装置３）には永続化データを保持しない。
・状態情報（リトライの可否）はＩｏＴ Ｇａｔｅｗａｙ（実施形態では、通信制御装置２）に保持する。
・永続なセンサ情報の保持は、クラウドストレージ（実施形態では、ストレージ４）上のＣＳＶファイルに配置する。すなわち、ＩｏＴクラウドサービスは自前のストレージサービスを不要とすることで、クラウド構成を簡易化できる。

【0060】

また、流用するクラウドサービスのリソース（ＷｅｂＡＰＩコール数）消費を低減できる効果は下記により実現される。
・クラウドストレージ（実施形態では、ストレージ４）上のファイルの書き込み不可を検出（例えば、書き込み失敗イベント）して、その結果（失敗の可否）をＩｏＴ Ｇａｔｅｗａｙ（実施形態では、通信制御装置２）にて保持する。
・ＩｏＴ ＧａｔｅｗａｙからＩｏＴクラウドサービスへのセンサ情報送信をシリアライズする。これにより、無駄なセンサ情報送信のトライを減らす。また、リトライ間隔を調整することで、無駄なＷｅｂＡＰＩコールを低減する。

【0061】

本実施形態の通信制御装置２、サーバ装置３及び端末５で実行されるプログラムは、例えばインストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

【0062】

また例えば、本実施形態の通信制御装置２、サーバ装置３及び端末５で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態の通信制御装置２、サーバ装置３及び端末５で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。

【0063】

また例えば、本実施形態の通信制御装置２、サーバ装置３及び端末５を、ＲＯＭ等に予め組み込んで提供するように構成してもよい。また例えば、本実施形態の通信制御装置２、サーバ装置３及び端末５で実行されるプログラムは、ＲＯＭ等に予め組み込まれて提供されてもよい。

【符号の説明】

【0064】

１ センサ
２ 通信制御装置
３ サーバ装置
４ ストレージ
５ 端末
２１ デバイス制御部
２２ 受信部
２３ バッファ
２４ 記憶部
２５ 送信タイミング制御部
２６ タイマー
２７ 送信部
３１ 認証部
３２ ワークフロー部

【先行技術文献】

【特許文献】

【0065】

【特許文献1】特開２０１６－１５２００７号公報

【図1】

【図2】

【図3】

【図4】

【図5】