図面 (/)

技術 情報処理システム、情報処理装置、サーバ装置、情報処理システムの制御方法、及びプログラム

出願人 キヤノン株式会社
発明者 小林真琴
出願日 2016年2月18日 (4年9ヶ月経過) 出願番号 2016-029189
公開日 2017年8月24日 (3年2ヶ月経過) 公開番号 2017-146849
状態 特許登録済
技術分野 記憶装置の機密保護 オンライン・システムの機密保護
主要キーワード 数字付き デバイス関連情報 NBB 対応モジュール ユーザー個人情報 デバイスステータス情報 JIT 個人情報部分
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年8月24日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (8)

課題

IoTサービスを提供するクラウド上のサーバー個人情報集積せず、IoTデバイス側セキュアに保持された個人情報を利用することができる情報処理システムを提供する

解決手段

WebAPIサーバ300(サーバ装置)から個人情報を有するIOT200(情報処理装置)に対してサービスを提供する情報処理システムであって、サーバ装置は、情報処理装置からの依頼に応じて、アクセストークン発行する発行手段と、情報処理装置からサービス提供依頼を受けて、アクセストークンを認証する認証手段と、アクセストークンが認証された場合、情報処理装置に対して個人情報を利用する命令を送信する送信手段とを備える。情報処理装置は、サーバ装置に対して登録を依頼する登録依頼手段と、発行されたアクセストークンを利用して、サーバ装置にサービス提供依頼をする提供依頼手段と、命令に従って、個人情報を利用する利用手段とを備える。

概要

背景

近年IoT(Internet of Things)が注目されているが、インターネット通信するIoTデバイスが増えるにつれ、IoTにサービスを提供するクラウド上のサーバー個人情報を利用する機会が増えている。そのため、クラウド上のIoTにサービスを提供するサーバーについては、個人情報の流出防止が重要になる。そこで、特許文献1には、機密性の高いデータをデータ処理サービス側サーバー上へ置かなくてよく、高いデータセキュリティを確保することを目的とするシステムが提案されている。

概要

IoTにサービスを提供するクラウド上のサーバーに個人情報を集積せず、IoTデバイス側セキュアに保持された個人情報を利用することができる情報処理システムを提供するWebAPIサーバ300(サーバ装置)から個人情報を有するIOT200(情報処理装置)に対してサービスを提供する情報処理システムであって、サーバ装置は、情報処理装置からの依頼に応じて、アクセストークン発行する発行手段と、情報処理装置からサービス提供依頼を受けて、アクセストークンを認証する認証手段と、アクセストークンが認証された場合、情報処理装置に対して個人情報を利用する命令を送信する送信手段とを備える。情報処理装置は、サーバ装置に対して登録を依頼する登録依頼手段と、発行されたアクセストークンを利用して、サーバ装置にサービス提供依頼をする提供依頼手段と、命令に従って、個人情報を利用する利用手段とを備える。

目的

近年IoT(Internet of Things)が注目されているが、インターネットと通信するIoTデバイスが増えるにつれ、IoTにサービスを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ウェブサービスを提供するサーバ装置から個人情報を有する情報処理装置に対して前記サービスを提供する情報処理システムであって、前記サーバ装置は、前記情報処理装置にて管理されている個人情報を利用する前記ウェブサービスを提供する提供手段と、前記情報処理装置からの依頼に応じて、アクセストークン発行する発行手段と、前記情報処理装置からサービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証手段と、前記認証手段により前記アクセストークンが認証された場合、前記情報処理装置に対し前記提供手段による前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令を送信する送信手段と、を備え、前記情報処理装置は、前記個人情報を管理する管理手段と、前記サーバ装置に対して前記情報処理装置の登録を依頼する登録依頼手段と、前記発行手段により発行された前記アクセストークンを利用して、前記サーバ装置に対して前記サービス提供依頼を送信する提供依頼手段と、前記サーバ装置の送信手段から送信された前記命令に従い前記管理手段にて管理される前記個人情報を参照し、前記命令に従い参照した前記個人情報を用いて特定の処理を実行する処理手段と、を備えることを特徴とする情報処理システム。

請求項2

前記認証手段が、前記提供依頼手段からの前記アクセストークンが前記発行手段で発行したアクセストークンであると判定した場合、前記送信手段は、前記命令を前記情報処理装置に対して送信することを特徴とする請求項1に記載の情報処理システム。

請求項3

前記認証手段は、前記提供依頼手段からの前記アクセストークンが前記発行手段で発行したアクセストークンでないと判定した場合、前記情報処理装置にエラーを送信し、前記処理手段は、前記認証手段によりエラーが送信された場合、前記個人情報を用いて前記特定の処理を実行しないことを特徴とする請求項1または2に記載の情報処理システム。

請求項4

前記送信手段が送信する命令にはメール送信処理に関する命令が含まれ、前記処理手段は、前記命令に含まれるメールテンプレート所定位置に対し、前記参照した前記個人情報を設定し電子メールを作成し、前記作成した電子メールを送信することを特徴とする請求項1に記載の情報処理システム。

請求項5

前記処理手段は、前記命令に含まれるメールテンプレートの宛先に対し、前記参照した前記個人情報の内のメールアドレスを設定し電子メールを作成し、前記作成した電子メールを送信することを特徴とする請求項に記載の情報処理システム。

請求項6

前記送信手段が送信する命令には個人情報編集処理に関する命令を含み、前記処理手段は、前記管理手段で管理される個人情報を編集することを特徴とする請求項に記載の情報処理システム。

請求項7

前記処理手段は、前記個人情報編集処理に関する命令に従い、前記管理手段で管理される個人情報の作成、更新、または変更を行うことを特徴とする請求項6に記載の情報処理システム。

請求項8

前記命令には前記個人情報を利用するためのアクセス権限が含まれ、前記利用手段は、前記アクセス権限で指定された権限に従って前記個人情報を利用することを特徴とする請求項1〜7のいずれか1項に記載の情報処理システム。

請求項9

前記アクセス権限には、少なくとも個人情報の作成権限、読み取り権限更新権限、および削除権限のいずれかが含まれることを特徴とする請求項8に記載の情報処理システム。

請求項10

サーバ装置からウェブサービスの提供を受ける、個人情報を有する情報処理装置であって、前記個人情報を管理する管理手段と、前記サーバ装置に対して前記情報処理装置の登録を依頼する登録依頼手段と、前記登録依頼手段による登録依頼を受けて前記サーバ装置から発行されたアクセストークンを利用して、前記サーバ装置に対してサービス提供依頼を送信する提供依頼手段と、前記情報処理装置からのサービス提供依頼を受けて、前記サーバ装置で前記アクセストークンが認証された場合に、前記サーバ装置から送信される、前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令に従って、前記管理手段にて管理される前記個人情報を参照し、前記命令に従い参照した前記個人情報を用いて特定の処理を実行する処理手段と、を備えることを特徴とする情報処理装置。

請求項11

個人情報を有する情報処理装置に対して、ウェブサービスを提供するサーバ装置であって、前記情報処理装置にて管理されている個人情報を利用する前記ウェブサービスを提供する提供手段と、前記情報処理装置からの前記情報処理装置の登録依頼に応じて、アクセストークンを発行する発行手段と、前記情報処理装置から前記アクセストークンを用いたサービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証手段と、前記認証手段により前記アクセストークンが認証された場合、前記情報処理装置に対し前記提供手段による前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令を送信する送信手段と、を備えることを特徴とするサーバ装置。

