JP2021196734A - 期限管理システム、及び期限管理方法 - Google Patents

Abstract

【課題】多数のクライアント装置を備える場合であっても、それぞれの電子証明書の有効期限を適切に管理することができる期限管理システム及び期限管理方法を提供する。【解決手段】通信システム１は、有効期限が設定された有期情報を記憶する複数のデバイスと、有期情報における期限管理を行う更新管理サーバ３０と、複数のデバイスのそれぞれと更新管理サーバ３０との通信を仲介するＭＱＴＴブローカ４０と、を備える。複数のデバイスのそれぞれは、自身が記憶する有期情報の期限管理に関する通知の受信をＭＱＴＴブローカ４０に依頼する。更新管理サーバ３０は、有期情報における期限管理に関する通知をＭＱＴＴブローカ４０に送信する。ＭＱＴＴブローカ４０は、更新管理サーバ３０から受信した通知において期限管理の対象となる有期情報を記憶するデバイスに、当該通知を配信する。【選択図】図１

Description

本発明は、期限管理システム、及び期限管理方法に関する。

ＩｏＴ（Internet of Things）の分野において、複数のクライアント装置からサーバ装置にデータを集約するシステムがある。クライアント装置からサーバ装置に送信されるデータのセキュリティを強化するため、電子証明書や公開鍵、秘密鍵、共通鍵などの暗号鍵を用いて、サーバ装置とクライアント装置の間で認証や暗号化通信を行う技術がある。このような電子証明書には有効期限が設定される場合がある。この場合、有効期限が切れた証明書を有するクライアント装置がサーバ装置から認証を得られないようにしてセキュリティの低下を抑止することが可能となる。特許文献１では、電子証明書の有効期限に応じて、有効期限を更新する技術が開示されている。

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

しかしながら、データを集約するシステムにおいては、サーバ装置に多数のクライアント装置が接続される場合が多い。このため、多数のクライアント装置のそれぞれについて電子証明書の有効期限を管理しなくてはならない。この対策として、例えば、電子証明書の有効期限を管理する専用のサーバ（以下、管理サーバという）を用いて、クライアント装置のそれぞれの電子証明書の有効期限を更新することが考えられる。この場合、管理サーバが多数の電子証明書の有効期限を個別に管理しようとすると処理が煩雑となり過ぎるため現実的でない。管理サーバが多数の電子証明書の有効期限を一斉に更新させようとするとシステム内の通信の負担が増大してしまう。また、電子証明書の有効期限を無期限とすることも考えられるが、セキュリティの技術は日進月歩のため、いつかは暗号が解読されてしまうことがあり得るためセキュリティ上のリスクとなる可能性が高い。クライアント装置の管理者やユーザー等が有効期限を「人力」で管理し、有効期限が近い電子証明書を手動で更新することも考えられるが管理対象のクライアント装置が多くなるにつれて、人件費や人為ミスが増えると考えられる。

本発明は、このような状況に鑑みてなされたものである。本発明の目的は、多数のクライアント装置を備える場合であっても、それぞれの電子証明書の有効期限を適切に管理することができる期限管理システム、及び期限管理方法を提供することを目的とする。

本発明の、期限管理システムは、有効期限が設定された有期情報を記憶する複数のクライアント装置と、前記複数のクライアント装置のそれぞれが記憶する前記有期情報における期限管理を行う更新管理サーバと、前記複数のクライアント装置のそれぞれと前記更新管理サーバとの通信を仲介する通信処理サーバと、を備え、前記複数のクライアント装置のそれぞれは、自身が記憶する前記有期情報の期限管理に関する通知の受信を前記通信処理サーバに依頼し、前記更新管理サーバは、前記有期情報における期限管理に関する通知を前記通信処理サーバに送信し、前記通信処理サーバは、前記更新管理サーバから受信した通知と、前記複数のクライアント装置のそれぞれから依頼された内容とに基づいて、当該通知において期限管理の対象となる前記有期情報を記憶するクライアント装置に、当該通知を配信する。

本発明の、期限管理方法は、有効期限が設定された有期情報を記憶する複数のクライアント装置と、前記複数のクライアント装置のそれぞれが記憶する前記有期情報における期限管理を行う更新管理サーバと、前記複数のクライアント装置のそれぞれと前記更新管理サーバとの通信を仲介する通信処理サーバと、を備える期限管理システムの期限管理方法であって、前記複数のクライアント装置のそれぞれが、自身が記憶する前記有期情報の期限管理に関する通知の受信を前記通信処理サーバに依頼し、前記更新管理サーバが、前記有期情報における期限管理に関する通知を前記通信処理サーバに送信し、前記通信処理サーバが、前記更新管理サーバから受信した通知と、前記複数のクライアント装置のそれぞれから依頼された内容とに基づいて、期限管理の対象となる前記有期情報を記憶するクライアント装置に、前記更新管理サーバから受信した通知を配信する。

本発明によれば、多数のクライアント装置を備える場合であっても、それぞれの電子証明書の有効期限を適切に管理することができる。

本発明の実施形態による通信システム１の構成例を示すブロック図である。 本発明の実施形態による更新管理サーバ３０の構成例を示すブロック図である。 本発明の実施形態によるＭＱＴＴブローカ４０の構成例を示すブロック図である。 本発明の実施形態によるデバイス５０の構成例を示すブロック図である。 本発明の実施形態による証明書管理情報３２０の構成例を示す図である。 本発明の実施形態による更新通知情報３２１の構成例を示す図である。 本発明の実施形態によるトピック情報４２０の構成例を示す図である。 本発明の実施形態による通信システム１が行う処理の流れを示すシーケンス図である。 本発明の実施形態による通信システム１が行う処理を説明する図である。 本発明の実施形態による通信システム１が行う処理の流れを示すシーケンス図である。 本発明の実施形態による通信システム１が行う処理を説明する図である。 本発明の実施形態による通信システム１が行う処理を説明する図である。

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

図１は、本発明の実施形態による通信システム１の構成例を示すブロック図である。通信システム１は、例えば、クラウド１０と、認証局２０と、更新管理サーバ３０と、ＭＱＴＴブローカ４０と、複数のデバイス５０（デバイス５０−１、５０−２、…、５０−Ｎ）とを備える。Ｎは任意の自然数である。クラウド１０は、「サーバ装置」の一例である。デバイス５０は、「クライアント装置」の一例である。

