JP2017146849A

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

Info

Publication number: JP2017146849A
Application number: JP2016029189A
Authority: JP
Inventors: 小林　真琴; Makoto Kobayashi; 真琴小林
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-02-18
Filing date: 2016-02-18
Publication date: 2017-08-24
Anticipated expiration: 2036-02-18
Also published as: JP6736305B2; US20180322311A1; US10902107B2; WO2017141618A1

Abstract

【課題】ＩｏＴにサービスを提供するクラウド上のサーバーに個人情報を集積せず、ＩｏＴデバイス側にセキュアに保持された個人情報を利用することができる情報処理システムを提供する【解決手段】ＷｅｂＡＰＩサーバ３００（サーバ装置)から個人情報を有するＩＯＴ２００（情報処理装置）に対してサービスを提供する情報処理システムであって、サーバ装置は、情報処理装置からの依頼に応じて、アクセストークンを発行する発行手段と、情報処理装置からサービス提供依頼を受けて、アクセストークンを認証する認証手段と、アクセストークンが認証された場合、情報処理装置に対して個人情報を利用する命令を送信する送信手段とを備える。情報処理装置は、サーバ装置に対して登録を依頼する登録依頼手段と、発行されたアクセストークンを利用して、サーバ装置にサービス提供依頼をする提供依頼手段と、命令に従って、個人情報を利用する利用手段とを備える。【選択図】図５

Description

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

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

特開２００５−３５２６３４号公報

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

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

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

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

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

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

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

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

（第１実施形態）
本実施形態では、インターネット上でＲＥＳＴＡＰＩによりウェブサービスを提供するＷｅｂＡＰＩサーバーにＩｏＴデバイスを登録し、その登録結果をＩｏＴデバイスのユーザーに電子メールを用いて通知するようなサービスを想定している。また、ＲＥＳＴＡＰＩサーバーがＲＥＳＴＡＰＩの処理結果と共にＩｏＴデバイスの個人情報を利用するような、ＷｅｂＡＰＩサーバーによる、ＩｏＴデバイス内のセキュアストレージ内の個人情報を編集可能にするようなサービスを想定している。なお、本実施形態に係るＷｅｂＡＰＩサーバーが提供するサービスは、これに限定することなく、様々なサービスを実装するＷｅｂＡＰＩサーバー全てに適用可能である。

本実施形態では、ＲＥＳＴＡＰＩ（ウェブサービス）実行の結果ユーザーの個人情報を利用するようなＲＥＳＴＡＰＩ実行において、インターネット上のＷｅｂＡＰＩサーバー側に個人情報を置かない。これにより、サーバー側の情報管理不備による漏洩、個人情報がＷｅｂＡＰＩサーバー、ＩｏＴデバイス間に流れる際のスキミング、ＭａｎｉｎｔｈｅｍＩＤｄｌｅ攻撃等を回避する。また、ＩｏＴデバイス内の個人情報は、ＴＰＭなどの耐タンパー性を有するハードウェア等により、十分に保護されるものとする。なお、ＩｏＴデバイスの個人情報を利用するようなＲＥＳＴＡＰＩサービスは、ＩｏＴデバイスの登録結果通知サービスに限られるものではない。さらに、本実施形態における権限の移譲ではＯＡｕｔｈの仕組みを利用する。ＯＡｕｔｈでは、ユーザーから移譲された権限の証明するための情報として、トークンと呼ばれる情報を利用する。

［ＩｏＴデバイスがメール送信を伴うＲＥＳＴＡＰＩ呼び出しを行う場合］
本実施形態に係るＲＥＳＴＡＰＩサービスシステム（情報処理システム）は、図１に示すような構成のネットワーク上に実現される。ＲＥＳＴＡＰＩサービスシステムは、ＷＡＮ１００と、ＬＡＮ１０１と、ＬＡＮ１０２と、クライアントＩｏＴデバイス２００と、ＷｅｂＡＰＩサーバー３００と、ＩｏＴデバイス設定用ＰＣ４００と、ＷｅｂＡＰＩサーバー設定用ＰＣ５００を含む。ＷＡＮ１００は、ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋであり、ＷｏｒｌｄＷｉｄｅＷｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１およびＬＡＮ１０２は、各構成要素を接続するＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋである。

クライアントＩｏＴデバイス２００は、ＬＡＮ１０１に存在するデバイスであり、ユーザーが操作、あるいは自律的に動作するＩｏＴデバイスである。ＩｏＴデバイスには、Ｗｅｂブラウザーや、ＷｅｂＡＰＩを呼び出す専用クライアントアプリケーションや、セキュアに個人情報を保存するストレージや、ＲＳＡ暗号演算、ＲＳＡ鍵ペア（公開鍵と秘密鍵）の生成やＳＨＡ−１ハッシュ演算などの機能を有する。また、チップ内で暗号化・復号、デジタル署名の生成・検証、プラットフォームの完全性検証を行うことができるＴＰＭ（業界団体ＴＣＧ（ＴｒｕｓｔｅｄＣｏｍｐｕｔｉｎｇＧｒｏｕｐ）が仕様策定）チップが存在する。ユーザーは、Ｗｅｂブラウザーや専用アプリケーションを用いて、ＷｅｂＡＰＩサーバー３００にアクセスし、さらにセキュアストレージ内の個人情報を用いてＷｅｂＡＰＩを利用する。ＩｏＴデバイス設定用ＰＣ４００は、クライアントＩｏＴデバイス２００と同様にＬＡＮ１０１に存在するＰＣであり、クライアントＩｏＴデバイス２００内の個人情報や、その編集要求について設定を行う。

ＷｅｂＡＰＩサーバー（サーバ装置）３００は、ＬＡＮ１０２に存在するサーバーであり、クライアントＩｏＴデバイス２００からのＷｅｂＡＰＩリクエスト（サービス提供依頼）に応じて、各種サービス提供を行う。例えば、各種サービスは、印刷サービスや帳票サービスといったサービスである。ＷｅｂＡＰＩサーバー設定用ＰＣ５００は、ＷｅｂＡＰＩサーバー３００と同様にＬＡＮ１０２に存在するＰＣであり、ＷｅｂＡＰＩサーバー３００内の個人情報に関わるパラメーターを設定する。

また、クライアントＩＯＴデバイス２００、ＷｅｂＡＰＩサーバー３００は、それぞれＷＡＮネットワーク１００およびＬＡＮ１０１、ＬＡＮ１０２を介して接続されている。なお、クライアントＩＯＴデバイス２００およびそれぞれのサービスは、それぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また、同一のＰＣ上に構成されていてもよい。