請求項12

ウェブサービスを提供するサーバ装置から個人情報を有する情報処理装置に対して前記サービスを提供する情報処理方法であって、前記情報処理装置から前記サーバ装置に対して、前記情報処理装置の登録を依頼する登録依頼工程と、前記情報処理からの依頼に応じて、アクセストークンを、前記情報処理装置に対して発行する発行工程と、前記登録工程で発行された前記アクセストークンを利用して、前記情報処理装置から前記サーバ装置に対して前記サービス提供依頼を送信する提供依頼工程と、前記情報処理装置からサービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証工程と、前記認証工程で前記アクセストークンが認証された場合、前記サーバ装置から前記情報処理装置に対し前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令を送信する送信工程と、前記送信工程で送信された前記命令に従って、前記情報処理装置で管理されている前記個人情報を参照し、前記命令に従い参照した前記個人情報を用いて特定の処理を実行する処理工程と、を有することを特徴とする情報処理方法。

請求項13

請求項10に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム

請求項14

請求項11に記載のサーバ装置の各手段としてコンピュータを機能させるためのプログラム。

技術分野

0001

本発明は、情報処理システム情報処理装置サーバ装置、情報処理システムの制御方法、及びプログラムに関する。特に、IoTデバイスからのRESサービス呼び出しの際の個人情報保護方法に関する。

背景技術

0002

近年IoT(Internet of Things)が注目されているが、インターネット通信するIoTデバイスが増えるにつれ、IoTにサービスを提供するクラウド上のサーバー個人情報を利用する機会が増えている。そのため、クラウド上のIoTにサービスを提供するサーバーについては、個人情報の流出防止が重要になる。そこで、特許文献1には、機密性の高いデータをデータ処理サービス側サーバー上へ置かなくてよく、高いデータセキュリティを確保することを目的とするシステムが提案されている。

先行技術

0003

特開2005−352634号公報

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

0004

IoTにサービスを提供する場合の個人情報漏洩リスクは、そもそもIoTにサービスを提供するサーバー側に個人情報を集積することに起因する。例えば、RESTAPI実行の結果個人情報を利用する場合、個人情報(メールアドレスユーザー名等)を、サービス側に保持する必要がある。すなわち、サービス側がIoTデバイスのREST API実行の結果ユーザーにメール送信する場合など、サービス側に個人情報を登録しておく必要がある。その際、サービス側に個人情報を登録するためには、ネットワークを介して個人情報をやり取りしなければならない。

0005

この場合、サービス側での個人情報の保持は、サーバーへの悪意ある攻撃などにより、情報漏洩のリスクがある。しかしながら、メール送信機能を有するIoTデバイスであれば、サービス側からの要請により、自身の持つ情報を元にIoTデバイスからメール送信することができる。なお、この場合は、メールアドレスをサービス側に持つ必要はない。例えば、ユースケースとしては、ブラウザー表示装置を持たないIoTデバイスのRESTAPI呼び出しや、IoTデバイスの定期的なジョブ実行に伴うREST API呼び出し(操作者がデバイスの近くにいない場合)などが挙げられる。

0006

さらに、公共の場にあるIoT端末内の個人情報の扱いをセキュアにしたい場合、例えば、オフィスや公共の場にあるデバイス内の個人情報のアクセス(追加、編集、参照、消去)に際しては、何等かの認証、検証が必要となる。その際、外部端末から編集可能項目を参照し、編集項目の(追加、編集、参照、消去)を行うが、クラウドサービスポリシーに従って編集項目を制御したい場合、デバイスのみの認証では編集項目の制御ができない。

0007

本発明は、上記課題を鑑みて、IoTにサービスを提供するクラウド上のサーバー(サーバ装置)に個人情報を集積せず、IoTデバイス(情報処理装置)側にセキュアに保持された個人情報を利用することができる情報処理システムを提供することを目的とする。

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

0008

上記課題を解決するために、本発明の情報処理システムは、ウェブサービスを提供するサーバ装置から個人情報を有する情報処理装置に対して前記サービスを提供する情報処理システムであって、前記サーバ装置は、前記情報処理装置からの依頼に応じて、アクセストークン発行する発行手段と、前記情報処理装置からサービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証手段と、前記認証手段により前記アクセストークン認証された場合、前記情報処理装置に対して、前記個人情報を利用する命令を送信する送信手段と、を備え、前記情報処理装置は、前記サーバ装置に対して前記情報処理装置の登録を依頼する登録依頼手段と、前記発行手段により発行された前記アクセストークンを利用して、前記サーバ装置に対して前記サービス提供依頼をする提供依頼手段と、前記サーバ装置の送信手段から送信された命令に従って、前記個人情報を利用する利用手段と、を備えることを特徴とする。

発明の効果

0009

本発明によれば、IoTにサービスを提供するクラウド上のサーバーに個人情報を集積せず、IoTデバイス側にセキュアに保持された個人情報を利用することができる情報処理システムを提供することができる。従って、IoTにサービスを提供するクラウド上のサーバーにそもそも個人情報を集積せず、IoTデバイス側にセキュアに保持された個人情報を利用する。これにより、従来のRESTAPIサービスと同等の機能をユーザーに提供するようなREST APIサービスを実現することができる。

図面の簡単な説明

0010

本発明の一実施形態に係るシステム構成図である。
各装置のハードウェア構成図である。
各装置のモジュール構成図である。
WebAPIサーバーへのIoTデバイスの登録シーケンス図である。
IoTデバイスのメール送信処理シーケンス図である。
個人情報アクセス要求シーケンス図である。
IoTデバイスの個人情報編集処理のシーケンス図である。

実施例

0011

以下、本発明を実施するための最良の形態について図面などを参照して説明する。

0012

(第1実施形態)
本実施形態では、インターネット上でRESTAPIによりウェブサービスを提供するWebAPIサーバーにIoTデバイスを登録し、その登録結果をIoTデバイスのユーザーに電子メールを用いて通知するようなサービスを想定している。また、REST APIサーバーがREST APIの処理結果と共にIoTデバイスの個人情報を利用するような、Web APIサーバーによる、IoTデバイス内のセキュアストレージ内の個人情報を編集可能にするようなサービスを想定している。なお、本実施形態に係るWeb APIサーバーが提供するサービスは、これに限定することなく、様々なサービスを実装するWeb APIサーバー全てに適用可能である。

0013

本実施形態では、RESTAPI(ウェブサービス)実行の結果ユーザーの個人情報を利用するようなREST API実行において、インターネット上のWebAPIサーバー側に個人情報を置かない。これにより、サーバー側の情報管理不備による漏洩、個人情報がWeb APIサーバー、IoTデバイス間に流れる際のスキミング、Man in the mIDdle攻撃等を回避する。また、IoTデバイス内の個人情報は、TPMなどの耐タンパー性を有するハードウェア等により、十分に保護されるものとする。なお、IoTデバイスの個人情報を利用するようなREST APIサービスは、IoTデバイスの登録結果通知サービスに限られるものではない。さらに、本実施形態における権限移譲ではOAuthの仕組みを利用する。OAuthでは、ユーザーから移譲された権限の証明するための情報として、トークンと呼ばれる情報を利用する。

0014