クラウド１０と、認証局２０と、更新管理サーバ３０と、ＭＱＴＴブローカ４０と、デバイス５０とは、通信ネットワークＮＷを介して互いに通信可能に接続される。デバイス５０は、図示しない中継装置を介して、クラウド１０と通信するようにしてもよい。

クラウド１０は、データを集約するサーバ等のコンピュータ装置である。クラウド１０は、デバイス５０によりセンシングされたデータを受信（集約）する。デバイス５０によりセンシングされるデータは、任意のデータであってよいが、例えば、監視カメラ等による撮像データ、或いは、温度センサ等により測定された温度データなどである。

クラウド１０は、認証局２０によって発行された電子証明書（サーバ証明書）を記憶する。クラウド１０は、デバイス５０と通信する場合、まずデバイス５０との相互認証を行う。そして、クラウド１０は、デバイス５０が正当な装置であることが確認された場合に、デバイス５０とのデータのやりとりを行う。相互認証は、例えば、後述する電子証明書を用いて行われる。この場合、通信先の装置から送られてきた電子証明書を相互に検証し、電子証明書が改ざん等されていない場合に通信先の装置が正当であると判定する。

デバイス５０は、例えば、通信機能付きのセンサ端末である。デバイス５０は、センシングしたデータを、ＭＱＴＴブローカ４０を介してクラウド１０に送信する。ＭＱＴＴブローカ４０については後で詳しく説明する。デバイス５０は、認証局２０によって発行された電子証明書（クライアント証明書）を記憶する。デバイス５０は、クラウド１０と通信する場合、まずクラウド１０との相互認証を行い、クラウド１０が正当な装置であることが確認された場合に、通信を行う。

認証局２０は、電子証明書を発行するサーバ等のコンピュータ装置である。認証局２０は、電子証明書は、データの送受信に関わる装置が正当な装置であることを認証する電子的な情報である。電子証明書は、例えば、ＣＳＲ（Certificate Signing Request）と呼ばれる電子文書（証明書署名要求データ）に基づいて認証局２０により発行される電子署名付きの電子データである。電子証明書は、例えば、ＩＴＵ−Ｔ（International Telecommunication Union-Telecommunication sector、国際通信連合）の公開鍵基盤(ＰＫＩ（Public Key Infrastructure）)の規格であるｘ．５０９に基づいて、生成される（例えば、https://tools.ietf.org/html/rfc5280を参照）。

認証局２０は、外部装置からの要求に応じて電子証明書を発行する。ここでの外部装置は、主にクラウド１０、デバイス５０である。システムによって更新管理サーバ３０やＭＱＴＴブローカ４０が外部装置として機能してもよい。この場合、認証局２０は、更新管理サーバ３０やＭＱＴＴブローカ４０からの要求に応じて電子証明書を発行する。認証局２０は、外部装置から通知されたＣＳＲに応じた電子証明書を生成し、生成した電子証明書を外部装置に送付することにより、電子証明書を発行する。

更新管理サーバ３０は、電子証明書の期限管理を行うサーバ等のコンピュータ装置である。例えば、更新管理サーバ３０は、電子証明書の有効期限を管理し、現時点から所定の期間（例えば、１か月）以内に有効期限を迎える電子証明書を記憶しているデバイス５０に、電子証明書の更新を促す通知を行う。

更新管理サーバ３０は、例えば、認証局２０による電子証明書の発行を仲介し、発行された電子証明書のデータを記憶する。具体的に、更新管理サーバ３０は、デバイス５０からの証明書発行要求を受信し、受信した要求に基づいて、認証局２０に当該デバイス５０に電子証明書を発行するように依頼する。更新管理サーバ３０は、認証局２０から発行された電子証明書をデバイス５０に送信する。

更新管理サーバ３０は、認証局２０に電子証明書の発行を依頼する際、発行される電子証明書を管理するための情報を、ＣＳＲに含めるようにする。電子証明書を管理するための情報は、少なくとも発行される電子証明書を識別できる情報が含まれていればよく、例えば、要求元のデバイス５０（証明書発行要求をしたデバイス５０）の識別情報である。要求元のデバイス５０の識別情報としては、例えば、要求元のデバイス５０に対して個々に割り当てられるＵＵＩＤ（Universally Unique Identifier）における１２８ビットの識別子が考えられる。

以下の説明では、電子証明書を管理するための情報としてデバイス５０ごとに割り当てられるＵＵＩＤが用いられる場合を例に説明する。しかしながらこれに限定されることはない。電子証明書を管理するための情報は、電子証明書を識別できる情報が含まれていればよく、例えば、証明書が発行された日時、デバイス５０のシリアル番号、及びこれらを組み合わせたものであってもよい。

更新管理サーバ３０は、要求元のデバイス５０から電子証明書の発行要求を受信すると、ＵＵＩＤを含むＣＳＲを生成する。更新管理サーバ３０は、生成したＣＳＲを認証局２０に送信して電子証明書の発行を要求する。これによって、ＣＳＲを元とした電子証明書が認証局２０により発行される。更新管理サーバ３０は、第２電子文書を元とした電子証明書を認証局２０から受信する。

更新管理サーバ３０は、第２電子文書を元とした電子証明書を、ＵＵＩＤと共に要求元のデバイス５０に送信する。更新管理サーバ３０は、電子証明書に関する情報を、ＵＵＩＤに対応づけたものを、後述する証明書管理情報３２０として記憶する。電子証明書に関する情報は、特に電子証明書の期限に関するもの、例えば、電子証明書の発行日時、有効期限、更新時期などを示す情報である。ここで、電子証明書自体にＵＵＩＤが含まれている。このため、更新管理サーバ３０はＵＵＩＤを意識することなく電子証明書をデバイス５０に通知し、デバイス５０が通知された電子証明書からＵＵＩＤを取り出すようにしてもよい。