図２は、本実施形態に係るクライアントＩＯＴデバイス２００のハードウェア構成を示すブロック図である。なお、ＷｅｂＡＰＩサーバー３００のサーバーコンピューター、ＩｏＴデバイス設定用ＰＣ４００、ＷｅｂＡＰＩサーバー設定用ＰＣ５００の構成も同様である。図２に示されるハードウェアブロック図は、一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のクライアントＩＯＴデバイス２００およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、または外部メモリ２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここで、ＯＳとは、コンピュータ上で稼動するオペレーティングシステムの略語であり、以下、オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理は、このプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。本実施形態では、ＲＯＭ２０３は、フォントＲＯＭ、プログラムＲＯＭ、データＲＯＭを含むが、これに限定せず、まとめて１つのＲＯＭとしてもよく、他の機能別にＲＯＭを含んでもよい。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は、各種データを記憶するハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）等外部メモリ２１１におけるデータアクセスを制御する。ＮＣ２１２は、ネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。なお、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は、外部メモリ２１１にインストールされたアプリケーションプログラムである。各構成要素は、バス２０４によりそれぞれ通信可能に接続される。

図３は、本実施形態に係る、クライアントＩＯＴデバイス２００、ＷｅｂＡＰＩサーバー３００の、それぞれのモジュール構成を示す図である。クライアントＩＯＴデバイス２００は、ＣＰＵ２０１がＲＯＭ２０３または外部メモリ２１１に記憶されたＯＳを実行することで各アプリケーションを制御する。ＯＳ２１０は、一般的には、リアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用される。クライアントＩＯＴデバイス２００は、ＷＷＷを利用するためのユーザーエージェントであるＲＥＳＴクライアントモジュール２２０を備える。また、ＩｏＴデバイス２００は、自身の中にセキュアＤＢモジュール２３０を有する。セキュアＤＢモジュール２３０は、業界団体ＴｒｕｓｔｅｄＣｏｍｐｕｔｉｎｇＧｒｏｕｐ（ＴＣＧ）が標準仕様を策定するＴＰＭチップと、ＴＰＭチップに格納された暗号鍵情報で暗号化した個人情報データベースから構成される。

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

ＩｏＴデバイス２００は、後述のクライアント登録シーケンスを用いて後述のＷｅｂＡＰＩサーバー３００に自身をデバイス登録するためのクライアント登録依頼モジュール２６０を有する。メール送信モジュール２４０は、後述するデバイスステータス情報送信依頼ＲＥＳＴＡＰＩ処理の結果、ＩｏＴデバイス２００のセキュアＤＢモジュール２３０内に存在するメールアドレスなどの個人情報を用いて機能するモジュールである。該メール送信モジュール２４０は、電子メール送信プロトコルとしてＳＭＴＰを用いるＳＭＴＰクライアント機能を有し、また送信先ＳＭＴＰサーバーは、予め設定されているものとする。なお、ユーザーが送信先となるＳＭＴＰサーバーの設定を変更することは適宜可能である。個人情報編集モジュール２５０は、後述する個人情報編集依頼ＲＥＳＴＡＰＩ処理の結果、ＩｏＴデバイス２００のセキュアＤＢモジュール２３０内に存在する個人情報を処理するモジュールである。

本実施形態では、２つのＷｅｂＡＰＩサーバー対応モジュールであるメール送信モジュール２４０と個人情報編集モジュール２５０をＩｏＴデバイス２００が有する。しかしながら、前述の通り、様々なＷｅｂＡＰＩに対応可能であるためＩｏＴデバイス２００が備えるモジュールは、これらに限定されない。

ＷｅｂＡＰＩサーバー３００は、ＣＰＵ２０１がＲＯＭ２０３、または外部メモリ２１１に記憶されたＯＳを実行する事で各アプリケーションを制御する。ＯＳ３１０は、一般的にはＬｉｎｕｘ（登録商標）等の汎用ＯＳであってよい。また、ＷｅｂＡＰＩサーバー３００は、ＲＥＳＴサーバーモジュール３２０を有する。そして、ＲＥＳＴサーバーモジュール３２０は、ＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０からのＲＥＳＴ要求を受信し、その要求を処理した上で後述するＪＳＯＮ形式のＲＥＳＴレスポンスを返す機能を有する。また、ＷｅｂＡＰＩサーバー３００は、認証トークンの管理、検証を行う認証モジュール３３０と、デバイス登録データ、トークンデータを管理、保持するＤＢモジュール３４０とを有する。ＷｅｂＡＰＩサーバー３００のクライアント登録モジュール３５０は、ＩｏＴデバイス２００のクライアント登録依頼モジュール２６０からの要求を受ける。そして、ＷｅｂＡＰＩサーバー３００上のＤＢモジュール３４０にＩｏＴデバイスのデバイスＩＤなどのＩｏＴデバイス情報を登録するクライアント登録機能を有する。

［デバイス登録］
図４は、本実施形態に係る、ＷｅｂＡＰＩサーバー３００へのＩｏＴデバイス２００の登録のシーケンスを示す図である。本シーケンスは、ＩｏＴデバイス２００のクライアント登録依頼モジュール２６０がクライアント登録依頼を行うことで開始される。本実施形態では、ＷｅｂＡＰＩサーバー３００のＲＥＳＴエンドポイントのＵＲＬは、ＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０が保持している。しかしながら、これに限定することなく、ＩｏＴデバイス２００内のセキュアＤＢモジュール２３０、外部メモリ２１１などに保持してもよく、外部入力可能であれば、外部から入力してもよい。ここで、表１を用いて、ＩｏＴデバイス２００のセキュアＤＢモジュール２３０内に存在するデバイス関連情報テーブルについて説明する。

表１は、デバイス関連情報テーブルであり、DeviceID、TenantID、Public_Key、Private_Key、Tokenから構成される。DeviceIDは、ＩｏＴデバイス２００の工場出荷時などに予め決められたデバイスＩＤを格納する。TenantIDは、予め設定されたデバイスの所属するテナントを格納する。Public_Key、Private_Keyは、後述するＩｏＴデバイス２００で生成する２０４８ｂｉｔＲＳＡの公開鍵、秘密鍵をそれぞれ格納する。Tokenは、後述するＷＥＢＡＰＩサーバー３００から取得するアクセストークンを格納する。なお、TenantIDは、ＩｏＴデバイス２００の外部から入力可能な構成にしてもよい。