[IoTデバイスがメール送信を伴うRESTAPI呼び出しを行う場合]
本実施形態に係るRESTAPIサービスシステム(情報処理システム)は、図1に示すような構成のネットワーク上に実現される。REST APIサービスシステムは、WAN100と、LAN101と、LAN102と、クライアントIoTデバイス200と、WebAPIサーバー300と、IoTデバイス設定用PC400と、Web APIサーバー設定用PC500を含む。WAN100は、Wide Area Networkであり、World Wide Web(WWW)システムが構築されている。LAN101およびLAN102は、各構成要素を接続するLocal Area Networkである。

0015

クライアントIoTデバイス200は、LAN101に存在するデバイスであり、ユーザーが操作、あるいは自律的に動作するIoTデバイスである。IoTデバイスには、Webブラウザーや、WebAPIを呼び出す専用クライアントアプリケーションや、セキュアに個人情報を保存するストレージや、RSA暗号演算、RSA鍵ペア公開鍵秘密鍵)の生成やSHA−1ハッシュ演算などの機能を有する。また、チップ内で暗号化・復号デジタル署名の生成・検証、プラットフォーム完全性検証を行うことができるTPM(業界団体TCG(Trusted Computing Group)が仕様策定)チップが存在する。ユーザーは、Webブラウザーや専用アプリケーションを用いて、WebAPIサーバー300にアクセスし、さらにセキュアストレージ内の個人情報を用いてWeb APIを利用する。IoTデバイス設定用PC400は、クライアントIoTデバイス200と同様にLAN101に存在するPCであり、クライアントIoTデバイス200内の個人情報や、その編集要求について設定を行う。

0016

WebAPIサーバー(サーバ装置)300は、LAN102に存在するサーバーであり、クライアントIoTデバイス200からのWebAPIリクエスト(サービス提供依頼)に応じて、各種サービス提供を行う。例えば、各種サービスは、印刷サービス帳票サービスといったサービスである。Web APIサーバー設定用PC500は、Web APIサーバー300と同様にLAN102に存在するPCであり、Web APIサーバー300内の個人情報に関わるパラメーターを設定する。

0017

また、クライアントIOTデバイス200、WebAPIサーバー300は、それぞれWANネットワーク100およびLAN101、LAN102を介して接続されている。なお、クライアントIOTデバイス200およびそれぞれのサービスは、それぞれ個別のLAN上に構成されていてもよいし同一のLAN上に構成されていてもよい。また、同一のPC上に構成されていてもよい。

0018

図2は、本実施形態に係るクライアントIOTデバイス200のハードウェア構成を示すブロック図である。なお、WebAPIサーバー300のサーバーコンピューター、IoTデバイス設定用PC400、Web APIサーバー設定用PC500の構成も同様である。図2に示されるハードウェアブロック図は、一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のクライアントIOTデバイス200およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。

0019