更新管理サーバ３０は、任意のタイミングで証明書管理情報３２０を参照し、更新を促す通知（以下、更新通知という）をするデバイス５０を抽出する。更新管理サーバ３０は、例えば、現時点から所定の期間内（例えば、１か月）以内に有効期限を迎える電子証明書を記憶しているデバイス５０を、更新通知を行う対象の装置として抽出する。更新管理サーバ３０は、ＵＵＩＤを含む更新通知を生成し、生成した更新通知をＭＱＴＴブローカ４０に通知する。

ＭＱＴＴブローカ４０は、装置間の通信を仲介するサーバ等のコンピュータ装置である。ここでの装置間の通信は、特に多数の装置同士の通信、例えばクラウド１０と複数のデバイス５０との通信、及び更新管理サーバ３０と複数のデバイス５０との通信を想定している。しかしながらこれに限定されない。ＭＱＴＴブローカ４０は、１対１の通信、例えば、更新管理サーバ３０とクラウド１０との通信を仲介してもよい。この場合にも、クラウド１０と複数のデバイス５０との通信の場合と同様の手法を適用することができる。

ＭＱＴＴブローカ４０は、ＭＱＴＴ（Message Queueing Telemetry Transport）プトロコル、特にパブリッシュ／サブスクライブ接続プロトコルにしたがった非同期通信を行う。ＭＱＴＴブローカ４０は、接続先の装置からトピックを指定したサブスクライブ（メッセージの受信登録）を受け付ける。トピックは、メッセージの内容を示す情報であって、例えば、「ｓｅｎｓｏｒ＿ｄａｔａ」、「ｃｏｎｆｉｇ＿ｃｈａｎｇｅ」等で示される。「ｓｅｎｓｏｒ＿ｄａｔａ」トピックは、センサによって測定されたデータ値がメッセージの内容であることを示す。「ｃｏｎｆｉｇ＿ｃｈａｎｇｅ」トピックは、センサのパラメータ変更がメッセージの内容であることを示す。

例えば、接続先の装置がクラウド１０である場合、ＭＱＴＴブローカ４０は、クラウド１０から「ｓｅｎｓｏｒ＿ｄａｔａ」トピックを指定したサブスクライブを受け付ける。つまり、クラウド１０は、「ｓｅｎｓｏｒ＿ｄａｔａ」トピックをＭＱＴＴブローカ４０にサブスクライブする。或いは、接続先の装置がデバイス５０である場合、ＭＱＴＴブローカ４０は、デバイス５０から「ｃｏｎｆｉｇ＿ｃｈａｎｇｅ」トピックを指定したサブスクライブを受け付ける。つまり、デバイス５０は、「ｃｏｎｆｉｇ＿ｃｈａｎｇｅ」トピックをＭＱＴＴブローカ４０にサブスクライブする。ＭＱＴＴブローカ４０は、トピックごとに、サブスクライブしてきた装置を記憶する。

ＭＱＴＴブローカ４０は、デバイス５０からセンサによって測定されたデータ値を受信すると、そのデータ値を「ｓｅｎｓｏｒ＿ｄａｔａ」トピックをサブスクライブした装置、つまりクラウド１０にパブリッシュ（配信）する。これにより、デバイス５０からの測定データが非同期にクラウド１０に送信される。また、ＭＱＴＴブローカ４０は、クラウド１０や図示しないメンテナンス装置からセンサパラメータの設定値や変更値を受信すると、その設定値や変更値を「ｃｏｎｆｉｇ＿ｃｈａｎｇｅ」トピックをサブスクライブした装置、つまりデバイス５０にパブリッシュする。

ここで、比較例としてデバイス５０からクラウド１０に直に測定データを送信する場合を考える。この場合、デバイス５０は、デバイス５０とクラウド１０との通信同期を確立させた上で、測定データを送信し、更に送信した測定データが正しく受信されたこと（例えば、Ａｃｋ）を待つなどの処理が必要となる。このため、測定データを送信する場合における処理負担が大きくなる傾向にある。さらに、１つのクラウド１０に対して複数のデバイス５０が接続する構成であれば、クラウド１０の処理負担も増大する傾向にあった。

これに対し、本実施形態では、デバイス５０は、クラウド１０が測定データを受信したか否かに関わらず、ＭＱＴＴブローカ４０に測定データを送信しておけば、測定データがクラウド１０に配信される。すなわち、ＭＱＴＴブローカ４０を仲介させることによって、クラウド１０とデバイス５０との双方の処理負担を軽減させている。

本実施形態では、このパブリッシュ／サブスクライブ接続プロトコルにしたがった非同期通信を、電子証明書の期限管理にも適用する。具体的に、ＭＱＴＴブローカ４０は、更新管理サーバ３０からデバイス５０に送信される更新通知を仲介する。

ＭＱＴＴブローカ４０は、デバイス５０から「ＵＵＩＤ−ａ／…／ｎｅｅｄ＿ｕｐｄａｔｅ」トピックを指定したサブスクライブを受け付ける。ここで「ＵＵＩＤ−ａ」は、特定のデバイス５０（例えば、デバイス５０−１）のＵＵＩＤである。つまり、デバイス５０−１は、「ＵＵＩＤ−ａ／…／ｎｅｅｄ＿ｕｐｄａｔｅ」トピックをＭＱＴＴブローカ４０にサブスクライブする。これにより、デバイス５０−１にＵＵＩＤ−ａに対応する電子証明書の更新通知に係るメッセージがパブリッシュ（配信）されるようになる。

同様に、ＭＱＴＴブローカ４０は、デバイス５０−２から「ＵＵＩＤ−ｂ／…／ｎｅｅｄ＿ｕｐｄａｔｅ」トピックを指定したサブスクライブを受け付ける。ここで「ＵＵＩＤ−ｂ」は、デバイス５０−２のＵＵＩＤである。これにより、デバイス５０−２にＵＵＩＤ−ｂに対応する電子証明書の更新通知に係るメッセージがパブリッシュ（配信）されるようになる。このように、複数のデバイス５０のそれぞれが、自身が記憶する電子証明書に対応するＵＵＩＤを含む更新通知に係るトピックをサブスクライブし、自身が記憶する電子証明書の更新通知がパブリッシュ（配信）されるようにする。これにより、更新管理サーバ３０とデバイス５０の双方の負担を増加させることなく、デバイス５０のそれぞれの電子証明書の有効期限を適切に管理することが可能である。

