(57)【特許請求の範囲】
【請求項１】
ウェブサービスを提供するサーバ装置から個人情報を有する情報処理装置に対して前記ウェブサービスを提供する情報処理システムであって、
前記サーバ装置は、
前記情報処理装置にて管理されている個人情報を利用する前記ウェブサービスを提供する提供手段と、
前記情報処理装置からの依頼に応じて、アクセストークンを発行する発行手段と、
前記情報処理装置からサービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証手段と、
前記認証手段により前記アクセストークンが認証された場合、前記情報処理装置に対し前記提供手段による前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令を送信する送信手段と、
を備え、
前記情報処理装置は、
前記個人情報を管理する管理手段と、
前記サーバ装置に対して前記情報処理装置の登録を依頼する登録依頼手段と、
前記発行手段により発行された前記アクセストークンを利用して、前記サーバ装置に対して前記サービス提供依頼を送信する提供依頼手段と、
前記サーバ装置の前記送信手段から送信された前記命令に従い前記管理手段にて管理される前記個人情報を参照し、前記命令に従い参照した前記個人情報を用いて特定の処理を実行する処理手段と、
を備え、
前記送信手段が送信する命令にはメール送信処理に関する命令が含まれ、前記処理手段は、前記命令に含まれるメールテンプレートの所定位置に対し、前記参照した前記個人情報を設定し電子メールを作成し、前記作成した電子メールを送信する
ことを特徴とする情報処理システム。
【請求項２】
前記認証手段が、前記提供依頼手段からの前記アクセストークンが前記発行手段で発行したアクセストークンであると判定した場合、前記送信手段は、前記命令を前記情報処理装置に対して送信する
ことを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記認証手段は、前記提供依頼手段からの前記アクセストークンが前記発行手段で発行したアクセストークンでないと判定した場合、前記情報処理装置にエラーを送信し、前記処理手段は、前記認証手段によりエラーが送信された場合、前記個人情報を用いて前記特定の処理を実行しない
ことを特徴とする請求項１または２に記載の情報処理システム。
【請求項４】
前記処理手段は、前記命令に含まれるメールテンプレートの宛先に対し、前記参照した前記個人情報の内のメールアドレスを設定し電子メールを作成し、前記作成した電子メールを送信する
ことを特徴とする請求項１〜３のいずれか１項に記載の情報処理システム。
【請求項５】
前記送信手段が送信する命令には個人情報編集処理に関する命令を含み、前記処理手段は、前記管理手段で管理される個人情報を編集する
ことを特徴とする請求項１〜４のいずれか１項に記載の情報処理システム。
【請求項６】
前記処理手段は、前記個人情報編集処理に関する命令に従い、前記管理手段で管理される個人情報の作成、更新、または変更を行う
ことを特徴とする請求項５に記載の情報処理システム。
【請求項７】
前記命令には前記個人情報を利用するためのアクセス権限が含まれ、前記処理手段は、前記アクセス権限で指定された権限に従って前記個人情報を利用する
ことを特徴とする請求項１〜６のいずれか１項に記載の情報処理システム。
【請求項８】
前記アクセス権限には、少なくとも個人情報の作成権限、読み取り権限、更新権限、および削除権限のいずれかが含まれる
ことを特徴とする請求項７に記載の情報処理システム。
【請求項９】
サーバ装置からウェブサービスの提供を受ける、個人情報を有する情報処理装置であって、
前記個人情報を管理する管理手段と、
前記サーバ装置に対して前記情報処理装置の登録を依頼する登録依頼手段と、
前記登録依頼手段による登録依頼を受けて前記サーバ装置から発行されたアクセストークンを利用して、前記サーバ装置に対してサービス提供依頼を送信する提供依頼手段と、
前記情報処理装置からのサービス提供依頼を受けて、前記サーバ装置で前記アクセストークンが認証された場合に、前記サーバ装置から送信される、前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令に従って、前記管理手段にて管理される前記個人情報を参照し、前記命令に従い参照した前記個人情報を用いて特定の処理を実行する処理手段と、
を備え、
前記命令にはメール送信処理に関する命令が含まれ、前記処理手段は、前記命令に含まれるメールテンプレートの所定位置に対し、前記参照した前記個人情報を設定し電子メールを作成し、前記作成した電子メールを送信する
ことを特徴とする情報処理装置。
【請求項１０】
個人情報を有する情報処理装置に対して、ウェブサービスを提供するサーバ装置であって、
前記情報処理装置にて管理されている個人情報を利用する前記ウェブサービスを提供する提供手段と、
前記情報処理装置からの前記情報処理装置の登録依頼に応じて、アクセストークンを発行する発行手段と、
前記情報処理装置から前記アクセストークンを用いたサービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証手段と、
前記認証手段により前記アクセストークンが認証された場合、前記情報処理装置に対し前記提供手段による前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令を送信する送信手段と、
を備え、
前記送信手段が送信する命令にはメール送信処理に関する命令が含まれる
ことを特徴とするサーバ装置。
【請求項１１】
ウェブサービスを提供するサーバ装置から個人情報を有する情報処理装置に対して前記サービスを提供する情報処理システムの制御方法であって、
前記情報処理装置から前記サーバ装置に対して、前記情報処理装置の登録を依頼する登録依頼工程と、
前記情報処理装置からの依頼に応じて、アクセストークンを、前記情報処理装置に対して発行する発行工程と、
前記発行工程で発行された前記アクセストークンを利用して、前記情報処理装置から前記サーバ装置に対してサービス提供依頼を送信する提供依頼工程と、
前記情報処理装置から前記サービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証工程と、
前記認証工程で前記アクセストークンが認証された場合、前記サーバ装置から前記情報処理装置に対し前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令を送信する送信工程と、
前記送信工程で送信された前記命令に従って、前記情報処理装置で管理されている前記個人情報を参照し、前記命令に従い参照した前記個人情報を用いて特定の処理を実行する処理工程と、
を有し、
前記送信工程で送信する命令にはメール送信処理に関する命令が含まれ、前記処理工程は、前記命令に含まれるメールテンプレートの所定位置に対し、前記参照した前記個人情報を設定し電子メールを作成し、前記作成した電子メールを送信する
ことを特徴とする情報処理システムの制御方法。
【請求項１２】
請求項９に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム。
【請求項１３】
請求項１０に記載のサーバ装置の各手段としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、情報処理装置、サーバ装置、情報処理システムの制御方法、及びプログラムに関する。特に、ＩｏＴデバイスからのＲＥＳＴサービス呼び出しの際の個人情報保護方法に関する。
【背景技術】
【０００２】
近年ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）が注目されているが、インターネットと通信するＩｏＴデバイスが増えるにつれ、ＩｏＴにサービスを提供するクラウド上のサーバーが個人情報を利用する機会が増えている。そのため、クラウド上のＩｏＴにサービスを提供するサーバーについては、個人情報の流出防止が重要になる。そこで、特許文献１には、機密性の高いデータをデータ処理サービス側サーバー上へ置かなくてよく、高いデータセキュリティを確保することを目的とするシステムが提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−３５２６３４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ＩｏＴにサービスを提供する場合の個人情報漏洩リスクは、そもそもＩｏＴにサービスを提供するサーバー側に個人情報を集積することに起因する。例えば、ＲＥＳＴ  ＡＰＩ実行の結果個人情報を利用する場合、個人情報（メールアドレス、ユーザー名等）を、サービス側に保持する必要がある。すなわち、サービス側がＩｏＴデバイスのＲＥＳＴ  ＡＰＩ実行の結果ユーザーにメール送信する場合など、サービス側に個人情報を登録しておく必要がある。その際、サービス側に個人情報を登録するためには、ネットワークを介して個人情報をやり取りしなければならない。
【０００５】
この場合、サービス側での個人情報の保持は、サーバーへの悪意ある攻撃などにより、情報漏洩のリスクがある。しかしながら、メール送信機能を有するＩｏＴデバイスであれば、サービス側からの要請により、自身の持つ情報を元にＩｏＴデバイスからメール送信することができる。なお、この場合は、メールアドレスをサービス側に持つ必要はない。例えば、ユースケースとしては、ブラウザーや表示装置を持たないＩｏＴデバイスのＲＥＳＴ  ＡＰＩ呼び出しや、ＩｏＴデバイスの定期的なジョブ実行に伴うＲＥＳＴ  ＡＰＩ呼び出し（操作者がデバイスの近くにいない場合）などが挙げられる。
【０００６】
さらに、公共の場にあるＩｏＴ端末内の個人情報の扱いをセキュアにしたい場合、例えば、オフィスや公共の場にあるデバイス内の個人情報のアクセス（追加、編集、参照、消去）に際しては、何等かの認証、検証が必要となる。その際、外部端末から編集可能項目を参照し、編集項目の（追加、編集、参照、消去）を行うが、クラウドサービスのポリシーに従って編集項目を制御したい場合、デバイスのみの認証では編集項目の制御ができない。
【０００７】
本発明は、上記課題を鑑みて、ＩｏＴにサービスを提供するクラウド上のサーバー（サーバ装置）に個人情報を集積せず、ＩｏＴデバイス（情報処理装置）側にセキュアに保持された個人情報を利用することができる情報処理システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明の情報処理システムは、ウェブサービスを提供するサーバ装置から個人情報を有する情報処理装置に対して前記ウェブサービスを提供する情報処理システムであって、前記サーバ装置は、前記情報処理装置にて管理されている個人情報を利用する前記ウェブサービスを提供する提供手段と、前記情報処理装置からの依頼に応じて、アクセストークンを発行する発行手段と、前記情報処理装置からサービス提供依頼を受けて、前記情報処理装置から送信された前記アクセストークンを認証する認証手段と、前記認証手段により前記アクセストークンが認証された場合、前記情報処理装置に対し前記提供手段による前記ウェブサービスを提供するに伴い、前記個人情報を利用する命令を送信する送信手段と、を備え、前記情報処理装置は、前記個人情報を管理する管理手段と、前記サーバ装置に対して前記情報処理装置の登録を依頼する登録依頼手段と、前記発行手段により発行された前記アクセストークンを利用して、前記サーバ装置に対して前記サービス提供依頼を送信する提供依頼手段と、前記サーバ装置の前記送信手段から送信された前記命令に従い前記管理手段にて管理される前記個人情報を参照し、前記命令に従い参照した前記個人情報を用いて特定の処理を実行する処理手段と、を備え、前記送信手段が送信する命令にはメール送信処理に関する命令が含まれ、前記処理手段は、前記命令に含まれるメールテンプレートの所定位置に対し、前記参照した前記個人情報を設定し電子メールを作成し、前記作成した電子メールを送信することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ＩｏＴにサービスを提供するクラウド上のサーバーに個人情報を集積せず、ＩｏＴデバイス側にセキュアに保持された個人情報を利用することができる情報処理システムを提供することができる。従って、ＩｏＴにサービスを提供するクラウド上のサーバーにそもそも個人情報を集積せず、ＩｏＴデバイス側にセキュアに保持された個人情報を利用する。これにより、従来のＲＥＳＴ  ＡＰＩサービスと同等の機能をユーザーに提供するようなＲＥＳＴ  ＡＰＩサービスを実現することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態に係るシステム構成図である。
【図２】各装置のハードウェア構成図である。
【図３】各装置のモジュール構成図である。
【図４】Ｗｅｂ  ＡＰＩサーバーへのＩｏＴデバイスの登録シーケンス図である。
【図５】ＩｏＴデバイスのメール送信処理のシーケンス図である。
【図６】個人情報アクセス要求シーケンス図である。
【図７】ＩｏＴデバイスの個人情報編集処理のシーケンス図である。
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための最良の形態について図面などを参照して説明する。
【００１２】
（第１実施形態）
本実施形態では、インターネット上でＲＥＳＴ  ＡＰＩによりウェブサービスを提供するＷｅｂ  ＡＰＩサーバーにＩｏＴデバイスを登録し、その登録結果をＩｏＴデバイスのユーザーに電子メールを用いて通知するようなサービスを想定している。また、ＲＥＳＴ  ＡＰＩサーバーがＲＥＳＴ  ＡＰＩの処理結果と共にＩｏＴデバイスの個人情報を利用するような、Ｗｅｂ  ＡＰＩサーバーによる、ＩｏＴデバイス内のセキュアストレージ内の個人情報を編集可能にするようなサービスを想定している。なお、本実施形態に係るＷｅｂ  ＡＰＩサーバーが提供するサービスは、これに限定することなく、様々なサービスを実装するＷｅｂ  ＡＰＩサーバー全てに適用可能である。
【００１３】
本実施形態では、ＲＥＳＴ  ＡＰＩ（ウェブサービス）実行の結果ユーザーの個人情報を利用するようなＲＥＳＴ  ＡＰＩ実行において、インターネット上のＷｅｂ  ＡＰＩサーバー側に個人情報を置かない。これにより、サーバー側の情報管理不備による漏洩、個人情報がＷｅｂ  ＡＰＩサーバー、ＩｏＴデバイス間に流れる際のスキミング、Ｍａｎ  ｉｎ  ｔｈｅ  ｍＩＤｄｌｅ攻撃等を回避する。また、ＩｏＴデバイス内の個人情報は、ＴＰＭなどの耐タンパー性を有するハードウェア等により、十分に保護されるものとする。なお、ＩｏＴデバイスの個人情報を利用するようなＲＥＳＴ  ＡＰＩサービスは、ＩｏＴデバイスの登録結果通知サービスに限られるものではない。さらに、本実施形態における権限の移譲ではＯＡｕｔｈの仕組みを利用する。ＯＡｕｔｈでは、ユーザーから移譲された権限の証明するための情報として、トークンと呼ばれる情報を利用する。
【００１４】
［ＩｏＴデバイスがメール送信を伴うＲＥＳＴ  ＡＰＩ呼び出しを行う場合］
本実施形態に係るＲＥＳＴ  ＡＰＩサービスシステム（情報処理システム）は、図１に示すような構成のネットワーク上に実現される。ＲＥＳＴ  ＡＰＩサービスシステムは、ＷＡＮ１００と、ＬＡＮ１０１と、ＬＡＮ１０２と、クライアントＩｏＴデバイス２００と、Ｗｅｂ  ＡＰＩサーバー３００と、ＩｏＴデバイス設定用ＰＣ４００と、Ｗｅｂ  ＡＰＩサーバー設定用ＰＣ５００を含む。ＷＡＮ１００は、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋであり、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１およびＬＡＮ１０２は、各構成要素を接続するＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋである。
【００１５】
クライアントＩｏＴデバイス２００は、ＬＡＮ１０１に存在するデバイスであり、ユーザーが操作、あるいは自律的に動作するＩｏＴデバイスである。ＩｏＴデバイスには、Ｗｅｂブラウザーや、Ｗｅｂ  ＡＰＩを呼び出す専用クライアントアプリケーションや、セキュアに個人情報を保存するストレージや、ＲＳＡ暗号演算、ＲＳＡ鍵ペア（公開鍵と秘密鍵）の生成やＳＨＡ−１ハッシュ演算などの機能を有する。また、チップ内で暗号化・復号、デジタル署名の生成・検証、プラットフォームの完全性検証を行うことができるＴＰＭ（業界団体ＴＣＧ（Ｔｒｕｓｔｅｄ  Ｃｏｍｐｕｔｉｎｇ  Ｇｒｏｕｐ）が仕様策定）チップが存在する。ユーザーは、Ｗｅｂブラウザーや専用アプリケーションを用いて、Ｗｅｂ  ＡＰＩサーバー３００にアクセスし、さらにセキュアストレージ内の個人情報を用いてＷｅｂ  ＡＰＩを利用する。ＩｏＴデバイス設定用ＰＣ４００は、クライアントＩｏＴデバイス２００と同様にＬＡＮ１０１に存在するＰＣであり、クライアントＩｏＴデバイス２００内の個人情報や、その編集要求について設定を行う。
【００１６】
Ｗｅｂ  ＡＰＩサーバー（サーバ装置）３００は、ＬＡＮ１０２に存在するサーバーであり、クライアントＩｏＴデバイス２００からのＷｅｂ  ＡＰＩリクエスト（サービス提供依頼）に応じて、各種サービス提供を行う。例えば、各種サービスは、印刷サービスや帳票サービスといったサービスである。Ｗｅｂ  ＡＰＩサーバー設定用ＰＣ５００は、Ｗｅｂ  ＡＰＩサーバー３００と同様にＬＡＮ１０２に存在するＰＣであり、Ｗｅｂ  ＡＰＩサーバー３００内の個人情報に関わるパラメーターを設定する。
【００１７】
また、クライアントＩＯＴデバイス２００、Ｗｅｂ  ＡＰＩサーバー３００は、それぞれＷＡＮネットワーク１００およびＬＡＮ１０１、ＬＡＮ１０２を介して接続されている。なお、クライアントＩＯＴデバイス２００およびそれぞれのサービスは、それぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また、同一のＰＣ上に構成されていてもよい。
【００１８】
図２は、本実施形態に係るクライアントＩＯＴデバイス２００のハードウェア構成を示すブロック図である。なお、Ｗｅｂ  ＡＰＩサーバー３００のサーバーコンピューター、ＩｏＴデバイス設定用ＰＣ４００、Ｗｅｂ  ＡＰＩサーバー設定用ＰＣ５００の構成も同様である。図２に示されるハードウェアブロック図は、一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のクライアントＩＯＴデバイス２００およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。
【００１９】
図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、または外部メモリ２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここで、ＯＳとは、コンピュータ上で稼動するオペレーティングシステムの略語であり、以下、オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理は、このプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。本実施形態では、ＲＯＭ２０３は、フォントＲＯＭ、プログラムＲＯＭ、データＲＯＭを含むが、これに限定せず、まとめて１つのＲＯＭとしてもよく、他の機能別にＲＯＭを含んでもよい。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は、各種データを記憶するハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）等外部メモリ２１１におけるデータアクセスを制御する。ＮＣ２１２は、ネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。なお、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は、外部メモリ２１１にインストールされたアプリケーションプログラムである。各構成要素は、バス２０４によりそれぞれ通信可能に接続される。
【００２０】
図３は、本実施形態に係る、クライアントＩＯＴデバイス２００、Ｗｅｂ  ＡＰＩサーバー３００の、それぞれのモジュール構成を示す図である。クライアントＩＯＴデバイス２００は、ＣＰＵ２０１がＲＯＭ２０３または外部メモリ２１１に記憶されたＯＳを実行することで各アプリケーションを制御する。ＯＳ２１０は、一般的には、リアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用される。クライアントＩＯＴデバイス２００は、ＷＷＷを利用するためのユーザーエージェントであるＲＥＳＴクライアントモジュール２２０を備える。また、ＩｏＴデバイス２００は、自身の中にセキュアＤＢモジュール２３０を有する。セキュアＤＢモジュール２３０は、業界団体Ｔｒｕｓｔｅｄ  Ｃｏｍｐｕｔｉｎｇ  Ｇｒｏｕｐ（ＴＣＧ）が標準仕様を策定するＴＰＭチップと、ＴＰＭチップに格納された暗号鍵情報で暗号化した個人情報データベースから構成される。
【００２１】
ＴＰＭチップは、ＩｏＴデバイス２３０に装着され、セキュリティー関連の処理機能を実装したＬＳＩチップである。セキュリティー関連の処理機能とは、具体的には、ＲＳＡ暗号などのエンコード、デコード機能、公開鍵、暗号鍵の鍵ペアの生成、ＳＨＡ１などのハッシュ値計算、デジタル署名の生成、検証などの機能を指す。また、内蔵する不揮発性メモリに生成した値を安全に格納、管理する機能も有する。また、ＴＰＭチップは、耐タンパー性を有し、内部を解析して情報を読みだそうとすると物理的に破損して読み出しを不可能にする機能も有する。セキュアＤＢモジュール２３０は、ＴＰＭチップ内の暗号鍵を用いて後述する個人情報を保持することができる。
【００２２】
ＩｏＴデバイス２００は、後述のクライアント登録シーケンスを用いて後述のＷｅｂ  ＡＰＩサーバー３００に自身をデバイス登録するためのクライアント登録依頼モジュール２６０を有する。メール送信モジュール２４０は、後述するデバイスステータス情報送信依頼ＲＥＳＴ  ＡＰＩ処理の結果、ＩｏＴデバイス２００のセキュアＤＢモジュール２３０内に存在するメールアドレスなどの個人情報を用いて機能するモジュールである。該メール送信モジュール２４０は、電子メール送信プロトコルとしてＳＭＴＰを用いるＳＭＴＰクライアント機能を有し、また送信先ＳＭＴＰサーバーは、予め設定されているものとする。なお、ユーザーが送信先となるＳＭＴＰサーバーの設定を変更することは適宜可能である。個人情報編集モジュール２５０は、後述する個人情報編集依頼ＲＥＳＴ  ＡＰＩ処理の結果、ＩｏＴデバイス２００のセキュアＤＢモジュール２３０内に存在する個人情報を処理するモジュールである。
【００２３】
本実施形態では、２つのＷｅｂ  ＡＰＩサーバー対応モジュールであるメール送信モジュール２４０と個人情報編集モジュール２５０をＩｏＴ デバイス２００が有する。しかしながら、前述の通り、様々なＷｅｂ  ＡＰＩに対応可能であるためＩｏＴデバイス２００が備えるモジュールは、これらに限定されない。
【００２４】
Ｗｅｂ  ＡＰＩサーバー３００は、ＣＰＵ２０１がＲＯＭ２０３、または外部メモリ２１１に記憶されたＯＳを実行する事で各アプリケーションを制御する。ＯＳ３１０は、一般的にはＬｉｎｕｘ（登録商標）等の汎用ＯＳであってよい。また、Ｗｅｂ  ＡＰＩサーバー３００は、ＲＥＳＴサーバーモジュール３２０を有する。そして、ＲＥＳＴサーバーモジュール３２０は、ＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０からのＲＥＳＴ要求を受信し、その要求を処理した上で後述するＪＳＯＮ形式のＲＥＳＴレスポンスを返す機能を有する。また、Ｗｅｂ  ＡＰＩサーバー３００は、認証トークンの管理、検証を行う認証モジュール３３０と、デバイス登録データ、トークンデータを管理、保持するＤＢモジュール３４０とを有する。Ｗｅｂ  ＡＰＩサーバー３００のクライアント登録モジュール３５０は、ＩｏＴデバイス２００のクライアント登録依頼モジュール２６０からの要求を受ける。そして、Ｗｅｂ  ＡＰＩサーバー３００上のＤＢモジュール３４０にＩｏＴデバイスのデバイスＩＤなどのＩｏＴデバイス情報を登録するクライアント登録機能を有する。
【００２５】
［デバイス登録］
図４は、本実施形態に係る、Ｗｅｂ  ＡＰＩサーバー３００へのＩｏＴデバイス２００の登録のシーケンスを示す図である。本シーケンスは、ＩｏＴデバイス２００のクライアント登録依頼モジュール２６０がクライアント登録依頼を行うことで開始される。本実施形態では、Ｗｅｂ  ＡＰＩサーバー３００のＲＥＳＴエンドポイントのＵＲＬは、ＩｏＴデバイス２００のＲＥＳＴクライアントモジュール２２０が保持している。しかしながら、これに限定することなく、ＩｏＴデバイス２００内のセキュアＤＢモジュール２３０、外部メモリ２１１などに保持してもよく、外部入力可能であれば、外部から入力してもよい。ここで、表１を用いて、ＩｏＴデバイス２００のセキュアＤＢモジュール２３０内に存在するデバイス関連情報テーブルについて説明する。
【表１】
0006736305.tif 000002
【００２６】
表１は、デバイス関連情報テーブルであり、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"
}
【００３０】
上記クライアント登録ＡＰＩを受信したＷＥＢ  ＡＰＩサーバー３００のＲＥＳＴサーバーモジュール３２０は、クライアント登録ＡＰＩの引数をデバイス登録テーブル（表２）に保存する（ステップＳ４０４）。すなわち、引数であるデバイスＩＤ、テナントＩＤ、ＩｏＴデバイス２００で生成した公開鍵を、デバイス登録データ、トークンデータを、管理、保持するＤＢモジュール３４０のデバイス登録テーブル（表２）に保存する。ここで、表２を用いて、ＷＥＢ  ＡＰＩサーバー３００のＤＢモジュール３４０内に存在するデバイス登録テーブルについて説明する。
【表２】
0006736305.tif 000003
【００３１】
デバイス登録テーブル（表２）は、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の値を比較する。そして、登録済みのＩｏＴデバイスからのＲＥＳＴ  ＡＰＩ呼び出しかどうか判定する（ステップＳ５０３）。この判定が異常であれば、ＲＥＳＴ  ＡＰＩ呼び出しに対してエラーを返す。
【００３９】
検証モジュールのアクセストークン検証処理が正常であれば（ステップＳ５０３）、ＲＥＳＴサーバーモジュール３２０は、クライアントステータスを取得し、メール送信のためのメール文面テンプレートと、パラメーターを取得する。表３、表４を用いて、Ｗｅｂ  ＡＰＩサーバー３００内に存在する、ＲＥＳＴ  ＡＰＩ応答コマンドテーブル、ＲＥＳＴ  ＡＰＩ応答コマンドパラメーターテーブルについて説明する。
【表３】
0006736305.tif 000004
【表４】
0006736305.tif 000005
【００４０】
ＲＥＳＴ  ＡＰＩパラメーターテーブル（表３）は、以下のカラムを有する。すなわち、予め設定されたデバイスの所属するテナントを格納する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”を取り出す。さらに、ＩｏＴデバイス２２０のセキュアＤＢモジュール２３０に保存される表５に示す個人情報テーブル１を参照する。
【表５】
0006736305.tif 000006
【００４８】
個人情報テーブル１（表５）は、以下のカラムを有する。すなわち、個人情報項目を表す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の値を比較する。この判定が異常であれば、ＲＥＳＴ  ＡＰＩ呼び出しに対してエラーを返す。
【表６】
0006736305.tif 000007
【００６０】
ＲＥＳＴ  ＡＰＩ応答コマンドパラメーターテーブル２（表６）は、以下のカラムを有する。つまり、表３の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”）を結合する。そして、ハッシュ値１とハッシュ値２を比較して、ハッシュ値比較を行う。もし、ハッシュ値比較の結果が同じであれば、個人情報アクセス要求ＯＫの応答を行う（ステップＳ７０７）。そして、個人情報へアクセスを行う（ステップＳ７０８）。もし、ハッシュ値比較の結果が不一致であれば、個人情報アクセス要求に対してエラーの応答を行う。
【００７２】
以上、本実施形態によれば、ＲＥＳＴ  ＡＰＩ実行の結果ユーザーの個人情報を利用するようなＲＥＳＴ  ＡＰＩ実行において、サーバー側に個人情報を置かないことで、サーバー側の情報管理不備、情報漏洩等を解消することができる。また、個人情報をみだりにネットワークに流さないことで、Ｍａｎ  ｉｎ  ｔｈｅ  ｍＩＤｄｌｅなどの攻撃にも対処できる。また、クライアントデバイス側の個人情報は（ＴＰＭなどにより）十分に保護される。さらに、クラウド側は、ユーザー個人情報に紐付かない処理を行い、デバイス側は、ユーザー個人情報に紐付く処理を行う。この２つをオーバーレイしてＲＥＳＴ  ＡＰＩ処理を行うことで、サーバー側に個人情報を置くことなく、サーバー側情報と個人情報を合わせたサービスを行うことができる。
【００７３】
（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００７４】
また、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。
【図１】
0006736305.tif 000008
【図２】
0006736305.tif 000009
【図３】
0006736305.tif 000010
【図４】
0006736305.tif 000011
【図５】
0006736305.tif 000012
【図６】
0006736305.tif 000013
【図７】
0006736305.tif 000014