図2において、CPU201は、ROM203のプログラム用ROMに記憶された、または外部メモリ211からRAM202にロードされたOSやアプリケーション等のプログラムを実行する。ここで、OSとは、コンピュータ上で稼動するオペレーティングシステム略語であり、以下、オペレーティングシステムのことをOSと呼ぶ。後述する各フローチャートの処理は、このプログラムの実行により実現できる。RAM202は、CPU201の主メモリワークエリア等として機能する。本実施形態では、ROM203は、フォントROM、プログラムROM、データROMを含むが、これに限定せず、まとめて1つのROMとしてもよく、他の機能別にROMを含んでもよい。キーボードコントローラKBC)205は、キーボード(KB)209や不図示のポインティングデバイスからのキー入力を制御する。CRTコントローラ(CRTC)206は、CRTディスプレイ210の表示を制御する。ディスクコントローラ(DKC)207は、各種データを記憶するハードディスク(HD)やフロッピー(登録商標ディスクFD等外メモリ211におけるデータアクセスを制御する。NC212は、ネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。なお、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はCPU201であり、ソフトウェア上の主体は、外部メモリ211にインストールされたアプリケーションプログラムである。各構成要素は、バス204によりそれぞれ通信可能に接続される。

0020

図3は、本実施形態に係る、クライアントIOTデバイス200、WebAPIサーバー300の、それぞれのモジュール構成を示す図である。クライアントIOTデバイス200は、CPU201がROM203または外部メモリ211に記憶されたOSを実行することで各アプリケーションを制御する。OS210は、一般的には、リアルタイムOSが使用されるが、昨今ではLinux(登録商標)等の汎用OSが使用される。クライアントIOTデバイス200は、WWWを利用するためのユーザーエージェントであるRESTクライアントモジュール220を備える。また、IoTデバイス200は、自身の中にセキュアDBモジュール230を有する。セキュアDBモジュール230は、業界団体Trusted Computing Group(TCG)が標準仕様を策定するTPMチップと、TPMチップに格納された暗号鍵情報で暗号化した個人情報データベースから構成される。

0021

TPMチップは、IoTデバイス230に装着され、セキュリティー関連の処理機能を実装したLSIチップである。セキュリティー関連の処理機能とは、具体的には、RSA暗号などのエンコードデコード機能、公開鍵、暗号鍵の鍵ペアの生成、SHA1などのハッシュ値計算、デジタル署名の生成、検証などの機能を指す。また、内蔵する不揮発性メモリに生成した値を安全に格納、管理する機能も有する。また、TPMチップは、耐タンパー性を有し、内部を解析して情報を読みだそうとすると物理的に破損して読み出しを不可能にする機能も有する。セキュアDBモジュール230は、TPMチップ内の暗号鍵を用いて後述する個人情報を保持することができる。

0022

IoTデバイス200は、後述のクライアント登録シーケンスを用いて後述のWebAPIサーバー300に自身をデバイス登録するためのクライアント登録依頼モジュール260を有する。メール送信モジュール240は、後述するデバイスステータス情報送信依頼RESTAPI処理の結果、IoTデバイス200のセキュアDBモジュール230内に存在するメールアドレスなどの個人情報を用いて機能するモジュールである。該メール送信モジュール240は、電子メール送信プロトコルとしてSMTPを用いるSMTPクライアント機能を有し、また送信先SMTPサーバーは、予め設定されているものとする。なお、ユーザーが送信先となるSMTPサーバーの設定を変更することは適宜可能である。個人情報編集モジュール250は、後述する個人情報編集依頼REST API処理の結果、IoTデバイス200のセキュアDBモジュール230内に存在する個人情報を処理するモジュールである。

0023

本実施形態では、2つのWebAPIサーバー対応モジュールであるメール送信モジュール240と個人情報編集モジュール250をIoTデバイス200が有する。しかしながら、前述の通り、様々なWebAPIに対応可能であるためIoTデバイス200が備えるモジュールは、これらに限定されない。

0024

WebAPIサーバー300は、CPU201がROM203、または外部メモリ211に記憶されたOSを実行する事で各アプリケーションを制御する。OS310は、一般的にはLinux(登録商標)等の汎用OSであってよい。また、Web APIサーバー300は、RESTサーバーモジュール320を有する。そして、RESTサーバーモジュール320は、IoTデバイス200のRESTクライアントモジュール220からのREST要求を受信し、その要求を処理した上で後述するJSON形式のRESTレスポンスを返す機能を有する。また、Web APIサーバー300は、認証トークンの管理、検証を行う認証モジュール330と、デバイス登録データ、トークンデータを管理、保持するDBモジュール340とを有する。Web APIサーバー300のクライアント登録モジュール350は、IoTデバイス200のクライアント登録依頼モジュール260からの要求を受ける。そして、Web APIサーバー300上のDBモジュール340にIoTデバイスのデバイスIDなどのIoTデバイス情報を登録するクライアント登録機能を有する。

0025

[デバイス登録]
図4は、本実施形態に係る、WebAPIサーバー300へのIoTデバイス200の登録のシーケンスを示す図である。本シーケンスは、IoTデバイス200のクライアント登録依頼モジュール260がクライアント登録依頼を行うことで開始される。本実施形態では、Web APIサーバー300のRESTエンドポイントのURLは、IoTデバイス200のRESTクライアントモジュール220が保持している。しかしながら、これに限定することなく、IoTデバイス200内のセキュアDBモジュール230、外部メモリ211などに保持してもよく、外部入力可能であれば、外部から入力してもよい。ここで、表1を用いて、IoTデバイス200のセキュアDBモジュール230内に存在するデバイス関連情報テーブルについて説明する。

0026

表1は、デバイス関連情報テーブルであり、DeviceID、TenantID、Public_Key、Private_Key、Tokenから構成される。DeviceIDは、IoTデバイス200の工場出荷時などに予め決められたデバイスIDを格納する。TenantIDは、予め設定されたデバイスの所属するテナントを格納する。Public_Key、Private_Keyは、後述するIoTデバイス200で生成する2048bit RSAの公開鍵、秘密鍵をそれぞれ格納する。Tokenは、後述するWEBAPIサーバー300から取得するアクセストークンを格納する。なお、TenantIDは、IoTデバイス200の外部から入力可能な構成にしてもよい。

0027

クライアント登録依頼モジュール260は、WebAPIサーバー300でIoTデバイス200の確認を行うために、TPMチップを用いて2048bit RSAの公開鍵、秘密鍵を生成する。そして、セキュアDBモジュール230のデバイス関連情報テーブル(表1)のPublic_Key、Private_Keyに格納する(ステップS401)。なお、これらの鍵の鍵長アルゴリズムについては、十分に安全性が確認されていれば、2048bit/RSA以外の他のものでも良い。

0028

次に、クライアント登録モジュール260は、セキュアDBモジュール230のデバイス関連情報テーブル(表1)からデバイスID(Device_A)とテナントID(101AA)と公開鍵(xxxxx)を引数に指定する。そして、WEBAPIサーバー300のデバイス登録RESTAPIを呼び出すためにRESTクライアントモジュール220を使用する(ステップS402)。クライアント登録依頼モジュール260からRESTAPI呼び出しを依頼されたRESTクライアントモジュール220は、引数を指定して、WEB APIサーバー300のクライアント登録APIを呼び出す(ステップS403)。

0029

IoTデバイス200からクライアント登録APIを呼び出されたWEBAPIサーバー300は、RESTサーバーモジュール320がクライアント登録APIを受信する。本実施形態のREST APIは、HTTPまたはHTTPSプロトコルを用い、JSON形式のメッセージで表される。具体的なクライアント登録APIを以下に示す。
[クライアント登録API]
POST /client_registration HTTP/1.1
Host: restapiserver.example.com
Content-Type: application/json;charset=UTF-8

{
"device_id":"Device_A",
"tenant_id":"101AA",
"public_key":"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq3DajwoRjpfF+aHtzygzNIvKEqw8HfUd1eGcLzJi4cCJITlY64IlNQXzDEev5FyylMIQT0xANBBcE1lF/rzRSf9JzE4KAjInz7UmKxedRBSYdiix/jeB1TcJ9e3KHHIOnwGxJLw1X1op3Lbl5sYPvNOp7OAqvk+ZueZocCzoZ+7VIb/vCt5I+jm8Tim8tPtDyBSPSwVTCVUVzWBnx2e4TXjHMfB6mU4eoZ4HRRvaGofeBc7sIIEf1zGRuds7kGgdpZBWEYD5lJ31TM5y9aIhEOPtuxRn6X0IVqJpwOWUTMlFX6WhNZ0SECkrXAvUkq8mooyCk+jcLRT+DPt9DvmXAwIDAQAB"
}

0030

上記クライアント登録APIを受信したWEBAPIサーバー300のRESTサーバーモジュール320は、クライアント登録APIの引数をデバイス登録テーブル(表2)に保存する(ステップS404)。すなわち、引数であるデバイスID、テナントID、IoTデバイス200で生成した公開鍵を、デバイス登録データ、トークンデータを、管理、保持するDBモジュール340のデバイス登録テーブル(表2)に保存する。ここで、表2を用いて、WEB APIサーバー300のDBモジュール340内に存在するデバイス登録テーブルについて説明する。

0031

デバイス登録テーブル(表2)は、TenantID、DeviceID、Public_Key、Token、nonceから構成される。TenantIDは、予め設定されたデバイスの所属するテナントを格納する。DeviceIDは、クライアント登録APIの引数で指定され、登録されたクライアントを示すデバイスIDを格納する。Public_Keyは、同じくクライアント登録APIの引数で指定され、登録されたクライアントで生成された公開鍵を格納する。Tokenは、後述するデバイス登録の際に発行するトークンを格納する。nonceは、後述するクライアントであるIoTデバイス200の個人情報アクセス要求に対する応答正当であることを保障するための仕組みに用いるnonce値を格納する。なお、TenantIDは、WEBAPIサーバー300の外部から入力可能な構成であってもよい。

0032

WEBAPIサーバー300のRESTサーバーモジュール320は、デバイス登録テーブル(表2)に対し、受信したRESTAPIの引数のテナントID(“101AA”)の存在を確認する。そして、テナントIDが存在していれば、同カラムのDeviceID格納領域に、同じくREST APIの引数のデバイスID(“Device_A”)を格納する(ステップS404)。デバイスID登録が成功した場合、RESTサーバーモジュール320は、クライアント登録APIをコールしたIoTデバイス200の以降のサービス呼び出しが正当であるか否かを検証するために用いるアクセストークンを発行する。そして、デバイス登録テーブル(表2)の、要求元TenantID、DeviceIDと同じカラムのToken領域に発行したアクセストークンを格納する(ステップS404)。

0033

デバイス登録テーブル(表2)へのデバイスID、公開鍵の格納、アクセストークン発行と格納が正常に終了した際にはRESTサーバーモジュール320へ正常に終了した旨を伝える(ステップS405)。そして、RESTサーバーモジュール320は、アクセストークンを、クライアント登録APIの呼び出し元であるIoTデバイス200に対してREST API応答として返却する(ステップS406)。このとき、HTTPあるいはHTTPSプロトコルを用いて、JSONフォーマットでREST API応答として返却する。具体的なクライアント登録REST API応答の内容を以下に示す。
[クライアント登録REST API応答]
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
"token":"5d9556d8-5035-4a67-abd3-13bd13c7cdf0@1000000AAxI"
}

0034

WEBAPIサーバー300から、クライアント登録API応答を受信したRESTクライアントモジュール220は、クライアント登録API応答の引数であるトークンをデバイス関連情報テーブル(表1)のTokenに保存する(ステップS407)。すなわち、トークン("5d9556d8-5035-4a67-abd3-13bd13c7cdf0@1000000AAxI")をセキュアDBモジュール230内に存在するデバイス関連情報テーブル(表1)のToken格納領域に保存する。