通信ネットワークＮＷは、例えば、インターネット、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、プロバイダ装置、無線基地局、専用回線などのうちの一部または全部を含む通信網である。

図２は、本発明の実施形態による更新管理サーバ３０の構成例を示すブロック図である。更新管理サーバ３０は、例えば、通信部３１と、記憶部３２と、制御部３３とを備える。通信部３１は、通信ネットワークＮＷを介して、認証局２０及びＭＱＴＴブローカ４０等と通信を行う。

記憶部３２は、記憶媒体、例えば、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）、ＲＡＭ（Random Access read/write Memory）、ＲＯＭ（Read Only Memory）、またはこれらの記憶媒体の任意の組み合わせによって構成される。

記憶部３２は、例えば、証明書管理情報３２０と、更新通知情報３２１とを記憶する。証明書管理情報３２０は、認証局２０により発行された電子証明書の期限を管理するための情報であり、例えば、電子証明書の発行日や有効期限を示す情報である。更新通知情報３２１は、更新通知に関する情報であり、例えば、更新通知を行った日時などを示す情報である。

制御部３３は、例えば、更新管理サーバ３０がハードウェアとして備えるＣＰＵ（Central Processing Unit）に、記憶部３２に記憶されたプログラムを実行させることによって実現される。制御部３３は、例えば、認証部３３０と、証明書管理部３３１と、更新通知部３３２と、装置制御部３３３とを備える。

認証部３３０は、認証に係る処理を行う。認証に係る処理は、通信先の装置を認証する処理であって、例えば、相互認証、或いは片側認証を行う処理である。認証部３３０は、例えば、デバイス５０から証明書の発行要求を受ける前に、デバイス５０と相互認証を行う。認証部３３０は、デバイス５０を認証した認証結果を証明書管理部３３１に出力する。

証明書管理部３３１は、デバイス５０に対して発行される電子証明書を管理する。証明書管理部３３１は、デバイス５０からの要求に応じて、認証局２０に電子証明書の発行を依頼する。例えば、証明書管理部３３１は、認証後のデバイス５０から公開鍵を取得する。また、証明書管理部３３１は、ＵＵＩＤを生成する。証明書管理部３３１は、公開鍵とＵＵＩＤとを含むＣＳＲを生成する。証明書管理部３３１は、生成したＣＳＲを認証局２０に送付して認証局２０に電子証明書の発行を依頼する。証明書管理部３３１は、認証局２０により発行された電子証明書を、認証局２０から受信する。証明書管理部３３１は、受信した電子証明書を、ＵＵＩＤと共にデバイス５０に送付する。証明書管理部３３１は、デバイス５０に送付した電子証明書に関する情報を生成し、生成した情報を、証明書管理情報３２０として記憶部３２に記憶させる。

更新通知部３３２は、更新通知を行う。更新通知部３３２は、任意のタイミングで証明書管理情報３２０を参照し、更新通知を行うデバイス５０を抽出する。更新通知部３３２は抽出したデバイス５０に対応づけられたＵＵＩＤを含む更新通知を生成し、生成した更新通知を、通信部３１を介してＭＱＴＴブローカ４０に送信する。更新通知部３３２は、送信した更新通知に関する情報を生成し、生成した情報を、更新通知情報３２１として記憶部３２に記憶させる。

装置制御部３３３は、更新管理サーバ３０を統括的に制御する。装置制御部３３３は、例えば、認証時において、デバイス５０から受信したデータを認証部３３０に出力する。装置制御部３３３は、認証局２０により発行された電子証明書を証明書管理部３３１に出力する。

図３は、本発明の実施形態によるＭＱＴＴブローカ４０の構成例を示すブロック図である。ＭＱＴＴブローカ４０は、例えば、通信部４１と、記憶部４２と、制御部４３とを備える。通信部４１は、通信ネットワークＮＷを介して、クラウド１０、更新管理サーバ３０、ＭＱＴＴブローカ４０、及びデバイス５０と通信する。

記憶部４２は、記憶媒体、例えば、ＨＤＤ、フラッシュメモリ、ＥＥＰＲＯＭ、ＲＡＭ、ＲＯＭ、またはこれらの記憶媒体の任意の組み合わせによって構成される。記憶部４２は、例えば、トピック情報４２０を記憶する。トピック情報４２０は、仲介するメッセージのトピックに対応づけられたサブスクライバを示す情報である。サブスクライバは、サブスクライブ（メッセージの受信を登録）した装置である。例えば、センサによる測定値を示すメッセージのトピックであれば、トピック情報４２０は、「ｓｅｎｓｏｒ＿ｄａｔａ」などを示す情報に、そのメッセージの受信を登録したクラウド１０が対応づけられた情報である。

制御部４３は、例えば、ＭＱＴＴブローカ４０がハードウェアとして備えるＣＰＵに、記憶部４２に記憶されたプログラムを実行させることによって実現される。制御部４３は、例えば、メッセージ処理部４３０と、装置制御部４３１とを備える。

メッセージ処理部４３０は、パブリッシュ／サブスクライブ接続プロトコルにしたがった非同期通信を行う。メッセージ処理部４３０は、サブスクライブされたトピックを、サブスクライバに対応づけた情報を、トピック情報４２０として記憶する。メッセージ処理部４３０は、パブリッシャからのメッセージを受信する。パブリッシャは、メッセージをパブリッシュする装置である。例えば、「ｓｅｎｓｏｒ＿ｄａｔａ」トピックに係るメッセージのパブリッシャはデバイス５０である。メッセージ処理部４３０は、パブリッシャから受信したメッセージのトピックを抽出し、抽出したトピックに基づいてトピック情報４２０を参照する。メッセージ処理部４３０は、抽出したトピックに対応づけられたサブスクライバに、当該メッセージをパブリッシュ（配信）する。

装置制御部４３１は、ＭＱＴＴブローカ４０を統括的に制御する。装置制御部４３１は、例えば、通信部４１によって受信されたメッセージをメッセージ処理部４３０に出力する。装置制御部４３１は、メッセージ処理部４３０によりパブリッシュ（配信）されるメッセージを、通信部４１を介して配信先の装置に送信する。