クライアント登録依頼モジュール２６０は、ＷｅｂＡＰＩサーバー３００でＩｏＴデバイス２００の確認を行うために、ＴＰＭチップを用いて２０４８ｂｉｔＲＳＡの公開鍵、秘密鍵を生成する。そして、セキュアＤＢモジュール２３０のデバイス関連情報テーブル（表１）のPublic_Key、Private_Keyに格納する（ステップＳ４０１）。なお、これらの鍵の鍵長、アルゴリズムについては、十分に安全性が確認されていれば、２０４８ｂｉｔ／ＲＳＡ以外の他のものでも良い。

次に、クライアント登録モジュール２６０は、セキュアＤＢモジュール２３０のデバイス関連情報テーブル（表１）からデバイスＩＤ（Device_A）とテナントＩＤ（101AA）と公開鍵（xxxxx）を引数に指定する。そして、ＷＥＢＡＰＩサーバー３００のデバイス登録ＲＥＳＴＡＰＩを呼び出すためにＲＥＳＴクライアントモジュール２２０を使用する（ステップＳ４０２）。クライアント登録依頼モジュール２６０からＲＥＳＴＡＰＩ呼び出しを依頼されたＲＥＳＴクライアントモジュール２２０は、引数を指定して、ＷＥＢＡＰＩサーバー３００のクライアント登録ＡＰＩを呼び出す（ステップＳ４０３）。

ＩｏＴデバイス２００からクライアント登録ＡＰＩを呼び出されたＷＥＢＡＰＩサーバー３００は、ＲＥＳＴサーバーモジュール３２０がクライアント登録ＡＰＩを受信する。本実施形態のＲＥＳＴＡＰＩは、ＨＴＴＰまたはＨＴＴＰＳプロトコルを用い、ＪＳＯＮ形式のメッセージで表される。具体的なクライアント登録ＡＰＩを以下に示す。
［クライアント登録ＡＰＩ］
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"
}

上記クライアント登録ＡＰＩを受信したＷＥＢＡＰＩサーバー３００のＲＥＳＴサーバーモジュール３２０は、クライアント登録ＡＰＩの引数をデバイス登録テーブル（表２）に保存する（ステップＳ４０４）。すなわち、引数であるデバイスＩＤ、テナントＩＤ、ＩｏＴデバイス２００で生成した公開鍵を、デバイス登録データ、トークンデータを、管理、保持するＤＢモジュール３４０のデバイス登録テーブル（表２）に保存する。ここで、表２を用いて、ＷＥＢＡＰＩサーバー３００のＤＢモジュール３４０内に存在するデバイス登録テーブルについて説明する。

デバイス登録テーブル（表２）は、TenantID、DeviceID、Public_Key、Token、nonceから構成される。TenantIDは、予め設定されたデバイスの所属するテナントを格納する。DeviceIDは、クライアント登録ＡＰＩの引数で指定され、登録されたクライアントを示すデバイスＩＤを格納する。Public_Keyは、同じくクライアント登録ＡＰＩの引数で指定され、登録されたクライアントで生成された公開鍵を格納する。Tokenは、後述するデバイス登録の際に発行するトークンを格納する。nonceは、後述するクライアントであるＩｏＴデバイス２００の個人情報アクセス要求に対する応答が正当であることを保障するための仕組みに用いるｎｏｎｃｅ値を格納する。なお、TenantIDは、ＷＥＢＡＰＩサーバー３００の外部から入力可能な構成であってもよい。

ＷＥＢＡＰＩサーバー３００のＲＥＳＴサーバーモジュール３２０は、デバイス登録テーブル（表２）に対し、受信したＲＥＳＴＡＰＩの引数のテナントＩＤ（“101AA”）の存在を確認する。そして、テナントＩＤが存在していれば、同カラムのDeviceID格納領域に、同じくＲＥＳＴＡＰＩの引数のデバイスＩＤ（“Device_A”）を格納する（ステップＳ４０４）。デバイスＩＤ登録が成功した場合、ＲＥＳＴサーバーモジュール３２０は、クライアント登録ＡＰＩをコールしたＩｏＴデバイス２００の以降のサービス呼び出しが正当であるか否かを検証するために用いるアクセストークンを発行する。そして、デバイス登録テーブル（表２）の、要求元TenantID、DeviceIDと同じカラムのToken領域に発行したアクセストークンを格納する（ステップＳ４０４）。

デバイス登録テーブル（表２）へのデバイスＩＤ、公開鍵の格納、アクセストークン発行と格納が正常に終了した際にはＲＥＳＴサーバーモジュール３２０へ正常に終了した旨を伝える（ステップＳ４０５）。そして、ＲＥＳＴサーバーモジュール３２０は、アクセストークンを、クライアント登録ＡＰＩの呼び出し元であるＩｏＴデバイス２００に対してＲＥＳＴＡＰＩ応答として返却する（ステップＳ４０６）。このとき、ＨＴＴＰあるいはＨＴＴＰＳプロトコルを用いて、ＪＳＯＮフォーマットでＲＥＳＴＡＰＩ応答として返却する。具体的なクライアント登録ＲＥＳＴＡＰＩ応答の内容を以下に示す。
［クライアント登録ＲＥＳＴＡＰＩ応答］
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"
}

ＷＥＢＡＰＩサーバー３００から、クライアント登録ＡＰＩ応答を受信したＲＥＳＴクライアントモジュール２２０は、クライアント登録ＡＰＩ応答の引数であるトークンをデバイス関連情報テーブル（表１）のTokenに保存する（ステップＳ４０７）。すなわち、トークン（"5d9556d8-5035-4a67-abd3-13bd13c7cdf0@1000000AAxI"）をセキュアＤＢモジュール２３０内に存在するデバイス関連情報テーブル（表１）のToken格納領域に保存する。

［メール送信を伴うＲＥＳＴＡＰＩ処理］
図５は、本実施形態に係る、個人情報を用いた特定の処理として、ＩｏＴデバイス２００のメール送信処理のシーケンスを示す図である。本シーケンスは、デバイス登録処理終了後、ユーザーがＩｏＴデバイス２００の、ＷｅｂＡＰＩサーバー３００との通信を開始するためのメール送信ボタンを押下する。そして、ＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０が、ＷｅｂＡＰＩサーバー３００のＲＥＳＴサーバーモジュール３２０のＲＥＳＴＡＰＩを呼び出すことで開始される。