0035

[メール送信を伴うRESTAPI処理]
図5は、本実施形態に係る、個人情報を用いた特定の処理として、IoTデバイス200のメール送信処理のシーケンスを示す図である。本シーケンスは、デバイス登録処理終了後、ユーザーがIoTデバイス200の、WebAPIサーバー300との通信を開始するためのメール送信ボタンを押下する。そして、IoTデバイス200のRESTクライアントモジュール220が、Web APIサーバー300のRESTサーバーモジュール320のREST APIを呼び出すことで開始される。

0036

本実施形態では、WebAPIサーバー300のRESTエンドポイントのURLは、IoTデバイス200のRESTクライアントモジュール220が保持している。しかしながら、IoTデバイス200内のセキュアDBモジュール230、外部メモリ211などに保持してもよく、外部入力可能であれば外部から入力してもよい。

0037

メール送信を行うIoTデバイス200のRESTクライアントモジュール220は、デバイス関連情報テーブル(表1)を利用して、RESTサーバーモジュール320に実装された、メール送信RESTAPIを呼び出す(ステップS501)。すなわち、セキュアDBモジュール230内に存在するデバイス関連情報テーブル(表1)のDeviceIDと、TenantIDと、デバイス登録で取得したアクセストークンを引数にして、メール送信REST APIを呼び出す。具体的なメール送信REST APIを以下に示す。
[メール送信REST API]
POST /client_statusHTTP/1.1
Host: restapiserver.example.com
Content-Type: application/json;charset=UTF-8

{
"device_id":"Device_A",
"tenant_id":"101AA",
"token":"5d9556d8-5035-4a67-abd3-13bd13c7cdf0@1000000AAxI"
}

0038

メール送信RESTAPIを受信したWebAPIサーバー300のRESTサーバーモジュール320は、IoTデバイスのRESTAPI呼び出しを、認証トークンの管理、検証を行う認証モジュール330を用いて検証する。すなわち、受信したREST API呼び出しのdevice_id、tenant_id、tokenを認証トークンの管理、検証を行う認証モジュール330に渡す(ステップS502)。本実施形態では、device_idは、“Device_A”であり、tenant_idは、“101AA”である。そして、tokenは、“5d9556d8-5035-4a67-abd3-13bd13c7cdf0@1000000AAxI”である。認証モジュール330は、デバイス登録処理でデバイス登録した、デバイス登録テーブル(表2)のDeviceID、TenantID、Tokenと、渡されたdevice_id、tenant_id、tokenの値を比較する。そして、登録済みのIoTデバイスからのREST API呼び出しかどうか判定する(ステップS503)。この判定が異常であれば、REST API呼び出しに対してエラーを返す。

0039

検証モジュールのアクセストークン検証処理が正常であれば(ステップS503)、RESTサーバーモジュール320は、クライアントステータスを取得し、メール送信のためのメール文面テンプレートと、パラメーターを取得する。表3、表4を用いて、WebAPIサーバー300内に存在する、RESTAPI応答コマンドテーブル、REST API応答コマンドパラメーターテーブルについて説明する。

0040

RESTAPIパラメーターテーブル(表3)は、以下のカラムを有する。すなわち、予め設定されたデバイスの所属するテナントを格納するTenantID、にWebAPIサーバー300のRESTサーバーモジュール320に実装された各々のRESTAPIにより一意に決まるServiceIDを有する。また、後述するServiceIDのREST APIに対応し、該REST APIの応答に付属する、IoTデバイス200が実行するコマンドを示すCommandを有する。以上のカラムがREST APIパラメーターテーブル(表3)に存在する。

0041

RESTAPI応答コマンドパラメーターテーブル(表4)は、以下のカラムを有する。すなわち、表3のCommandに対応するCommand、後述する各Commandに対応するCommandのパラメーターを示すArgumentsを有する。また、IoTデバイス200で実行するCommandに対して該IoTデバイスのどの個人情報を使用するかを示すAuth1、Auth2を有する。さらに、Auth1、Auth2で示されるIoTデバイス上の個人情報に対するアクセス権限を示すPrivilege1、Privilege2を有する。本実施形態では、上述のようにAuthとPrivilegeは、コマンドに応じて複数存在し、各々のカラム名は、Auth1、Auth2…、Privilege1、Privilege2…のような数字付きのカラム名になる。以上のカラムがRESTAPIパラメーターテーブル(表4)に存在する。

0042

なお、表3、表4のTenantID、ServiceID、Command、Arguments、Auth1、Auth2、Privilege1、Privilege2は、WEBAPIサーバー300の外部から入力可能な構成にしてもよい。また、表4のAuth1、Auth2に格納される値は、後述するIoTデバイス200内に存在する個人情報パラメーターの値が入る。表4のPrivilege1、Privilege2には、アクセス権限を示す4つの文字列“C”、“R”、“U”、“D”のいずれか、あるいはそれらの組合せが入る。なお、本実施形態では、文字列は、“C”が作成権限を表し、“R”が読み取り権限を表し、“U”が更新権限を表し、“D”が削除権限を表す。

0043

WebAPIサーバー300のRESTサーバーモジュール320は、DBモジュール340に存在するRESTAPI応答コマンドテーブル(表3)、REST API応答コマンドパラメーターテーブル(表4)を参照する(ステップS504)。そして、メール送信RESTAPI呼び出しで指定されたサービスと、メール送信REST APIのパラメーターに指定されたテナントIDに相当するREST API応答コマンドテーブル(表3)のCommandを取得する。すなわち、メール送信REST API呼び出しで指定されたサービス(client_status)と、メール送信REST APIのパラメーターに指定されたテナントID(“tenant_ID”:“101AA”)に相当するCommandを取得する。さらに、相当するREST API応答コマンドパラメーターテーブル(表4)のCommandに対応するArguments、Auth1、Auth2、Privilege1、Privilege2のカラムの各々を取得する(ステップS505)。本実施形態では、Commandは、“send-mail”、Argumentsは、“Template_A”、Auth1は、“private_admin_mail_address”を参照する。また、Privilege1は、“R”、Auth2は、“private_admin_name”、Privilege2は、“R”を参照する。ここで、Artumentsの“Template_A”は、Web APIサーバー300の外部メモリ211に存在するメール送信のためのメール文面テンプレートを示す。本実施形態における具体的な“Template_A”を以下に示す。
[Template_A]
To: ##${Auth1}##
Cc:
Subject: Device Status Information

Hello, ##${Auth2}##
This is a Status Information & Change Notification.
https://restservice.example.com/device/status

0044