図４は、本発明の実施形態によるデバイス５０の構成例を示すブロック図である。デバイス５０は、例えば、通信部５１と、記憶部５２と、制御部５３とを備える。通信部５１は、通信ネットワークＮＷを介して、クラウド１０、更新管理サーバ３０、ＭＱＴＴブローカ４０等と通信を行う。

記憶部５２は、記憶媒体、例えば、ＨＤＤ、フラッシュメモリ、ＥＥＰＲＯＭ、ＲＡＭ、ＲＯＭ、またはこれらの記憶媒体の任意の組み合わせによって構成される。記憶部５２は、例えば、鍵情報５２０と、証明書情報５２１と、センサ情報５２２とを記憶する。鍵情報５２０は、相互認証、或いは暗号化通信などに用いられる暗号鍵に関する情報である。証明書情報５２１は、認証局２０によって発行された電子証明書に関する情報である。センサ情報５２２は、センサにより測定された測定データを示す情報である。

制御部５３は、例えば、デバイス５０がハードウェアとして備えるＣＰＵに、記憶部５２に記憶されたプログラムを実行させることによって実現される。制御部５３は、例えば、証明書要求部５３０と、認証部５３１と、受信登録部５３２と、センサ情報取得部５３３と、装置制御部５３４とを備える。

証明書要求部５３０は、電子証明書の発行を要求する。証明書要求部５３０は、例えば、デバイス５０の公開鍵の情報を更新管理サーバ３０に送信して電子証明書の発行を要求する。また、証明書要求部５３０は、認証局２０によって発行された電子証明書を更新管理サーバ３０から取得し、取得した電子証明書を示す情報を、証明書情報５２１として、記憶部５２に記憶させる。また、証明書要求部５３０は、更新管理サーバ３０から電子証明書と共に送信されたＵＵＩＤを取得し、取得したＵＵＩＤを受信登録部５３２に出力する。

認証部５３１は、認証に係る処理を行う。認証部５３１が行う処理は、認証部３３０と同様であるためその説明を省略する。認証部５３１は、例えば、証明書要求部５３０による要求が行われた際に、更新管理サーバ３０と相互認証を行う。

受信登録部５３２は、更新通知に係るメッセージの受信を登録する。受信登録部５３２は、証明書要求部５３０からＵＵＩＤを取得し、取得したＵＵＩＤを含む更新通知のトピックをＭＱＴＴブローカ４０にサブスクライブする。

センサ情報取得部５３３は、センサによって測定された測定データを取得し、取得した測定データを、センサ情報５２２として記憶部５２に記憶させる。装置制御部５３４は、デバイス５０を統括的に制御する。装置制御部５３４は、例えば、センサによって測定された測定データをセンサ情報取得部５３３に出力する。装置制御部５３４は、ＭＱＴＴブローカ４０により更新通知がパブリッシュ（配信）された場合、当該更新通知を証明書要求部５３０に出力する。この場合、証明書要求部５３０は、電子証明書の有効期限を更新させる要求（以下、更新要求ともいう）を、更新管理サーバ３０を介して認証局２０に依頼する。

図５は、本発明の実施形態による証明書管理情報３２０の構成例を示す図である。証明書管理情報３２０は、例えば、証明書ＩＤ、ＵＵＩＤ、発行要求受信日、発行日、有効期限などの項目を備える。証明書ＩＤは、電子証明書を一意に識別する識別情報である。ＵＵＩＤは、証明書ＩＤにより特定される電子証明書の期限を管理するための情報であって、例えば、証明書を要求したデバイス５０ごとにユニークに割り当てられた情報である。発行要求受信日は、デバイス５０から証明書を要求する通知が受信された日である。発行日は、認証局２０によって証明書が発行された日である。有効期限は、証明書の有効期限である。

図６は、本発明の実施形態による更新通知情報３２１の構成例を示す図である。更新通知情報３２１は、例えば、証明書ＩＤ、ＵＵＩＤ、更新通知日、更新要求受信日などの項目を備える。証明書ＩＤ、ＵＵＩＤは、証明書管理情報３２０における証明書ＩＤ、ＵＵＩＤと同様である。更新通知日は、更新通知を行った日を示す情報である。更新要求受信日は、デバイス５０から更新要求がなされた日を示す情報である。

図７は、本発明の実施形態によるトピック情報４２０の構成例を示す図である。トピック情報４２０は、例えば、トピックＩＤ、トピックなどの項目を備える。トピックＩＤは、トピックを一意に識別する識別情報である。トピックは、トピックＩＤで特定されるトピックの内容を示す情報である。この例では、トピックＩＤ（１）はデバイス５０−１が記憶する電子証明書の更新通知に係るメッセージであることが示されている。トピックＩＤ（２）はデバイス５０−２が記憶する電子証明書の更新通知に係るメッセージであることが示されている。トピックＩＤ（３）はデバイス５０−３が記憶する電子証明書の更新通知に係るメッセージであることが示されている。

図８は、本発明の実施形態による通信システム１が行う処理の流れを示すシーケンス図である。

ステップＳ１０において、あらかじめ（例えば、装置の製造時、工場出荷時など）、認証用の共通鍵Ａをデバイス５０と更新管理サーバ３０とに記憶させておく。認証用の共通鍵Ａは、例えば、ＴＤＥＳ（Triple DES（Data Encryption Standard））や、ＡＥＳ（Advanced Encryption Standard）等の暗号方式にしたがって生成される共通鍵である。或いは、認証用の共通鍵Ａは、ＲＳＡ（Rivest-Shamir-Adleman cryptosystem）や、楕円曲線暗号の鍵ペアでもよい。

ステップＳ１１において、デバイス５０は、秘密鍵と公開鍵の鍵ペアを生成する。鍵ペアは、例えば、ＲＳＡや楕円曲線暗号の暗号方式にしたがって生成される鍵ペアである。

ステップＳ１２において、デバイス５０は、電子証明書の発行要求を更新管理サーバ３０に送信する。デバイス５０は、発行要求に、ＣＳＲに含める情報、どのようなデータの発行を要求するか、複数の認証局が存在する場合にどの認証局に証明書を発行してもらうか等の情報(例えば、データ名称、認証局名称、ＵＲＩ（Uniform Resource Identifier）等)を含めていてもよい。