本実施形態では、ＷｅｂＡＰＩサーバー３００のＲＥＳＴエンドポイントのＵＲＬは、ＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０が保持している。しかしながら、ＩｏＴデバイス２００内のセキュアＤＢモジュール２３０、外部メモリ２１１などに保持してもよく、外部入力可能であれば外部から入力してもよい。

メール送信を行うＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０は、デバイス関連情報テーブル（表１）を利用して、ＲＥＳＴサーバーモジュール３２０に実装された、メール送信ＲＥＳＴＡＰＩを呼び出す（ステップＳ５０１）。すなわち、セキュアＤＢモジュール２３０内に存在するデバイス関連情報テーブル（表１）のDeviceIDと、TenantIDと、デバイス登録で取得したアクセストークンを引数にして、メール送信ＲＥＳＴＡＰＩを呼び出す。具体的なメール送信ＲＥＳＴＡＰＩを以下に示す。
［メール送信ＲＥＳＴＡＰＩ］
POST /client_status HTTP/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"
}

メール送信ＲＥＳＴＡＰＩを受信したＷｅｂＡＰＩサーバー３００のＲＥＳＴサーバーモジュール３２０は、ＩｏＴデバイスのＲＥＳＴＡＰＩ呼び出しを、認証トークンの管理、検証を行う認証モジュール３３０を用いて検証する。すなわち、受信したＲＥＳＴＡＰＩ呼び出しのdevice_id、tenant_id、tokenを認証トークンの管理、検証を行う認証モジュール３３０に渡す（ステップＳ５０２）。本実施形態では、device_idは、“Device_A”であり、tenant_idは、“101AA”である。そして、tokenは、“5d9556d8-5035-4a67-abd3-13bd13c7cdf0@1000000AAxI”である。認証モジュール３３０は、デバイス登録処理でデバイス登録した、デバイス登録テーブル（表２）のDeviceID、TenantID、Tokenと、渡されたdevice_id、tenant_id、tokenの値を比較する。そして、登録済みのＩｏＴデバイスからのＲＥＳＴＡＰＩ呼び出しかどうか判定する（ステップＳ５０３）。この判定が異常であれば、ＲＥＳＴＡＰＩ呼び出しに対してエラーを返す。

検証モジュールのアクセストークン検証処理が正常であれば（ステップＳ５０３）、ＲＥＳＴサーバーモジュール３２０は、クライアントステータスを取得し、メール送信のためのメール文面テンプレートと、パラメーターを取得する。表３、表４を用いて、ＷｅｂＡＰＩサーバー３００内に存在する、ＲＥＳＴＡＰＩ応答コマンドテーブル、ＲＥＳＴＡＰＩ応答コマンドパラメーターテーブルについて説明する。

ＲＥＳＴＡＰＩパラメーターテーブル（表３）は、以下のカラムを有する。すなわち、予め設定されたデバイスの所属するテナントを格納するTenantID、にＷｅｂＡＰＩサーバー３００のＲＥＳＴサーバーモジュール３２０に実装された各々のＲＥＳＴＡＰＩにより一意に決まるServiceIDを有する。また、後述するServiceIDのＲＥＳＴＡＰＩに対応し、該ＲＥＳＴＡＰＩの応答に付属する、ＩｏＴデバイス２００が実行するコマンドを示すCommandを有する。以上のカラムがＲＥＳＴＡＰＩパラメーターテーブル（表３）に存在する。

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

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

ＷｅｂＡＰＩサーバー３００のＲＥＳＴサーバーモジュール３２０は、ＤＢモジュール３４０に存在するＲＥＳＴＡＰＩ応答コマンドテーブル（表３）、ＲＥＳＴＡＰＩ応答コマンドパラメーターテーブル（表４）を参照する（ステップＳ５０４）。そして、メール送信ＲＥＳＴＡＰＩ呼び出しで指定されたサービスと、メール送信ＲＥＳＴＡＰＩのパラメーターに指定されたテナントＩＤに相当するＲＥＳＴＡＰＩ応答コマンドテーブル（表３）のCommandを取得する。すなわち、メール送信ＲＥＳＴＡＰＩ呼び出しで指定されたサービス（client_status）と、メール送信ＲＥＳＴＡＰＩのパラメーターに指定されたテナントＩＤ（“tenant_ID”:“101AA”）に相当するCommandを取得する。さらに、相当するＲＥＳＴＡＰＩ応答コマンドパラメーターテーブル（表４）のCommandに対応するArguments、Auth1、Auth2、Privilege1、Privilege2のカラムの各々を取得する（ステップＳ５０５）。本実施形態では、Commandは、“send-mail”、Argumentsは、“Template_A”、Auth1は、“private_admin_mail_address”を参照する。また、Privilege1は、“R”、Auth2は、“private_admin_name”、Privilege2は、“R”を参照する。ここで、Artumentsの“Template_A”は、ＷｅｂＡＰＩサーバー３００の外部メモリ２１１に存在するメール送信のためのメール文面テンプレートを示す。本実施形態における具体的な“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

ＲＥＳＴサーバーモジュール３２０は、上記Command、Argument、Auth1、Privilege1、Auth2、Privilege2を用いて、応答（命令）を作成する。すなわち、メール送信ＲＥＳＴＡＰＩの応答（命令）を作成し、ＩｏＴデバイス２００に返す（ステップＳ５０６）。具体的には、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”をＪＳＯＮ形式の“private_info”:“private_admin_mail_address”という値にに展開する。さらに、“access_privilege”:{“create”:“NG”，“read”:“OK”，“update”:“NG”，“delete”:“NG”}という値に展開する。そして、Privilege2の“R”を、ＪＳＯＮ形式の“private_info”:“private_admin_name”という値にに展開する。さらに、“access_privilege”:{“create”:“NG”，“read”:“OK”，“update”:“NG”，“delete”:“NG”}という値に展開する。具体的な本実施形態のメール送信ＲＥＳＴＡＰＩの応答を、ＪＳＯＮ形式で以下に示す。
［メール送信ＲＥＳＴＡＰＩの応答］
{
"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"
}
}
]
}
}
]
}