RESTサーバーモジュール320は、上記Command、Argument、Auth1、Privilege1、Auth2、Privilege2を用いて、応答(命令)を作成する。すなわち、メール送信RESTAPIの応答(命令)を作成し、IoTデバイス200に返す(ステップS506)。具体的には、Commandは、“send-mail”を、Argumentは、“Template_A”を、Auth1は、“private_admin_mail_address”を用いる。また、Privilege1は、“R”を、Auth2は、“private_admin_name”を、Privilege2は、“R”を用いる。本実施形態では、Template_Aの##${Auth1}##をAuth1の“private_admin_mail_address”に展開し、##${Auth2}##部分をAuth2の“private_admin_name”に展開する。また、Privilege1の“R”をJSON形式の“private_info”:“private_admin_mail_address”という値にに展開する。さらに、“access_privilege”:{“create”:“NG”,“read”:“OK”,“update”:“NG”,“delete”:“NG”}という値に展開する。そして、Privilege2の“R”を、JSON形式の“private_info”:“private_admin_name”という値にに展開する。さらに、“access_privilege”:{“create”:“NG”,“read”:“OK”,“update”:“NG”,“delete”:“NG”}という値に展開する。具体的な本実施形態のメール送信REST APIの応答を、JSON形式で以下に示す。
[メール送信REST APIの応答]
{
"type": "Program",
"body": [
{
"command": "send-email",
"arguments": {
"to": "##private_admin_mail_address##",
"cc": "",
"subject": "Status Information",
"body": "Hello, ##private_admin_user_name##\r\nThis is a Status Information & Change Notification.\r\nhttps://restservice.example.com/device/status"
},
"auth": [
{
"private_info": "private_admin_mail_address",
"access_privillage": {
"create": "NG",
"read": "OK",
"update": "NG",
"delete": "NG"
}
},
{
"private_info": "private_admin_user_name",
"access_privillage": {
"create": "NG",
"read": "OK",
"update": "NG",
"delete": "NG"
}
}
]
}
}
]
}

0045

WebAPIサーバー300のRESTサーバーモジュール320に実装されたメール送信RESTAPIを呼び出したIoTデバイス200のRESTクライアントモジュール220は、REST APIの応答として上記JSONメッセージを受信する。RESTクライアントモジュール220は、次に受信したREST API応答のJSONメッセージを参照し、メッセージ中の“command”、“argument”、“auth”の値に従った動作を行う。

0046

本実施形態では、RESTAPIコールを行うREST APIクライアント(IoTデバイス200)が、WebAPIサーバー(Web APIサーバー300)からの応答(命令)に含まれるコマンドにより動作する。また、Web APIサーバー300からの応答に含まれる個人情報アクセス権限に従って、自身に内在する個人情報にアクセスしてコマンドを実行する。その際、Web APIサーバー側にRESTクライアントの個人情報が存在しないことが特徴である。

0047

本実施形態では、RESTクライアントモジュール220は、受信したRESTAPI応答のJSONメッセージを参照する。そして、“auth”の“private_info”の“private_admin_mail_address”と、同じく“private_info”の“private_admin_name”を取り出す。さらに、IoTデバイス220のセキュアDBモジュール230に保存される表5に示す個人情報テーブル1を参照する。

0048

個人情報テーブル1(表5)は、以下のカラムを有する。すなわち、個人情報項目を表すprivate_info、メールアドレスを表すmail_address、名前を表すname、ニックネームを表すnicknameカラムである。本実施形態の個人情報テーブル1(表5)においては、個人情報の要素としてメールアドレスと名前とニックネームが存在している。もちろん、RESTAPIの種類に応じてIoTデバイス200のセキュアDBモジュール230で管理される個人情報の要素は、住所位置情報、所属名などであってよい。

0049

本実施形態では、RESTクライアントモジュール220は、セキュアDBモジュール230内の上記個人情報テーブル1(表5)と、受信したRESTAPI応答のJSONメッセージを参照する。そして、WebAPIサーバー300のRESTサーバーモジュールからJSONメッセージ内のパラメーターとして要求された個人情報を、個人情報テーブル1(表5)から取得する。具体的には、JSONメッセージの“auth”の“private_info”の“private_admin_mail_address”として個人情報テーブル1(表5)の対応する値“admin@IoT.example.com”を取得する。また、同じくJSONメッセージの“private_info”の“private_admin_name”として個人情報テーブル1(表5)の対応する値“Administrator”を取得する。その際、IoTデバイス200のRESTクライアントモジュール220は、Web APIサーバー300から受信したJSONメッセージの“private_info”の“access_privilege”に対応する権限のアクセス制限を受ける。

0050

本実施形態では、JSONメッセージの“private_info”の“private_admin_mail_address”と“private_admin_name”の“access_privilege”が “read”:“OK”である。そのため、RESTクライアントモジュール220は、個人情報テーブル1(表5)の“private_admin_mail_address”と“private_admin_name”の情報にアクセスし、読み出す(ステップS507)。

0051

その後、RESTクライアントモジュール220は、セキュアDBモジュール230内の個人情報テーブル1(表5)から取得した項目を用いてJSONメッセージの“arguments”に存在するメール文面テンプレートの個人情報部分を置き換える。つまり、メールテンプレート所定位置に対し、個人情報を設定する。具体的には、“private_admin_mail_adress”項目(“admin@iot.example.com”)と、“private_admin_name”項目(“Administrator”)について個人情報部分を置き換える。“private_admin_mail_adress”項目(宛先)は、個人情報内の“admin@iot.example.com”を設定する。また、“private_admin_name”項目は、“Administrator”を用いる。なお、メール文面テンプレートは、以下のようなメール文面メッセージになる。
[メール文面メッセージ]
To: admin@iot.example.com
Cc:
Subject: Device Status Information

Hello, Administrator
This is a Status Information & Change Notification.
https://restservice.example.com/device/status

0052

RESTクライアントモジュール220は、作成したメール文面メッセージと、受信したRESTAPI応答のJSONメッセージの“command”の値(“send-mail”)に従って、メール送信モジュール240を呼び出す(ステップS508)。IoTデバイス200のメール送信モジュール240は、受け取ったメール文面メッセージに従って、電子メールを送信する(ステップS509)。

0053

IoTにサービスを提供するクラウド上のサーバー(サーバ装置)に個人情報を集積せず、IoTデバイス(情報処理装置)側にセキュアに保持された個人情報を利用することができる情報処理システムを提供することができる。

0054

(第2実施形態)
[IoTデバイスが個人情報編集を伴うRESTAPI呼び出しを行う場合]
本実施形態では、第1実施形態と同様の構成において、IoTデバイス200がセキュアDBモジュール230に存在する個人情報の編集を伴うREST API呼び出しを行う場合について説明する。図7は、本実施形態に係る、個人情報を用いた特定の処理として、IoTデバイス200の個人情報編集処理のシーケンスを示す図である。本シーケンスは、デバイス登録処理終了後、PC400が、IoTデバイス200との通信を開始するための個人情報編集ボタンを押下し、個人情報編集モジュール250に個人情報編集要求を行うことで開始される(ステップS801)。個人情報編集要求について、具体的には以下のような個人情報編集要求メッセージにより行われる。
[個人情報編集要求メッセージ]
{
"type": "Program",
"body": [
{
"command": "edit-user",
"arguments": {
"private_info": "private_user1",
"name": "User2",
"nickname": "User2"
}
}
]
}

0055

上記メッセージは、IoTデバイス200のセキュアDBモジュール230内の個人情報テーブル1(表5)に存在する“private_user1”の“name”と“nickname”を更新するメッセージである。該メッセージを受信したIoTデバイス200の個人情報編集モジュール250は、IoTデバイス200のRESTクライアントモジュール220に対し、個人情報編集許可確認RESTAPIの呼び出しを依頼する(ステップS802)。本実施形態では、セキュアDBモジュール230内の個人情報テーブル1(表5)に存在するような個人情報を、IoTデバイス200と同じLAN102に存在するPC400などから編集する場合を想定している。この場合、WebAPIサーバー300に対してRESTAPI呼び出しを行い、その結果により個人情報を編集する。これは、例えば、IoTデバイス200が公共の場にあり複数のユーザーから使用されるような場合、IoTデバイス200内の個人情報の編集について、Web APIサーバー300側の個人情報編集ポリシーを強制できる、という効果がある。