ステップＳ１３において、デバイス５０と更新管理サーバ３０との相互認証が行われる。相互認証は、例えば、ステップＳ１０において双方の装置に記憶された共通鍵Ａによる暗号を用いたチャレンジ＆レスポンス方式にて行われる。チャレンジ側（例えば、デバイス５０）は、レスポンス側（例えば、更新管理サーバ３０）にチャレンジ（ホスト乱数）を送信する。レスポンス側は、ホスト乱数を暗号化する。暗号化は、チャレンジ側とレスポンス側とで予め共有している認証用の共通鍵を用いて行われる。レスポンス側は、暗号化したホスト乱数をチャレンジ側に通知する。チャレンジ側は、暗号化されたホスト乱数を復号する。復号は、チャレンジ側とレスポンス側とで予め共有している認証用の共通鍵を用いて行われる。チャレンジ側は、復号したホスト乱数と、送信したホスト乱数とが一致した場合に、レスポンス側が通信先として正当な装置であると認証する。相互に認証を行う場合、チャレンジ側とレスポンス側とを入れ替えて同様のやりとりを行うことにより認証が行われる。以下では、相互認証において互いの通信先の装置が正当な装置であると判定された場合の処理を説明する。

ステップＳ１４において、デバイス５０は、ステップＳ１１において生成した公開鍵を更新管理サーバ３０に送信する。ステップＳ１５において、更新管理サーバ３０は、ＵＵＩＤを生成し、生成したＵＵＩＤを含めたＣＳＲを生成する。例えば、更新管理サーバ３０は、ＣＳＲのコモンネームにＵＵＩＤを含める。また、更新管理サーバ３０は、ステップＳ１４においてデバイス５０から取得した公開鍵がＣＳＲに含まれるようにする。ステップＳ１６において、更新管理サーバ３０は、ＣＳＲを認証局２０に送信し、電子証明書の発行を要求する。

ステップＳ１７において、認証局２０は、通知されたＣＳＲをインプットとして電子署名をした電子証明書を発行する。ステップＳ１８において、認証局２０は、発行した電子証明書を更新管理サーバ３０に送信する。ステップＳ１９において、更新管理サーバ３０は、認証局２０から受信した電子証明書を、ＵＵＩＤとともにデバイス５０に送信する。ステップＳ２０において、デバイス５０は、電子証明書、及びＵＵＩＤを更新管理サーバ３０から受信し、受信したＵＵＩＤ、及び電子証明書を装置内に記憶させる。

ステップＳ２１において、デバイス５０は、ＵＵＩＤに対応する電子証明書の更新通知のトピックを指定して、ＭＱＴＴブローカ４０にサブスクライブする。この場合のトピックは、例えば、「/sensor/security/certificate/{UUID}/need_update」である。これにより、ＭＱＴＴブローカ４０から当該トピックを含む更新通知がデバイス５０にパブリッシュ（配信）されるようになる。

ステップＳ２２において、クラウド１０とデバイス５０とのやり取り、例えば、相互認証が行われる。例えば、クラウド１０は、デバイス５０から送信された電子証明書を検証し、デバイス５０から送信された電子証明書に改ざん等が認められない場合には、デバイス５０が正当な装置であると判定する。この場合、デバイス５０は、ステップＳ１９において受信した電子証明書をクラウド１０に送信する。デバイス５０は、クラウド１０から送信された電子証明書（サーバ証明書）を検証し、クラウド１０から送信された電子証明書に改ざん等が認められない場合には、クラウド１０が正当な装置であると判定する。さらに、ステップＳ２２において、クラウド１０とデバイス５０との間で、相互認証後に共有された共通鍵を用いた暗号化通信が行われる。

なお、上述した図８のフローチャートでは、ステップＳ１４においてデバイス５０が公開鍵を更新管理サーバ３０に送信する場合を例示して説明した。ここでデバイス５０は、ＣＳＲを生成し、生成したＣＳＲを公開鍵に代えて、更新管理サーバ３０に送信してもよい。この場合、デバイス５０は、ＵＵＩＤを生成し、生成したＵＵＩＤをＣＳＲに含めてもよい。あるいは、デバイス５０の製造時等において、ＵＵＩＤをデバイス５０の記憶部５２に記憶させておき、そのＵＵＩＤをＣＳＲに含めるようにしてもよい。

図９は、本発明の実施形態による通信システム１が行う処理を説明する図である。この例では、複数のデバイス５０（デバイス５０−１〜５０−Ｎ）のそれぞれが、トピックを指定したサブスクライブを行う流れが模式的に示されている。例えば、デバイス５０−１は、ＵＵＩＤ−ａの更新通知を指定したトピックをＭＱＴＴブローカ４０にサブスクライブする。これにより、ＭＱＴＴブローカ４０は、ＵＵＩＤ−ａの更新通知を指定したトピックにデバイス５０−１を登録する。この例では、ＵＵＩＤ−ａの更新通知を指定したトピックは、「…／｛ＵＵＩＤ−ａ｝／…／ｎｅｅｄ＿ｕｐｄａｔｅ／…」で示されている。

図１０は、本発明の実施形態による通信システム１が行う処理の流れを示すシーケンス図である。図１０には、図９で示した処理の後において更新通知がなされるまでの処理の流れが示されている。

ステップＳ３０において、更新管理サーバ３０は、任意のタイミングにて証明書管理情報３２０を参照しデバイス５０に発行された電子証明書の有効期限を確認し、更新通知をすべきデバイス５０の有無を判定する。以下では、更新通知をすべきデバイス５０があった場合の処理について説明する。

ステップＳ３１において、更新管理サーバ３０は、更新通知をＭＱＴＴブローカ４０に送信する。ここでの更新通知にはＵＵＩＤが含まれており、特定のＵＵＩＤにおける更新通知であることがトピックとして指定されている。なお、更新通知の内容は、デバイス５０が認識可能な情報であれば任意の情報（例えば、「ｔｒｕｅ」という文字列）であってよい。

ステップＳ３２において、ＭＱＴＴブローカ４０は、更新管理サーバ３０から通知された更新通知のトピックをサブスクライブしているデバイス５０に、更新通知をパブリッシュする。