ＷｅｂＡＰＩサーバー３００のＲＥＳＴサーバーモジュール３２０に実装されたメール送信ＲＥＳＴＡＰＩを呼び出したＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０は、ＲＥＳＴＡＰＩの応答として上記ＪＳＯＮメッセージを受信する。ＲＥＳＴクライアントモジュール２２０は、次に受信したＲＥＳＴＡＰＩ応答のＪＳＯＮメッセージを参照し、メッセージ中の“command”、“argument”、“auth”の値に従った動作を行う。

本実施形態では、ＲＥＳＴＡＰＩコールを行うＲＥＳＴＡＰＩクライアント（ＩｏＴデバイス２００）が、ＷｅｂＡＰＩサーバー（ＷｅｂＡＰＩサーバー３００）からの応答（命令）に含まれるコマンドにより動作する。また、ＷｅｂＡＰＩサーバー３００からの応答に含まれる個人情報アクセス権限に従って、自身に内在する個人情報にアクセスしてコマンドを実行する。その際、ＷｅｂＡＰＩサーバー側にＲＥＳＴクライアントの個人情報が存在しないことが特徴である。

本実施形態では、ＲＥＳＴクライアントモジュール２２０は、受信したＲＥＳＴＡＰＩ応答のＪＳＯＮメッセージを参照する。そして、“auth”の“private_info”の“private_admin_mail_address”と、同じく“private_info”の“private_admin_name”を取り出す。さらに、ＩｏＴデバイス２２０のセキュアＤＢモジュール２３０に保存される表５に示す個人情報テーブル１を参照する。

個人情報テーブル１（表５）は、以下のカラムを有する。すなわち、個人情報項目を表すprivate_info、メールアドレスを表すmail_address、名前を表すname、ニックネームを表すnicknameカラムである。本実施形態の個人情報テーブル１（表５）においては、個人情報の要素としてメールアドレスと名前とニックネームが存在している。もちろん、ＲＥＳＴＡＰＩの種類に応じてＩｏＴデバイス２００のセキュアＤＢモジュール２３０で管理される個人情報の要素は、住所、位置情報、所属名などであってよい。

本実施形態では、ＲＥＳＴクライアントモジュール２２０は、セキュアＤＢモジュール２３０内の上記個人情報テーブル１（表５）と、受信したＲＥＳＴＡＰＩ応答のＪＳＯＮメッセージを参照する。そして、ＷｅｂＡＰＩサーバー３００のＲＥＳＴサーバーモジュールからＪＳＯＮメッセージ内のパラメーターとして要求された個人情報を、個人情報テーブル１（表５）から取得する。具体的には、ＪＳＯＮメッセージの“auth”の“private_info”の“private_admin_mail_address”として個人情報テーブル１（表５）の対応する値“admin@ＩｏＴ.example.com”を取得する。また、同じくＪＳＯＮメッセージの“private_info”の“private_admin_name”として個人情報テーブル１（表５）の対応する値“Administrator”を取得する。その際、ＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０は、ＷｅｂＡＰＩサーバー３００から受信したＪＳＯＮメッセージの“private_info”の“access_privilege”に対応する権限のアクセス制限を受ける。

本実施形態では、ＪＳＯＮメッセージの“private_info”の“private_admin_mail_address”と“private_admin_name”の“access_privilege”が “read”:“OK”である。そのため、ＲＥＳＴクライアントモジュール２２０は、個人情報テーブル１（表５）の“private_admin_mail_address”と“private_admin_name”の情報にアクセスし、読み出す（ステップＳ５０７）。

その後、ＲＥＳＴクライアントモジュール２２０は、セキュアＤＢモジュール２３０内の個人情報テーブル１（表５）から取得した項目を用いてＪＳＯＮメッセージの“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

ＲＥＳＴクライアントモジュール２２０は、作成したメール文面メッセージと、受信したＲＥＳＴＡＰＩ応答のＪＳＯＮメッセージの“command”の値（“send-mail”）に従って、メール送信モジュール２４０を呼び出す（ステップＳ５０８）。ＩｏＴデバイス２００のメール送信モジュール２４０は、受け取ったメール文面メッセージに従って、電子メールを送信する（ステップＳ５０９）。

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

（第２実施形態）
［ＩｏＴデバイスが個人情報編集を伴うＲＥＳＴＡＰＩ呼び出しを行う場合］
本実施形態では、第１実施形態と同様の構成において、ＩｏＴデバイス２００がセキュアＤＢモジュール２３０に存在する個人情報の編集を伴うＲＥＳＴＡＰＩ呼び出しを行う場合について説明する。図７は、本実施形態に係る、個人情報を用いた特定の処理として、ＩｏＴデバイス２００の個人情報編集処理のシーケンスを示す図である。本シーケンスは、デバイス登録処理終了後、ＰＣ４００が、ＩｏＴデバイス２００との通信を開始するための個人情報編集ボタンを押下し、個人情報編集モジュール２５０に個人情報編集要求を行うことで開始される（ステップＳ８０１）。個人情報編集要求について、具体的には以下のような個人情報編集要求メッセージにより行われる。
［個人情報編集要求メッセージ］
{
"type": "Program",
"body": [
{
"command": "edit-user",
"arguments": {
"private_info": "private_user1",
"name": "User2",
"nickname": "User2"
}
}
]
}

上記メッセージは、ＩｏＴデバイス２００のセキュアＤＢモジュール２３０内の個人情報テーブル１（表５）に存在する“private_user1”の“name”と“nickname”を更新するメッセージである。該メッセージを受信したＩｏＴデバイス２００の個人情報編集モジュール２５０は、ＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０に対し、個人情報編集許可確認ＲＥＳＴＡＰＩの呼び出しを依頼する（ステップＳ８０２）。本実施形態では、セキュアＤＢモジュール２３０内の個人情報テーブル１（表５）に存在するような個人情報を、ＩｏＴデバイス２００と同じＬＡＮ１０２に存在するＰＣ４００などから編集する場合を想定している。この場合、ＷｅｂＡＰＩサーバー３００に対してＲＥＳＴＡＰＩ呼び出しを行い、その結果により個人情報を編集する。これは、例えば、ＩｏＴデバイス２００が公共の場にあり複数のユーザーから使用されるような場合、ＩｏＴデバイス２００内の個人情報の編集について、ＷｅｂＡＰＩサーバー３００側の個人情報編集ポリシーを強制できる、という効果がある。