0056

個人情報編集モジュール250から個人情報編集許可確認RESTAPIの呼び出しを依頼されたRESTクライアントモジュール220は、デバイス登録で取得したアクセストークンを引数にして、REST APIを呼び出す(ステップS803)。具体的には、RESTクライアントモジュール220は、セキュアDBモジュール230内に存在するデバイス関連情報テーブル(表1)のTokenに保存した、アクセストークンを引数に、RESTサーバーモジュール320のREST APIを呼び出す。このREST APIは、RESTクライアントモジュールが、個人情報編集要求メッセージからパラメーターを作成する。

0057

本実施形態では、WebAPIサーバー300のRESTエンドポイントのURLは、IoTデバイス200のRESTクライアントモジュール220が保持している。しかしながら、IoTデバイス200内のセキュアDBモジュール230、外部メモリ211などに保持してもよく、外部入力可能であれば外部から入力してもよい。なお、具体的な個人情報編集許可確認RESTAPIについて以下に示す。
[個人情報編集許可確認REST API]
POST /edit_private_infoHTTP/1.1
Host: restapiserver.example.com
Content-Type: application/json;charset=UTF-8

{
{
"command": "edit-user",
"arguments": {
"private_info": "private_user1",
"arguments": "name", "nickname"
}
},
"device_ID":"Device_A",
"tenant_ID":"101AA",
"token":"5d9556d8-5035-4a67-abd3-13bd13c7cdf0@1000000AAxI"

}

0058

上記の個人情報編集許可確認RESTAPIのパラメーターは、RESTクライアントモジュールが、個人情報編集要求メッセージから作成したものである。個人情報編集要求メッセージの“command”の“edit-user”が、上記の個人情報編集許可確認REST APIの“command”のパラメーターになる。また、個人情報編集要求メッセージの“arguments”の編集対象情報が、個人情報編集許可確認REST APIの“private_info”:“private_user1”のパラメーターになる。すなわち、“arguments”の編集対象情報を表す“private_info”:“private_user1”が、“private_info”:“private_user1”のパラメーターになる。さらに、個人情報編集要求メッセージの“arguments”の編集対象情報項目とその編集内容は、個人情報編集許可確認REST APIにおいては、編集対象情報項目が編集可能かを問い合わせるため、編集内容を除いたパラメーターになる。具体的には、“arguments”の編集対象情報項目とその編集内容を表す“name”:“User2”と“nickname”:“User2”は、編集内容を除いた“name”,“nickname”のパラメーターになる。また、“device_ID”は、セキュアDBモジュール230内に存在するデバイス関連情報テーブル(表1)のDevice_IDに保存しているDeviceIDである。また、“tenant_ID”は、Tenant_IDに保存しているTenantIDであり、“token”は、Tokenに保存した、デバイス登録で取得したアクセストークンである。

0059

個人情報編集許可確認RESTAPIを受信したWebAPIサーバー300のRESTサーバーモジュール320は、IoTデバイスのRESTAPI呼び出しを、認証トークンの管理、検証を行う認証モジュール330を用いて検証する。Web APIサーバーモジュールは、受信したREST API呼び出しのdevice_ID、tenant_ID、tokenを認証トークンの管理、検証を行う認証モジュール330に渡す(ステップS804)。具体的には、device_IDは“Device_A”を、tenant_IDは“101AA”を、tokenは“5d9556d8-5035-4a67-abd3-13bd13c7cdf0@1000000AAxI”を認証モジュール330に渡す。認証モジュール330は、Web APIサーバー300に存在するデバイス登録テーブル(表2)の値と、渡された値を比較し、登録済みのIoTデバイスからのREST API呼び出しかどうか判定する(ステップS805)。すなわち、デバイス登録テーブル(表2)のDeviceID、TenantID、Tokenと、渡されたdevice_ID、tenant_ID、tokenの値を比較する。この判定が異常であれば、REST API呼び出しに対してエラーを返す。

0060

RESTAPI応答コマンドパラメーターテーブル2(表6)は、以下のカラムを有する。つまり、表3のCommandに対応するCommand、各Commandに対応するCommandのパラメーターで、本実施形態のIoTデバイス200のセキュアDBモジュール230に存在する個人情報の編集対象者を示すArgumentsを有する。また、セキュアDBモジュール230に存在する個人情報の編集対象者の情報項目で示されるIoTデバイス上の編集対象の個人情報に対するアクセス権限を示すPrivilege1、Privilege2を有する。本実施形態では、個人情報の編集対象者の情報項目は、Private_info1、Private_info2、Private_info1、Private_info2である。上述のようにPrivate_infoとPrivilegeは、コマンドに応じて複数存在し、各カラム名は、Private_info1、Private_info2…、Privilege1、Privilege2…のような数字付きのカラム名になる。以上のカラムがREST API応答コマンドパラメーターテーブル2(表6)に存在する。なお、表3、表6のTenantID、ServiceID、Command、Arguments、Private_info1、Private_info2、Privilege1、Privilege2は、外部から入力可能な構成にしてもよい。

0061

検証モジュールのアクセストークン検証処理が正常であれば(すなわち、アクセストークンの認証ができた場合)(ステップS805)、RESTサーバーモジュール320に返答する。次に、RESTサーバーモジュール320は、DBモジュール340に存在するRESTAPI応答コマンドテーブル(表3)、REST API応答コマンドパラメーターテーブル2(表6)を参照する(ステップS806)。そして、個人情報編集許可確認RESTAPI呼び出しで指定されたサービス(edit-user)と、REST API応答コマンドテーブル(表3)のCommand(edit-user)を取得する。具体的には、個人情報編集許可確認REST APIのパラメーターに指定されたテナントID(“tenant_ID”:“101AA”)に相当する表3のCommand(edit-user)を取得する。さらに、REST API応答コマンドパラメーターテーブル(表6)のCommandに対応するArguments、Private_info1、Private_info2、Privilege1、Privilege2の各々の値を取得する。すなわち、Command(edit-user)に相当するREST API応答コマンドパラメーターテーブル(表6)のCommand(edit-user)に対応する各々の値を取得する(ステップS807)。本実施形態では、個人情報編集許可確認REST APIで指定されたパラメーターに従い、Commandは、“edit-user”を、Argumentsは、“private_user1”を、Private_info1は、“name”を参照する。また、Privilege1は、“CRU”を、Private_info2は、“nickname”を、Privilege2は、“CRUD”を参照する。

0062

RESTサーバーモジュール320は、Command、Arguments、Private_info1、Privillege1、Private_info2、Privillege2で、個人情報編集許可確認RESTAPIの応答を作成する。そして、IoTデバイス200に返す。すなわち、Command(“edit-user”)、Arguments(“private_user1”)、Private_info1(“name”)を用いる。また、Privillege1(“CRU”)、Private_info2(“nickname”)、Privillege2(“CRUD”)を用いる。本実施形態では、Command(“edit-user”)を“command”:“edit-user”に展開する。さらに、Arguments(“private_user1”)を“arguments”の“private_ID”:“#private_user1#”に展開する。

0063