ステップＳ３２において、デバイス５０は、パブリッシュされた更新通知から電子証明書に更新が必要であると判定し、更新するための処理を開始する。例えば、デバイス５０は、秘密鍵と公開鍵の鍵ペアを生成する。鍵ペアを生成する方法は、上述したステップＳ１１と同様である。ステップＳ３２では、ステップＳ１１とは異なる新たな鍵ペアを生成するようにしてもよいし、ステップＳ１１と同じ鍵ペアを再利用するようにしてもよい。

ステップＳ３３において、デバイス５０は、更新要求を更新管理サーバ３０に通知する。この場合、デバイス５０は、更新要求にデバイス５０に割り当てられたＵＵＩＤが含まれるようにする。ステップＳ３４〜Ｓ４２に示す処理は、上述したステップＳ１６〜Ｓ２１に示す処理と同等である。このため、これらの説明を省略する。

図１１は、本発明の実施形態による通信システム１が行う処理を説明する図である。図１１には、更新管理サーバ３０により通知された更新通知が、特定のデバイス５０に配信される流れが模式的に示されている。この例では、更新管理サーバ３０が、トピックが「…／｛ＵＵＩＤ−ｂ｝／…／ｎｅｅｄ＿ｕｐｄａｔｅ／…」である更新通知を、ＭＱＴＴブローカ４０にパブリッシュしたことが示されている。そして、ＭＱＴＴブローカ４０は、そのトピックを登録したデバイス５０−２に当該更新通知をパブリッシュしたことが示されている。

図１２は、本発明の実施形態による通信システム１が行う処理を説明する図である。図１２には、更新通知を受けて、デバイス５０が証明書を更新する流れが模式的に示されている。この例では、デバイス５０−２が、更新管理サーバ３０にＣＳＲ（ここでは、証明書更新リクエスト）を送信する。この場合、デバイス５０と更新管理サーバ３０とは相互認証を行い、互いに装置が正当であることを認証した後に電子証明書を更新する処理を開始する。

以上説明したように、実施形態の通信システム１は、デバイス５０と、更新管理サーバ３０と、ＭＱＴＴブローカ４０とを備える。デバイス５０は、通信システム１において複数設けられている。それぞれのデバイス５０は、それぞれの電子証明書を記憶する。更新管理サーバ３０は、複数のデバイス５０のそれぞれが記憶する電子証明書における期限管理を行う。ＭＱＴＴブローカ４０は、複数のデバイス５０のそれぞれと更新管理サーバ３０との通信を仲介する。複数のデバイス５０のそれぞれは、自身が記憶する電子証明書の更新通知の受信をＭＱＴＴブローカ４０に依頼する。更新管理サーバ３０は、電子証明書における更新通知をＭＱＴＴブローカ４０に送信する。ＭＱＴＴブローカ４０は、更新管理サーバ３０から受信した通知と、複数のデバイス５０のそれぞれから依頼された内容とに基づいて、当該通知において期限管理の対象となる電子証明書を記憶するデバイス５０に、当該通知を配信する。これにより、ＭＱＴＴブローカ４０が更新管理サーバ３０から通知された更新通知を、対象のデバイス５０に配信することができる。したがって、１つの更新管理サーバ３０が多数のデバイス５０と直接に更新通知を通信する場合と比較して、双方の処理を増大させることなく、デバイス５０のそれぞれが、自身が記憶する電子証明書の更新通知を受信することができる。すなわち、多数のデバイス５０を備える場合であっても、それぞれの電子証明書の有効期限を適切に管理することが可能である。

通信システム１は、「期限管理システム」の一例である。
デバイス５０は、「クライアント装置」の一例である。
ＭＱＴＴブローカ４０は、「通信処理サーバ」の一例である。
電子証明書は、有効期限が設定されており、「有期情報」の一例である。なお、上述した実施形態では電子証明書の有効期限を管理して更新通知を行う場合を例示して説明したが、これに限定されない。「有期情報」は、少なくとも有効期限を管理すべき情報であればよく、例えば、パスワードや暗号鍵など証明書以外の情報であってもよい。この場合、その「有期情報」の有効期限など、期限に関する情報が証明書管理情報３２０に記憶される。
更新通知は、「期限管理に関する通知」の一例である。

実施形態の通信システム１における更新通知を配信する仕組みがパブリッシュ／サブスクライブ接続プロトコルに基づいて行われていてもよい。つまり、複数のデバイス５０のそれぞれは、パブリッシュ／サブスクライブ接続プロトコルに基づいて、自身が記憶する電子証明書の更新に関するトピックをＭＱＴＴブローカ４０にサブスクライブする。更新管理サーバ３０は、パブリッシュ／サブスクライブ接続プロトコルに基づいて、電子証明書における更新通知をＭＱＴＴブローカ４０にパブリッシュする。ＭＱＴＴブローカ４０は、複数のデバイス５０のそれぞれからサブスクライブされたトピックを記憶し、更新管理サーバ３０によってパブリッシュされた通知に含まれるトピックをサブスクライブしたデバイス５０に、当該通知をパブリッシュする。これにより、パブリッシュ／サブスクライブ接続プロトコルを利用した非同期通信により、デバイス５０のそれぞれが、自身が記憶する電子証明書の更新通知を受信することができ、上述した効果と同様の効果を奏する。また、センサによる測定データを集約するシステムにおいては、パブリッシュ／サブスクライブ接続プロトコルを利用したデータ集約が行われることが多い。このため、パブリッシュ／サブスクライブ接続プロトコルを利用したデータ集約を行うシステムにおいては、パブリッシュ／サブスクライブ接続プロトコルを利用した既存の通信装置（ＭＱＴＴブローカ４０）を用いて、つまり専用の装置を追加することなく電子証明書の更新を適切に管理することが可能である。

実施形態の通信システム１では、デバイス５０は、電子証明書に対応づけられたＵＵＩＤ含むトピックを、ＭＱＴＴブローカ４０にサブスクライブする。これにより、実施形態の通信システム１では、複数のデバイス５０のうち、更新が必要な電子証明書を記憶するデバイス５０に特化して更新通知を通知することができる。

実施形態の通信システム１では、デバイス５０は、認証局２０によって発行されたクライアント証明書を期限管理対象の電子証明書として記憶する。これにより、実施形態の通信システム１では、クライアント証明書に有効期限を設定して安全性を維持させることができ、尚且つ、システムの負荷を増大させることなく有効期限を適切に管理することができる。