個人情報編集モジュール２５０から個人情報編集許可確認ＲＥＳＴＡＰＩの呼び出しを依頼されたＲＥＳＴクライアントモジュール２２０は、デバイス登録で取得したアクセストークンを引数にして、ＲＥＳＴＡＰＩを呼び出す（ステップＳ８０３）。具体的には、ＲＥＳＴクライアントモジュール２２０は、セキュアＤＢモジュール２３０内に存在するデバイス関連情報テーブル（表１）のTokenに保存した、アクセストークンを引数に、ＲＥＳＴサーバーモジュール３２０のＲＥＳＴＡＰＩを呼び出す。このＲＥＳＴＡＰＩは、ＲＥＳＴクライアントモジュールが、個人情報編集要求メッセージからパラメーターを作成する。

本実施形態では、ＷｅｂＡＰＩサーバー３００のＲＥＳＴエンドポイントのＵＲＬは、ＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０が保持している。しかしながら、ＩｏＴデバイス２００内のセキュアＤＢモジュール２３０、外部メモリ２１１などに保持してもよく、外部入力可能であれば外部から入力してもよい。なお、具体的な個人情報編集許可確認ＲＥＳＴＡＰＩについて以下に示す。
［個人情報編集許可確認ＲＥＳＴＡＰＩ］
POST /edit_private_info HTTP/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_ＩＤ":"Device_A",
"tenant_ＩＤ":"101AA",
"token":"5d9556d8-5035-4a67-abd3-13bd13c7cdf0@1000000AAxI"

}

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

個人情報編集許可確認ＲＥＳＴＡＰＩを受信したＷｅｂＡＰＩサーバー３００のＲＥＳＴサーバーモジュール３２０は、ＩｏＴデバイスのＲＥＳＴＡＰＩ呼び出しを、認証トークンの管理、検証を行う認証モジュール３３０を用いて検証する。ＷｅｂＡＰＩサーバーモジュールは、受信したＲＥＳＴＡＰＩ呼び出しのdevice_ID、tenant_ID、tokenを認証トークンの管理、検証を行う認証モジュール３３０に渡す（ステップＳ８０４）。具体的には、device_IDは“Device_A”を、tenant_IDは“101AA”を、tokenは“5d9556d8-5035-4a67-abd3-13bd13c7cdf0@1000000AAxI”を認証モジュール３３０に渡す。認証モジュール３３０は、ＷｅｂＡＰＩサーバー３００に存在するデバイス登録テーブル（表２）の値と、渡された値を比較し、登録済みのＩｏＴデバイスからのＲＥＳＴＡＰＩ呼び出しかどうか判定する（ステップＳ８０５）。すなわち、デバイス登録テーブル（表２）のDeviceID、TenantID、Tokenと、渡されたdevice_ID、tenant_ID、tokenの値を比較する。この判定が異常であれば、ＲＥＳＴＡＰＩ呼び出しに対してエラーを返す。

ＲＥＳＴＡＰＩ応答コマンドパラメーターテーブル２（表６）は、以下のカラムを有する。つまり、表３のCommandに対応するCommand、各Commandに対応するCommandのパラメーターで、本実施形態のＩｏＴデバイス２００のセキュアＤＢモジュール２３０に存在する個人情報の編集対象者を示すArgumentsを有する。また、セキュアＤＢモジュール２３０に存在する個人情報の編集対象者の情報項目で示されるＩｏＴデバイス上の編集対象の個人情報に対するアクセス権限を示すPrivilege1、Privilege2を有する。本実施形態では、個人情報の編集対象者の情報項目は、Private_info1、Private_info2、Private_info1、Private_info2である。上述のようにPrivate_infoとPrivilegeは、コマンドに応じて複数存在し、各カラム名は、Private_info1、Private_info2…、Privilege１、Privilege2…のような数字付きのカラム名になる。以上のカラムがＲＥＳＴＡＰＩ応答コマンドパラメーターテーブル２（表６）に存在する。なお、表３、表６のTenantID、ServiceID、Command、Arguments、Private_info1、Private_info2、Privilege1、Privilege2は、外部から入力可能な構成にしてもよい。

検証モジュールのアクセストークン検証処理が正常であれば（すなわち、アクセストークンの認証ができた場合）（ステップＳ８０５）、ＲＥＳＴサーバーモジュール３２０に返答する。次に、ＲＥＳＴサーバーモジュール３２０は、ＤＢモジュール３４０に存在するＲＥＳＴＡＰＩ応答コマンドテーブル（表３）、ＲＥＳＴＡＰＩ応答コマンドパラメーターテーブル２（表６）を参照する（ステップＳ８０６）。そして、個人情報編集許可確認ＲＥＳＴＡＰＩ呼び出しで指定されたサービス（edit-user）と、ＲＥＳＴＡＰＩ応答コマンドテーブル（表３）のCommand（edit-user）を取得する。具体的には、個人情報編集許可確認ＲＥＳＴＡＰＩのパラメーターに指定されたテナントＩＤ（“tenant_ID”:“101AA”）に相当する表３のCommand（edit-user）を取得する。さらに、ＲＥＳＴＡＰＩ応答コマンドパラメーターテーブル（表６）のCommandに対応するArguments、Private_info1、Private_info2、Privilege1、Privilege2の各々の値を取得する。すなわち、Command（edit-user）に相当するＲＥＳＴＡＰＩ応答コマンドパラメーターテーブル（表６）のCommand（edit-user）に対応する各々の値を取得する（ステップＳ８０７）。本実施形態では、個人情報編集許可確認ＲＥＳＴＡＰＩで指定されたパラメーターに従い、Commandは、“edit-user”を、Argumentsは、“private_user1”を、Private_info1は、“name”を参照する。また、Privilege1は、“CRU”を、Private_info2は、“nickname”を、Privilege2は、“CRUD”を参照する。

ＲＥＳＴサーバーモジュール３２０は、Command、Arguments、Private_info1、Privillege1、Private_info2、Privillege2で、個人情報編集許可確認ＲＥＳＴＡＰＩの応答を作成する。そして、ＩｏＴデバイス２００に返す。すなわち、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#”に展開する。

“#private_user1#”と“#”記号で囲んだのは、ＩｏＴデバイス２００における個人情報であることを明示するためである。さらに、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の各値をＪＳＯＮ形式の値に展開する。本実施形態の具体的な個人情報編集許可確認ＲＥＳＴＡＰＩの応答について、ＪＳＯＮ形式で以下に示す。
［個人情報編集許可確認ＲＥＳＴＡＰＩの応答］
{
"type": "Program",
"body": [
{
"command": "edit-user",
"arguments": {
"private_ＩＤ": "#private_user1#",
"param1": "#name#",
"access_privillege": {
"create": "OK",
"read": "OK",
"update": "OK",
"delete": "NG"
},
"private_ＩＤ": "#private_user1#",
"param2": "#nickname#",
"access_privillege": {
"create": "OK”,
"read": "OK",
"update": "OK",
"delete": "OK"
}
}
}
]
}