“#private_user1#”と“#”記号で囲んだのは、IoTデバイス200における個人情報であることを明示するためである。さらに、Private_info1(“name”)を“arguments”:の“param1”:“#name#”に展開する。また、Private_info2(“nickname”)を“arguments”:の“param2”:“#nickname#”に展開する。そして、アクセス権を示すPrivillege1を、“access_privillege”:{“create”:“OK”,“read”:“OK”,“update”:“OK”,“delete”:“NG”}に展開する。さらに、Privillege2を、“access_privillege”:{“create”:“OK”,“read”:“OK”,“update”:“OK”,“delete”:“OK”}に展開する。以上のようにArguments、Private_info1、Privilege1、Private_info2、Privilege2の各値をJSON形式の値に展開する。本実施形態の具体的な個人情報編集許可確認RESTAPIの応答について、JSON形式で以下に示す。
[個人情報編集許可確認REST APIの応答]
{
"type": "Program",
"body": [
{
"command": "edit-user",
"arguments": {
"private_ID": "#private_user1#",
"param1": "#name#",
"access_privillege": {
"create": "OK",
"read": "OK",
"update": "OK",
"delete": "NG"
},
"private_ID": "#private_user1#",
"param2": "#nickname#",
"access_privillege": {
"create": "OK”,
"read": "OK",
"update": "OK",
"delete": "OK"
}
}
}
]
}

0064

RESTサーバーモジュール320に実装されたメール送信RESTAPIを呼び出したIoTデバイス200のRESTクライアントモジュール220は、REST APIの応答として上記JSONメッセージを受信する(ステップS808)。次に、RESTクライアントモジュール220は、受信したREST API応答のJSONメッセージを参照し、メッセージ中の“command”、“arguments”の値に従った動作を行う。

0065

本実施形態では、RESTAPIコールを行うREST APIクライアント(IoTデバイス200)が、WebAPIサーバー(Web APIサーバー300)からの応答に含まれるコマンドにより動作する。さらに、Web APIサーバーからの応答に含まれる個人情報アクセス権限に従って、自身に内在する個人情報にアクセスしてコマンドを実行する。その際、Web APIサーバー側にRESTクライアントの個人情報が存在しない。

0066

また、本実施形態では、RESTクライアントモジュール220は、受信したRESTAPI応答のJSONメッセージを参照し、“command”:“edit-user”に指定された個人情報の編集を行う。すなわち、受信した個人情報編集許可確認REST API応答の“arguments”の“private_ID”、“param1”、“access_privillege”、“param2”、“access_privillege”を取り出す。そして、個人情報編集モジュール250に渡す(ステップS809)。個人情報編集モジュール250は、セキュアDBモジュール230内の個人情報テーブル(表5)を参照する。そして、個人情報編集要求メッセージと、RESTクライアントモジュール220から受け取った個人情報編集許可確認REST API応答を比較して、個人情報編集要求メッセージの内容を検証する。

0067

すなわち、個人情報編集要求メッセージは、セキュアDBモジュール230内の表5の“private_info”の“private_user1”の“name”と“nickname”を変更するような依頼メッセージを示す。すなわち、“name”と“nickname”を各々“User2”、“User2”に変更するような依頼メッセージを示す。また、RESTクライアントモジュール220から受け取った個人情報編集許可確認RESTAPI応答は、“private_ID”に示された“private_info”の値について、“name”の作成、更新、変更が可能である。すなわち、“private_info”の値“private_user1”について、“name”の作成、更新、変更が可能である。同じく、“nickname”の作成、更新、変更、削除が可能であることを示している。そこで、個人情報編集モジュール250は、個人情報編集要求メッセージに従い、表5の“private_info”の“private_user1”の“name”と“nickname”を変更する(ステップS810)。すなわち、“private_user1”の“name”と“nickname”を各々“User2”、“User2”に変更する。

0068

[個人情報アクセスをさらにセキュアにする手段]
次に、個人情報アクセスをさらにセキュアにする手段について述べる。図6は、IoTデバイス200のセキュアDBモジュール230内の個人情報アクセスに際してのRESTAPIの要求元がIoTデバイス200であり、要求先がWebAPIサーバー300であることをより確実にするための手段を示すシーケンス図である。図6のシーケンスは、第1実施形態のステップS501、第2実施形態ステップS803において行われる。

0069

まず、IoTデバイス200は、個人情報アクセスを伴うRESTAPI要求を行う前に、WebAPIサーバー300に対して個人情報アクセス要求を送信する(ステップS701)。本要求は、デバイス登録で取得したアクセストークンを引数にして行われる。個人情報アクセス要求を受信したWeb APIサーバー300は、取得したアクセストークンに対して、使い捨てのランダムな値であるnonce値を生成する。そして、DBモジュール340内に存在するデバイス登録テーブル(表2)のトークンと同じカラムのnonce領域にnonce値文字列として保存する(ステップS702)。具体的には、nonce値文字列としてUUIDで“7f5d949c-0318-4e4c-84f1-4d569d674ab5”を生成する。そして、生成したnonce値文字列をIoTデバイス200に返却する(ステップS703)。

0070

WebAPIサーバー300からnonce値文字列を返却されたIoTデバイス200は、デバイス関連情報テーブル(表1)のDeviceID文字列を取得する。そして、nonce値文字列と結合してSHA1ハッシュアルゴリズムを用いてハッシュ値1を求める(ステップS704)。具体的には、本実施形態では、nonce値文字列(“7f5d949c-0318-4e4c-84f1-4d569d674ab5”)と、DeviceID文字列(“Device_A”)を結合する。結合して得た値をSHA1ハッシュ化して得た値がハッシュ値1に相当する。IoTデバイス200は、ハッシュ値1をWeb APIサーバーに送信する(ステップS705)。

0071

ハッシュ値1を受信したWebAPIサーバー300は、DBモジュール340内に存在するデバイス登録テーブル(表2)のトークンと同じカラムのDeviceID文字列とnonce文字列を取得する。そして、DeviceID文字列とnonce文字列を結合してSHA1ハッシュアルゴリズムを用いてハッシュ値2を求める。具体的には、本実施形態では、nonce値文字列(“7f5d949c-0318-4e4c-84f1-4d569d674ab5”)と、DeviceID文字列(“Device_A”)を結合する。そして、ハッシュ値1とハッシュ値2を比較して、ハッシュ値比較を行う。もし、ハッシュ値比較の結果が同じであれば、個人情報アクセス要求OKの応答を行う(ステップS707)。そして、個人情報へアクセスを行う(ステップS708)。もし、ハッシュ値比較の結果が不一致であれば、個人情報アクセス要求に対してエラーの応答を行う。

0072

以上、本実施形態によれば、RESTAPI実行の結果ユーザーの個人情報を利用するようなREST API実行において、サーバー側に個人情報を置かないことで、サーバー側の情報管理不備、情報漏洩等を解消することができる。また、個人情報をみだりにネットワークに流さないことで、Man in the mIDdleなどの攻撃にも対処できる。また、クライアントデバイス側の個人情報は(TPMなどにより)十分に保護される。さらに、クラウド側は、ユーザー個人情報紐付かない処理を行い、デバイス側は、ユーザー個人情報に紐付く処理を行う。この2つをオーバーレイしてREST API処理を行うことで、サーバー側に個人情報を置くことなく、サーバー側情報と個人情報を合わせたサービスを行うことができる。

0073

(その他の実施例)
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。

0074

また、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