実施形態の通信システム１では、デバイス５０は、更新管理サーバ３０を介して、認証局２０にクライアント証明書の発行を要求する要求通知を行う。更新管理サーバ３０は、要求通知に基づいて、デバイス５０のＵＵＩＤを含むクライアント証明書の発行を認証局２０に要求する。これにより、実施形態の通信システム１では、ＵＵＩＤを含む電子証明書を発行することができ、ＵＵＩＤを用いて期限管理を行うことが可能となる。

実施形態の通信システム１では、更新管理サーバ３０は、認証局２０よって発行されたクライアント証明書を、ＵＵＩＤと共に、デバイス５０に送信する。これにより、実施形態の通信システム１では、ＵＵＩＤ（電子証明書の期限管理を行うための情報）をデバイス５０が取得することが可能となる。

実施形態の通信システム１では、デバイス５０は、更新管理サーバ３０から受信したクライアント証明書に含まれるＵＵＩＤ、又は更新管理サーバ３０から受信したクライアント証明書と共に受信したＵＵＩＤを含むトピックを、ＭＱＴＴブローカ４０にサブスクライブする。これにより、実施形態の通信システム１では、ＵＵＩＤ（電子証明書の期限管理を行うための情報）をトピックとしたサブスクライブを行うことが可能となる。

なお、上述の各実施の形態で説明した機能は、ハードウェアを用いて構成するにとどまらず、ソフトウェアを用いて各機能を記載したプログラムをコンピュータに読み込ませて実現することもできる。また、各機能は、適宜ソフトウェア、ハードウェアのいずれかを選択して構成するものであってもよい。

上述した実施形態における通信システム１、更新管理サーバ３０、ＭＱＴＴブローカ４０、デバイス５０の全部または一部をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよく、ＦＰＧＡ等のプログラマブルロジックデバイスを用いて実現されるものであってもよい。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１…通信システム（期限管理システム）
１０…クラウド（サーバ装置）
２０…認証局
３０…更新管理サーバ
３３１…証明書管理部
３３２…更新通知部
４０…ＭＱＴＴブローカ（通信処理サーバ）
４２０…トピック情報
５０…デバイス（クライアント装置）
５３２…受信登録部

Claims (8)

1. 有効期限が設定された有期情報を記憶する複数のクライアント装置と、
   前記複数のクライアント装置のそれぞれが記憶する前記有期情報における期限管理を行う更新管理サーバと、
   前記複数のクライアント装置のそれぞれと前記更新管理サーバとの通信を仲介する通信処理サーバと、
   を備え、
   前記複数のクライアント装置のそれぞれは、自身が記憶する前記有期情報の期限管理に関する通知の受信を前記通信処理サーバに依頼し、
   前記更新管理サーバは、前記有期情報における期限管理に関する通知を前記通信処理サーバに送信し、
   前記通信処理サーバは、前記更新管理サーバから受信した通知と、前記複数のクライアント装置のそれぞれから依頼された内容とに基づいて、当該通知において期限管理の対象となる前記有期情報を記憶するクライアント装置に、当該通知を配信する、
   期限管理システム。
2. 前記複数のクライアント装置のそれぞれは、パブリッシュ／サブスクライブ接続プロトコルに基づいて、自身が記憶する前記有期情報の期限管理に関するトピックを前記通信処理サーバにサブスクライブし、
   前記更新管理サーバは、パブリッシュ／サブスクライブ接続プロトコルに基づいて、前記有期情報における期限管理に関する通知を前記通信処理サーバにパブリッシュし、
   前記通信処理サーバは、前記複数のクライアント装置のそれぞれからサブスクライブされたトピックを記憶し、前記更新管理サーバによってパブリッシュされた通知に含まれるトピックをサブスクライブしたクライアント装置に、当該通知をパブリッシュする、
   請求項1に記載の期限管理システム。
3. 前記クライアント装置は、前記有期情報を一意に識別する識別情報を含むトピックを、前記通信処理サーバにサブスクライブする、
   請求項１又は請求項２に記載の期限管理システム。
4. 前記クライアント装置は、認証局によって発行されたクライアント証明書を前記有期情報として記憶する、
   請求項１から請求項３のいずれか一項に記載の期限管理システム。
5. 前記クライアント装置は、前記更新管理サーバを介して、認証局にクライアント証明書の発行を要求する要求通知を行い、
   前記更新管理サーバは、前記要求通知に基づいて、前記クライアント装置の識別情報を含むクライアント証明書の発行を認証局に要求する、
   請求項４に記載の期限管理システム。
6. 前記更新管理サーバは、認証局よって発行されたクライアント証明書を、クライアント装置を一意に識別する識別情報と共に、当該クライアント装置に送信する、
   請求項４又は請求項５に記載の期限管理システム。
7. 前記クライアント装置は、前記更新管理サーバから受信したクライアント証明書に含まれる前記クライアント装置の識別情報、又は前記更新管理サーバから受信したクライアント証明書と共に受信した前記クライアント装置の識別情報を含むトピックを、前記通信処理サーバにサブスクライブする、
   請求項４から請求項６のいずれか一項に記載の期限管理システム。
8. 有効期限が設定された有期情報を記憶する複数のクライアント装置と、
   前記複数のクライアント装置のそれぞれが記憶する前記有期情報における期限管理を行う更新管理サーバと、
   前記複数のクライアント装置のそれぞれと前記更新管理サーバとの通信を仲介する通信処理サーバと、
   を備える期限管理システムの期限管理方法であって、
   前記複数のクライアント装置のそれぞれが、自身が記憶する前記有期情報の期限管理に関する通知の受信を前記通信処理サーバに依頼し、
   前記更新管理サーバが、前記有期情報における期限管理に関する通知を前記通信処理サーバに送信し、
   前記通信処理サーバが、前記更新管理サーバから受信した通知と、前記複数のクライアント装置のそれぞれから依頼された内容とに基づいて、期限管理の対象となる前記有期情報を記憶するクライアント装置に、前記更新管理サーバから受信した通知を配信する、
   期限管理方法。

Images