ＲＥＳＴサーバーモジュール３２０に実装されたメール送信ＲＥＳＴＡＰＩを呼び出したＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０は、ＲＥＳＴＡＰＩの応答として上記ＪＳＯＮメッセージを受信する（ステップＳ８０８）。次に、ＲＥＳＴクライアントモジュール２２０は、受信したＲＥＳＴＡＰＩ応答のＪＳＯＮメッセージを参照し、メッセージ中の“command”、“arguments”の値に従った動作を行う。

本実施形態では、ＲＥＳＴＡＰＩコールを行うＲＥＳＴＡＰＩクライアント（ＩｏＴデバイス２００）が、ＷｅｂＡＰＩサーバー（ＷｅｂＡＰＩサーバー３００）からの応答に含まれるコマンドにより動作する。さらに、ＷｅｂＡＰＩサーバーからの応答に含まれる個人情報アクセス権限に従って、自身に内在する個人情報にアクセスしてコマンドを実行する。その際、ＷｅｂＡＰＩサーバー側にＲＥＳＴクライアントの個人情報が存在しない。

また、本実施形態では、ＲＥＳＴクライアントモジュール２２０は、受信したＲＥＳＴＡＰＩ応答のＪＳＯＮメッセージを参照し、“command”:“edit-user”に指定された個人情報の編集を行う。すなわち、受信した個人情報編集許可確認ＲＥＳＴＡＰＩ応答の“arguments”の“private_ID”、“param1”、“access_privillege”、“param2”、“access_privillege”を取り出す。そして、個人情報編集モジュール２５０に渡す（ステップＳ８０９）。個人情報編集モジュール２５０は、セキュアＤＢモジュール２３０内の個人情報テーブル（表５）を参照する。そして、個人情報編集要求メッセージと、ＲＥＳＴクライアントモジュール２２０から受け取った個人情報編集許可確認ＲＥＳＴＡＰＩ応答を比較して、個人情報編集要求メッセージの内容を検証する。

すなわち、個人情報編集要求メッセージは、セキュアＤＢモジュール２３０内の表５の“private_info”の“private_user1”の“name”と“nickname”を変更するような依頼メッセージを示す。すなわち、“name”と“nickname”を各々“User2”、“User2”に変更するような依頼メッセージを示す。また、ＲＥＳＴクライアントモジュール２２０から受け取った個人情報編集許可確認ＲＥＳＴＡＰＩ応答は、“private_ID”に示された“private_info”の値について、“name”の作成、更新、変更が可能である。すなわち、“private_info”の値“private_user1”について、“name”の作成、更新、変更が可能である。同じく、“nickname”の作成、更新、変更、削除が可能であることを示している。そこで、個人情報編集モジュール２５０は、個人情報編集要求メッセージに従い、表５の“private_info”の“private_user1”の“name”と“nickname”を変更する（ステップＳ８１０）。すなわち、“private_user1”の“name”と“nickname”を各々“User2”、“User2”に変更する。

［個人情報アクセスをさらにセキュアにする手段］
次に、個人情報アクセスをさらにセキュアにする手段について述べる。図６は、ＩｏＴデバイス２００のセキュアＤＢモジュール２３０内の個人情報アクセスに際してのＲＥＳＴＡＰＩの要求元がＩｏＴデバイス２００であり、要求先がＷｅｂＡＰＩサーバー３００であることをより確実にするための手段を示すシーケンス図である。図６のシーケンスは、第１実施形態のステップＳ５０１、第２実施形態ステップＳ８０３において行われる。

まず、ＩｏＴデバイス２００は、個人情報アクセスを伴うＲＥＳＴＡＰＩ要求を行う前に、ＷｅｂＡＰＩサーバー３００に対して個人情報アクセス要求を送信する（ステップＳ７０１）。本要求は、デバイス登録で取得したアクセストークンを引数にして行われる。個人情報アクセス要求を受信したＷｅｂＡＰＩサーバー３００は、取得したアクセストークンに対して、使い捨てのランダムな値であるnonce値を生成する。そして、ＤＢモジュール３４０内に存在するデバイス登録テーブル（表２）のトークンと同じカラムのnonce領域にnonce値文字列として保存する（ステップＳ７０２）。具体的には、nonce値文字列としてUUIDで“7f5d949c-0318-4e4c-84f1-4d569d674ab5”を生成する。そして、生成したnonce値文字列をＩｏＴデバイス２００に返却する（ステップＳ７０３）。

ＷｅｂＡＰＩサーバー３００からnonce値文字列を返却されたＩｏＴデバイス２００は、デバイス関連情報テーブル（表１）のDeviceID文字列を取得する。そして、nonce値文字列と結合してＳＨＡ１ハッシュアルゴリズムを用いてハッシュ値１を求める（ステップＳ７０４）。具体的には、本実施形態では、nonce値文字列（“7f5d949c-0318-4e4c-84f1-4d569d674ab5”）と、DeviceID文字列（“Device_A”）を結合する。結合して得た値をＳＨＡ１ハッシュ化して得た値がハッシュ値１に相当する。ＩｏＴデバイス２００は、ハッシュ値１をＷｅｂＡＰＩサーバーに送信する（ステップＳ７０５）。

ハッシュ値１を受信したＷｅｂＡＰＩサーバー３００は、ＤＢモジュール３４０内に存在するデバイス登録テーブル（表２）のトークンと同じカラムのDeviceID文字列とnonce文字列を取得する。そして、DeviceID文字列とnonce文字列を結合してＳＨＡ１ハッシュアルゴリズムを用いてハッシュ値２を求める。具体的には、本実施形態では、nonce値文字列（“7f5d949c-0318-4e4c-84f1-4d569d674ab5”）と、DeviceID文字列（“Device_A”）を結合する。そして、ハッシュ値１とハッシュ値２を比較して、ハッシュ値比較を行う。もし、ハッシュ値比較の結果が同じであれば、個人情報アクセス要求ＯＫの応答を行う（ステップＳ７０７）。そして、個人情報へアクセスを行う（ステップＳ７０８）。もし、ハッシュ値比較の結果が不一致であれば、個人情報アクセス要求に対してエラーの応答を行う。

以上、本実施形態によれば、ＲＥＳＴＡＰＩ実行の結果ユーザーの個人情報を利用するようなＲＥＳＴＡＰＩ実行において、サーバー側に個人情報を置かないことで、サーバー側の情報管理不備、情報漏洩等を解消することができる。また、個人情報をみだりにネットワークに流さないことで、ＭａｎｉｎｔｈｅｍＩＤｄｌｅなどの攻撃にも対処できる。また、クライアントデバイス側の個人情報は（ＴＰＭなどにより）十分に保護される。さらに、クラウド側は、ユーザー個人情報に紐付かない処理を行い、デバイス側は、ユーザー個人情報に紐付く処理を行う。この２つをオーバーレイしてＲＥＳＴＡＰＩ処理を行うことで、サーバー側に個人情報を置くことなく、サーバー側情報と個人情報を合わせたサービスを行うことができる。

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

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

Claims

ウェブサービスを提供するサーバ装置から個人情報を有する情報処理装置に対して前記サービスを提供する情報処理システムであって、
前記サーバ装置は、
前記情報処理装置にて管理されている個人情報を利用する前記ウェブサービスを提供する提供手段と、
前記情報処理装置からの依頼に応じて、アクセストークンを発行する発行手段と、
前記情報処理装置からサービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証手段と、
前記認証手段により前記アクセストークンが認証された場合、前記情報処理装置に対し前記提供手段による前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令を送信する送信手段と、
を備え、
前記情報処理装置は、
前記個人情報を管理する管理手段と、
前記サーバ装置に対して前記情報処理装置の登録を依頼する登録依頼手段と、
前記発行手段により発行された前記アクセストークンを利用して、前記サーバ装置に対して前記サービス提供依頼を送信する提供依頼手段と、
前記サーバ装置の送信手段から送信された前記命令に従い前記管理手段にて管理される前記個人情報を参照し、前記命令に従い参照した前記個人情報を用いて特定の処理を実行する処理手段と、
を備える
ことを特徴とする情報処理システム。
前記認証手段が、前記提供依頼手段からの前記アクセストークンが前記発行手段で発行したアクセストークンであると判定した場合、前記送信手段は、前記命令を前記情報処理装置に対して送信する
ことを特徴とする請求項１に記載の情報処理システム。
前記認証手段は、前記提供依頼手段からの前記アクセストークンが前記発行手段で発行したアクセストークンでないと判定した場合、前記情報処理装置にエラーを送信し、前記処理手段は、前記認証手段によりエラーが送信された場合、前記個人情報を用いて前記特定の処理を実行しない
ことを特徴とする請求項１または２に記載の情報処理システム。
前記送信手段が送信する命令にはメール送信処理に関する命令が含まれ、前記処理手段は、前記命令に含まれるメールテンプレートの所定位置に対し、前記参照した前記個人情報を設定し電子メールを作成し、前記作成した電子メールを送信する
ことを特徴とする請求項１に記載の情報処理システム。
前記処理手段は、前記命令に含まれるメールテンプレートの宛先に対し、前記参照した前記個人情報の内のメールアドレスを設定し電子メールを作成し、前記作成した電子メールを送信する
ことを特徴とする請求項に記載の情報処理システム。
前記送信手段が送信する命令には個人情報編集処理に関する命令を含み、前記処理手段は、前記管理手段で管理される個人情報を編集する
ことを特徴とする請求項に記載の情報処理システム。
前記処理手段は、前記個人情報編集処理に関する命令に従い、前記管理手段で管理される個人情報の作成、更新、または変更を行う
ことを特徴とする請求項６に記載の情報処理システム。
前記命令には前記個人情報を利用するためのアクセス権限が含まれ、前記利用手段は、前記アクセス権限で指定された権限に従って前記個人情報を利用する
ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理システム。
前記アクセス権限には、少なくとも個人情報の作成権限、読み取り権限、更新権限、および削除権限のいずれかが含まれる
ことを特徴とする請求項８に記載の情報処理システム。
サーバ装置からウェブサービスの提供を受ける、個人情報を有する情報処理装置であって、
前記個人情報を管理する管理手段と、
前記サーバ装置に対して前記情報処理装置の登録を依頼する登録依頼手段と、
前記登録依頼手段による登録依頼を受けて前記サーバ装置から発行されたアクセストークンを利用して、前記サーバ装置に対してサービス提供依頼を送信する提供依頼手段と、
前記情報処理装置からのサービス提供依頼を受けて、前記サーバ装置で前記アクセストークンが認証された場合に、前記サーバ装置から送信される、前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令に従って、前記管理手段にて管理される前記個人情報を参照し、前記命令に従い参照した前記個人情報を用いて特定の処理を実行する処理手段と、
を備える
ことを特徴とする情報処理装置。
個人情報を有する情報処理装置に対して、ウェブサービスを提供するサーバ装置であって、
前記情報処理装置にて管理されている個人情報を利用する前記ウェブサービスを提供する提供手段と、
前記情報処理装置からの前記情報処理装置の登録依頼に応じて、アクセストークンを発行する発行手段と、
前記情報処理装置から前記アクセストークンを用いたサービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証手段と、
前記認証手段により前記アクセストークンが認証された場合、前記情報処理装置に対し前記提供手段による前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令を送信する送信手段と、
を備える
ことを特徴とするサーバ装置。
ウェブサービスを提供するサーバ装置から個人情報を有する情報処理装置に対して前記サービスを提供する情報処理方法であって、
前記情報処理装置から前記サーバ装置に対して、前記情報処理装置の登録を依頼する登録依頼工程と、
前記情報処理からの依頼に応じて、アクセストークンを、前記情報処理装置に対して発行する発行工程と、
前記登録工程で発行された前記アクセストークンを利用して、前記情報処理装置から前記サーバ装置に対して前記サービス提供依頼を送信する提供依頼工程と、
前記情報処理装置からサービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証工程と、
前記認証工程で前記アクセストークンが認証された場合、前記サーバ装置から前記情報処理装置に対し前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令を送信する送信工程と、
前記送信工程で送信された前記命令に従って、前記情報処理装置で管理されている前記個人情報を参照し、前記命令に従い参照した前記個人情報を用いて特定の処理を実行する処理工程と、
を有する
ことを特徴とする情報処理方法。
請求項１０に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム。
請求項１１に記載のサーバ装置の各手段としてコンピュータを機能させるためのプログラム。