JP7245032B2 - 情報処理装置、システム、時刻修正方法、および、プログラム - Google Patents

Description

本発明は、情報処理装置、システム、時刻修正方法、および、プログラムに関する。

リソースサーバーと連携するクライアント端末において、クライアントアプリケーションが、各種データ（Ａｌｅｒｔ、構成情報、Ｃｏｕｎｔｅｒ、Ｊｏｂ、Ｓｅｎｓｏｒ情報など）を記録し、リソースサーバーに送信する構成を備える。このとき、各種データは、タイムスタンプ付きでクライアント端末のローカルに保存され、クライアントアプリケーションのデータ送信タイミングでリソースサーバーに送信される。また、クライアント端末は、認可トークン取得の際に、認可シーケンスにて必要となるアサーションをクライアント端末側で生成して送信する。その際、クライアント端末内のトークンプロバイダーは、デバイス時間（すなわち、クライアント端末における時間）を元にアサーションに有効期限を付ける。この有効期限は、リプレイアタック等の対策のため一般に短い時間（例えば、５分程度）が設定される。なお、認可シーケンスとしては、ＪＷＴ（ＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ）を用いたＯＡｕｔｈ２．０の認証フレームワークなどに準拠した方法がある。

上記のように、異なる装置間で連携を行う際に、クライアント端末側で用いられる時刻と、サーバー側で用いられる時刻との差異が生じる場合がある。このような場合に、例えば、特許文献１では、サーバー側で、クライアント端末から受信したデータにて示される時刻を自身の時刻に修正する方法が記載されている。

特開２００９－６９８９２号公報

一方、クライアントアプリケーションのイベントログ記録時とトークン取得時の各々で、時刻修正方法の必要条件が異なり、同じデバイスで時刻修正方法の異なる２つの時刻修正を実施しなければならない、という課題がある。

例えば、クライアントアプリケーションのイベントログ記録に関しては、デバイスの各種イベントログの時刻を過去に戻すことなく順序通り、時刻と対応付けて記録する必要がある。具体的には、トナーロー、トナー空のイベント順が、トナー空、トナーローのイベント順になると、最悪２回のトナー配送が発生する可能性がある。そのため、イベントログ記録に用いられる時刻の修正時には、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）のｓｌｅｗモードのように修正目標時間に対し、時刻差を徐々に縮める必要がある。

一方、トークン取得に関しては、トークン取得に用いられるアサーションに設定される有効期限が短い値（例えば、５分）が設定される。そのため、トークン取得に用いられる時刻の修正については、アサーション生成時、目標時刻（例えば、サーバー側の時間）と５分以上のずれがあれば、瞬時に目標時刻に修正する必要がある。例えば、デバイスで生成したアサーションを検証するサーバーの時刻と５分以上の時刻差があれば、アサーションは有効期限切れと判断されてしまう。なお、クライアントアプリケーションのイベントログ記録の時刻修正を行う際、先にアサーションの使用を伴うトークン取得処理が必要となる。

以上の課題を鑑み、本発明では、異なる２つの時刻修正を要する場合に、安全で、かつ、確実に時刻合わせを行うことを目的とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、情報処理装置であって、認可サーバーおよびリソースサーバーと通信可能に接続された情報処理装置であって、前記リソースサーバーが提供するサービスを利用するためのトークンの要求を、前記情報処理装置の時刻に基づいて生成された有効期限を含めて前記認可サーバーに送信する要求手段と、前記要求手段による要求の応答として前記認可サーバーの時刻情報を受信した場合、前記トークンの要求を、当該認可サーバーの時刻情報に基づいて生成された有効期限を含めて再送する送信手段と、前記要求に対する応答として取得した前記トークンを用いて、前記リソースサーバーに対して前記リソースサーバーの時刻情報を要求し、当該リソースサーバーの時刻情報に基づいて前記情報処理装置の時刻を修正する修正手段とを有する。

本発明により、異なる２つの時刻修正を要する場合に、安全で、かつ、確実に時刻合わせを行うことが可能となる。

本発明に係るシステム構成の例を示す図。 本発明に係る各装置のハードウェア構成の例を示す図。 本発明に係る各装置のソフトウェアモジュールの構成例を示す図。 本発明に係る装置のソフトウェアモジュール間の通信を説明するための図。 本発明に係るＮＴＰ設定画面のユーザーインターフェースの構成例を示す図。 本発明に係るクライアント装置の時刻合わせ処理のフローチャート。 本発明に係る認可サーバーのアサーション検証処理のフローチャート。 第１の実施形態に係るクライアント端末の認可トークン取得処理のフローチャート。 本発明に係るクライアント端末のソフトウェアモジュールの構成例を示す図。 システムクロックが遅れていた場合の修正動作を説明するための図。 システムクロックが進んでいた場合の修正動作を説明するための図。 第２の実施形態に係るクライアント端末の認可トークン取得処理のフローチャート。

以下、本発明を実施するための形態について図面を用いて説明する。なお、以下に示す形態は一例であり、本発明をこれらの形態に限定することを意図するものではない。

＜第１の実施形態＞
［システム構成］
本実施形態において、インターネット上の各サーバーにアプリケーションが設置されている構成を例に挙げて説明する。アプリケーションは、クライアント端末と連携し、様々な機能を提供する。このような機能を提供する実体を「サービス」と称し、機能をクライアント端末に提供することを「サービスの提供」と称する。

図１は、本実施形態に係る情報処理システムであるデータアクセス管理システムのネットワーク構成の例を示す。なお、ここでのネットワークを構成する方式等は特に限定するものではなく、有線・無線や、複数の通信方式が組み合わされて構成されてよい。

ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１００は、１または複数のネットワークから構成され、本実施形態ではＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）システムが構築されている。ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０１、１０２は、各構成要素を接続するためのネットワークである。認可サーバー１１０は、クライアント端末１３０の認証・認可を実現するための認可サーバーである。リソースサーバー１２０は、クライアント端末１３０のデータをバックアップするサービスや、クライアント端末１３０のセンサー情報を分析するサービスなど様々なサービスを提供する。クライアント端末１３０は、サービスを利用するための機器であり、例えば、パソコン、モバイル端末、画像形成装置などが該当する。

認可サーバー１１０は、クライアント端末１３０を認証し、クライアント端末１３０からの認可トークン要求を受けて、リソースサーバー１２０を利用するのに必要な認可トークンを発行する。本実施形態において、図１では、各サーバーがそれぞれ１台ずつ設置されている例を示しているが、例えば、負荷分散のために複数台で構成されていてもよく、また、認可サーバーシステムとしてまとめて提供されてもよい。また、認可サーバー１１０とリソースサーバー１２０が異なるネットワークに接続されていてもよい。各装置は、互いに通信可能に接続されている。

［ハードウェア構成］
図２は、本実施形態に係る、認可サーバー１１０、リソースサーバー１２０、およびクライアント端末１３０に適用可能な情報処理装置の一般的なハードウェア構成である。なお、ここではいずれも同じハードウェア構成として説明するが、それぞれが異なるハードウェア構成を備えてよい。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２３１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２３３のプログラム用ＲＯＭ、或いは外部メモリ２４１に格納されたＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やアプリケーション等のプログラムを実行する。また、ＣＰＵ２３１は、システムバス２３４に接続される各ブロックを制御する。後述する各シーケンスの処理は、このＣＰＵ２３１によるプログラムの実行により実現できる。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。操作部Ｉ／Ｆ２３５は、操作部２３９からの入力を制御するインターフェース（Ｉ／Ｆ）である。ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ２４０の表示を制御する。ディスクコントローラ（ＤＫＣ）２３７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２３８は、ＷＡＮ１００もしくはＬＡＮ１０１、１０２を介して接続されたサーバーコンピューターや他の機器との通信制御処理を実行する。

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２３１であり、ソフトウェア上の主体は外部メモリ２４１にインストールされたアプリケーションプログラムである。

［ソフトウェア構成］
図３は本実施形態に係る、認可サーバー１１０、リソースサーバー１２０、クライアント端末１３０のソフトウェア構成の例を示す図である。なお、ここで示すソフトウェアは、本実施形態に関係する部分のみを示し、他のソフトウェアモジュールが更に含まれてもよい。

認可サーバー１１０は、認可サーバーモジュール１１１とＨＴＴＰサーバーモジュール１１２を含んで構成される。ＨＴＴＰサーバーモジュール１１２は、ＷＡＮ１００を介してクライアント端末１３０と通信を行い、クライアント端末１３０が備えるクライアントアプリケーション１３１、およびトークンプロバイダー１３２とＨＴＴＰ通信を行う。また、ＨＴＴＰサーバーモジュール１１２は、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）／ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）による通信が可能であり、証明書ストア（不図示）を有する。

認可サーバーモジュール１１１は、ＨＴＴＰサーバーモジュール１１２を介して、クライアント端末１３０のクライアントアプリケーション１３１、トークンプロバイダー１３２からの要求を受信し、その要求に対する結果を応答する。具体的には、認可サーバーモジュール１１１は、ユーザー認証の要求をトークンプロバイダー１３２から受信すると、認証が成功したユーザーのユーザー情報が紐づいた認可トークンを生成し、トークンプロバイダー１３２に認可トークンを通知する。認可トークンとは、ユーザーが認可サーバー１１０にログインしている事を示すためのトークン、またはユーザーが認可サーバー１１０において認証されているかを検証するためのトークンである。認可サーバー１１０は、認可トークンを用いることでユーザーを識別することが可能となる。また、認可サーバーモジュール１１１は、認可トークンに署名情報を付与するための秘密鍵を保持するように構成してもよい。その場合は、認可サーバーモジュール１１１は、この秘密鍵を用いて認可トークンに署名情報を付与し、署名情報付きの認可トークンをクライアント端末１３０に対して発行する。

リソースサーバー１２０は、リソースサーバーモジュール１２１を含んで構成される。リソースサーバーモジュール１２１は、Ｗｅｂサービスを提供するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を公開する。なお、リソースサーバー１２０は、認可サーバー１１０と同様に、ＨＴＴＰサーバーモジュールを備え、ＨＴＴＰサーバーモジュールを介して外部との受送信を実行する形態でもよい。

クライアント端末１３０は、クライアントアプリケーション１３１、トークンプロバイダー１３２、およびコントローラーファームウェア１３３を含んで構成される。クライアントアプリケーション１３１は、トークンプロバイダー１３２を介して認可サーバー１１０から認可トークンを取得する。クライアント端末１３０は、取得した認可トークンを用いてリソースサーバー１２０が公開するＡＰＩを利用する。

トークンプロバイダー１３２は、クライアントアプリケーション１３１からの認可トークン要求を受信し、認可サーバー１１０と通信を行う事で認可トークンを取得する。なお、以下の説明において、「認可トークン要求」は、クライアントアプリケーション１３１が認可トークンを取得するためにトークンプロバイダー１３２に対して送信するリクエストである。一方、「トークン要求」は、トークンプロバイダー１３２が認可トークンを取得するために認可サーバー１１０に対して送信するリクエストである。このように、同じ認可トークンを取得するリクエストであっても、リクエストの受信元と送信先とが異なることでリクエストの呼称を変えていることを留意されたい。以下では、認可トークンを、リソースサーバーにアクセスするためのアクセストークンとして用いる。

トークンプロバイダー１３２は、ベンダーデフォルトクレデンシャルとして、トークンプロバイダー１３２自身の正当性を証明するためにＸ．５０９形式で定められるクライアント証明書およびその秘密鍵を備える。そして、トークンプロバイダー１３２が、クライアント証明書およびその秘密鍵を、認可サーバー１１０との通信を確立する際に利用する事で、認可サーバー１１０はトークンプロバイダー１３２を認証することができる。

図４は、本実施形態に係る、クライアント端末１３０、認可サーバー１１０、およびリソースサーバー１２０間の通信を説明するための図である。本実施形態において、クライアント端末１３０のクライアント端末１３０は、ＮＴＰサーバー４０１、イベントセンダー４０４、およびイベントコレクター４０５を含んで構成される。また、クライアント端末１３０のコントローラーファームウェア１３３は、ＮＴＰクライアント４０２、ＮＴＰ設定４０３、およびイベントログ４０６を含んで構成される。

本実施形態に係るクライアント端末１３０のトークンプロバイダー１３２は、クライアントアプリケーション１３１からの認可トークン要求により、認可サーバー１１０に対してトークン要求を行い、認可サーバー１１０から認可トークンを取得する。

本実施形態に係るクライアントアプリケーション１３１は、クライアント端末１３０における各種イベントログを収集し、収集したイベントログをリソースサーバー１２０に送信するアプリケーションである。例えば、クライアント端末１３０が画像形成装置である場合、イベントログとしては、スキャン・プリントジョブイベント、トナー量が一定値以下となった場合のトナーローイベント、装置各部の異常検知イベント、交換部品の寿命経過イベント等がある。

クライアント端末１３０のクライアントアプリケーション１３１のイベントコレクター４０５は、コントローラーファームウェア１３３の各種イベントログを収集する。クライアントアプリケーション１３１のイベントセンダー４０４は、トークンプロバイダー１３２から取得した認可トークンを用い、イベントコレクター４０５の収集したイベントログ４０６を、定期的にリソースサーバー１２０に送信する。また、クライアントアプリケーション１３１のＮＴＰサーバー４０１は、トークンプロバイダー１３２から取得した認可トークンを用い、リソースサーバー１２０から時刻同期情報を取得する。更に、ＮＴＰサーバー４０１は、コントローラーファームウェア１３３のＮＴＰクライアント４０２に時刻同期情報を渡してクライアント端末１３０の時刻同期を行う。

ここでＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）とは、ＲＦＣ５９０５で規定されているプロトコルであり、ネットワーク接続機器において、機器の持つ時刻を上位サーバーの持つ正しい時刻に同期するためのプロトコルである。本実施形態のＮＴＰサーバー４０１は、リソースサーバー１２０内のＮＴＰサーバー（不図示）の時刻を、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いたＲＥＳＴ ＡＰＩを用いて取得する。更に、ＮＴＰサーバー４０１は、コントローラーファームウェア１３３のＮＴＰクライアント４０２にＮＴＰプロトコルを用いて通知する。

さらに本実施形態に係るクライアントアプリケーション１３１のＮＴＰサーバー４０１は、コントローラーファームウェア１３３のＮＴＰ設定４０３に対し、ＮＴＰサーバー４０１自体のＩＰアドレスを設定するＮＴＰ設定機能を有する。

コントローラーファームウェア１３３のイベントログ４０６には、スキャン・プリントジョブイベント、トナー量が一定値以下となった場合のトナーローイベント、装置各部の異常検知イベント、交換部品の寿命経過イベント等がログファイルの形式で記録される。なお、イベントを記録する形式は、メッセージキューのような形式でもよい。また、イベント通知は、イベントコレクター４０５に対する割り込みなどで通知してもよい。

コントローラーファームウェア１３３のＮＴＰクライアント４０２は、ネットワークを経由してＮＴＰサーバーの時刻情報を取得し、クライアント端末１３０のシステムクロックを修正する。これにより、クライアント端末１３０の時刻が、ＮＴＰサーバーの時刻に同期される。本実施形態のＮＴＰクライアント４０２は、クライアント端末１３０の内部ネットワークを用いてＮＴＰサーバー４０１の時刻を取得して時刻同期を行う。

図５は、本実施形態に係るコントローラーファームウェア１３３のＮＴＰ設定４０３のＮＴＰ設定画面５００を示す。ＮＴＰ設定４０３は、ＮＴＰ設定画面５００によりクライアント端末１３０のＮＴＰクライアント４０２の各種設定を行うことができる。またＮＴＰ設定画面５００の設定項目に相当する設定を、クライアントアプリケーション１３１のＮＴＰサーバー４０１からのＡＰＩコールにより行うことができる。

ＮＴＰ設定画面５００は、チェックボックス５０１、入力フィールド５０２、入力フィールド５０３、ＯＫボタン５０４、およびキャンセルボタン５０５を有する。チェックボックス５０１は、ＮＴＰを使用する・しないを設定するためのチェックボックスである。入力フィールド５０２は、ＮＴＰサーバーと時刻を同期するためのポーリング間隔を入力するフィールドである。ここでは、分単位にて指定が可能となっている。入力フィールド５０３は、同期するＮＴＰサーバーのＩＰアドレスを指定するフィールドである。ＯＫボタン５０４は、ＮＴＰ設定画面５００にて指定した値を反映するためのボタンである。キャンセルボタン５０５は、ＮＴＰ設定画面５００にて指定した値を破棄するためのボタンである。

［時刻合わせ処理］
図６は、本実施形態に係るクライアント端末１３０におけるクライアント端末時刻合わせ処理のフローチャートである。本処理フローは、クライアント端末１３０のクライアントアプリケーション１３１の起動時、および、クライアント端末１３０のコントローラーファームウェア１３３のＮＴＰクライアント４０２のＮＴＰサーバー時刻取得処理動作時に定期的に実行される。ＮＴＰクライアント４０２によるＮＴＰサーバー時刻取得処理の定期実行間隔は、図５に示した入力フィールド５０２のポーリング間隔（数値、分単位）に相当する設定に従う。本実施形態では、一つのクライアント端末１３０において、トークンプロバイダー１３２のトークン取得時と、クライアントアプリケーション１３１のイベントログ記録動作時の、２つの場合において異なる時刻合わせを行う。以下、その２つの時刻合わせについて説明する。なお、本実施形態では、認可シーケンスとして、ＪＷＴ（ＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ）を用いたＯＡｕｔｈ２．０の認証フレームワークに準拠した方法を前提として説明するが、これに限定するものではない。

（トークン取得時の時刻修正）
本実施形態において、クライアント端末１３０のトークンプロバイダー１３２がＪＷＴ形式のアサーション（以下、ＪＷＴアサーション）を用いて認可サーバー１１０に認可要求を送り、認可サーバー１１０で認可要求の検証の後、その検証結果に応じて認可トークンを取得する。その際、ＪＷＴアサーションの意図しない再利用などのいわゆるリプレイ攻撃への対策のため、ＪＷＴアサーションの有効期限は５分としている。もし、クライアント端末１３０の時刻が認可サーバー１１０の時刻と比較して５分以上遅れており、かつ、その遅れた時刻を利用してトークンプロバイダー１３２がＪＷＴアサーションを作成し、認可サーバー１１０に認可トークン取得要求を送ったとする。この場合、トークンプロバイダー１３２は、認可サーバー１１０から認可トークンが取得できなくなる。すなわち、有効期限を５分以上過ぎた認可トークン要求のＪＷＴアサーションを受信した認可サーバー１１０は、ＪＷＴアサーションの検証において有効期限外と判定し、無効なＪＷＴアサーションとしてトークン発行を拒否することになる。

また、クライアント端末１３０の時刻が認可サーバー１１０のＪＷＴアサーション検証時の現時刻より未来となる時刻で、かつ、その未来の時刻を利用してトークンプロバイダー１３２がＪＷＴアサーションを作成したとする。このＪＷＴアサーションを用いて、認可サーバー１１０に認可トークン取得要求を送った場合も、トークンプロバイダー１３２は、認可サーバー１１０から認可トークンが取得できなくなる。すなわち、現時刻より発行時刻が未来である認可トークン要求のＪＷＴアサーションを受信した認可サーバー１１０は、ＪＷＴアサーションの検証で有効期限外と判定し、無効なＪＷＴアサーションとしてトークン発行を拒否することになる。

上記のように、クライアント端末１３０の時刻がＪＷＴアサーションの有効期限外の時刻である場合、トークンプロバイダー１３２は、ＪＷＴアサーションの発行時刻、有効期限を正しく設定するために、ＪＷＴアサーション発行時、即時の時刻修正の必要がある。

（イベントログ記録時の時刻修正）
一方、本実施形態に係るクライアント端末１３０のクライアントアプリケーション１３１のイベントコレクター４０５は、コントローラーファームウェア１３３の各種イベントログを収集する。各種イベントログでは、クライアント端末１３０で発生するイベント、例えば、ジョブイベント、トナー量が一定値以下となった場合のトナーローイベント、装置各部の異常検知イベント、交換部品の寿命経過イベント等の発生時の時刻が記録されている。この時刻は、クライアント端末１３０の時刻が使用される。このイベントログの発生時刻は、イベント発生順を正しく記録する必要がある。本実施形態においては、クライアントアプリケーション１３１のイベントコレクター４０５の収集した各種イベントログを定期的にリソースサーバー１２０に送信している。クライアント端末１３０の各種イベントログを収集した本実施形態のリソースサーバー１２０は、例えば、各種イベントを解析し、消耗部品発注、故障等不具合予測を行うことができる。なお、収集したログの用途やリソースサーバー１２０が提供するサービスは上記に限定するものではなく、他のサービスで会ってよい。

例えば、クライアント端末１３０のトナーローイベントにおいてトナー量が一定値以下であることを示すイベントログ１の後、トナー量が空であることを示すイベントログ２が記録されていたとする。この場合、イベント発生時刻はイベントログ１＜イベントログ２（未来を大、過去を小とした大小比較）となる。この際、リソースサーバー１２０の消耗部品発注（不図示）は対象トナーカートリッジを一本発注すればよいことが分かる。これに関し、イベントログ１＞イベントログ２のようにイベント発生時刻が誤って逆転して記録されていた場合を考える。リソースサーバー１２０の消耗部品発注では、まず、イベントログ２を判定してトナーカートリッジ発注し、その後、イベントログ１を判定して本来不要であるはずのトナーカートリッジを再度発注してしまう可能性がある。また、リソースサーバー１２０において故障等不具合予測（不図示）を行う場合を考える。例えば、部品Ａの故障（イベントＡ）の後部品Ｂが故障（イベントＢ）した場合に故障原因はＣといったようにイベント発生順序により故障個所を特定していたとする。このときに、イベントＡとイベントＢの発生時刻が誤って逆転して記録されていた場合、故障原因Ｃの特定が不可能になってしまう。

上記のようなイベント発生順の誤った逆転を起こさないようにするためには、クライアント端末１３０における時刻修正手段は、イベント発生時刻逆転を考慮しない即時の時刻修正を行ってはならない。そのため、クライアント端末１３０は、イベント発生間隔の最小時間以下の修正を繰り返し、徐々に修正時刻に合わせるような時刻修正が必要となる。本実施形態では、リソースサーバー１２０が提供するサービスとして、時刻に関するログの順序性や時刻の経過の担保が必要となるサービスを想定して説明を行う。

上記示したように、トークン取得時の時刻修正は、トークン取得要求のＪＷＴアサーションに記録する時刻として、即時に修正するような時刻修正が必要となる。一方、イベントログ記録時の時刻修正は、イベント発生時刻の逆転を考慮してイベント発生間隔の最小時間以下の修正を繰り返して徐々に修正時刻に合わせるような時刻修正が必要となる。本実施形態では、これらの２つの時刻修正方法を考慮して処理を行う。

Ｓ６０１にて、クライアントアプリケーション１３１は、クライアント端末１３０のＮＴＰ設定を確認する。クライアント端末１３０のＮＴＰ設定は、図５のＮＴＰ設定画面５００に示された設定可能項目の値が内部的に管理されている。

Ｓ６０２にて、クライアントアプリケーション１３１は、ＮＴＰ設定のうち、ＮＴＰを使用する・しないの設定の値を取得し、ＮＴＰ設定がＯＮ（ＮＴＰ設定を使用する）になっているか否かを判定する。ＮＴＰを使用しない（ＯＦＦ）に設定されている場合（Ｓ６０２にてＮＯ）Ｓ６０３へ進み、ＮＴＰを使用する（ＯＮ）に設定されている場合（Ｓ６０２にてＹＥＳ）Ｓ６０４へ進む。

Ｓ６０３にて、クライアントアプリケーション１３１は、ＮＴＰ設定についてＮＴＰを使用する（ＯＮ）に設定する。つまり、ＮＴＰによる時刻の調整を行うように設定を変更する。そして、Ｓ６０４へ進む。

Ｓ６０４にて、クライアントアプリケーション１３１は、ＮＴＰ設定のうち、ＮＴＰサーバーアドレスの設定を確認し、ＮＴＰサーバーアドレスが設定されているか否かを判定する。ＮＴＰサーバーアドレスが設定されている場合は（Ｓ６０４にてＹＥＳ）Ｓ６０６へ進み、設定されていない場合は（Ｓ６０４にてＮＯ）Ｓ６０５へ進む。

Ｓ６０５にて、クライアントアプリケーション１３１は、クライアント端末１３０自身を示す「ｌｏｃａｌｈｏｓｔ」、すなわちＩＰｖ４であれば「１２７．０．０．１」を設定する。これは、クライアント端末１３０の使用するＮＴＰサーバーを、クライアントアプリケーション１３１のＮＴＰサーバー４０１に設定することを意味する。そして、Ｓ６０７へ進む。

Ｓ６０６にて、クライアントアプリケーション１３１は、設定されているＮＴＰサーバーアドレスを用いるものとして、Ｓ６０７へ進む。

Ｓ６０７にて、クライアントアプリケーション１３１は、ＮＴＰ設定のＮＴＰサーバーアドレス設定がクライアント端末１３０自身を示す「ｌｏｃａｌｈｏｓｔ」（すなわち、ＩＰｖ４であれば「１２７．０．０．１」）であるか否かを判定する。上記設定がクライアント端末１３０自身を示す「ｌｏｃａｌｈｏｓｔ」である場合（Ｓ６０７にてＹＥＳ）Ｓ６０８へ進み、そうでない場合は（Ｓ６０７にてＮＯ）Ｓ６１１へ進む。このとき上記設定がクライアント端末１３０自身でない場合とは、ＮＴＰサーバーとして時刻同期情報の参照先が予め指定されている場合を意味する。本実施形態では、この場合には、指定されている参照先の時刻情報を用いて時刻の修正を行う。

Ｓ６０８にて、クライアントアプリケーション１３１は、トークンプロバイダー１３２に対し、リソースサーバー１２０にアクセスするための認可トークン（アクセストークン）の取得を要求する（認可トークン要求）。

Ｓ６０９にて、トークンプロバイダー１３２は、認可トークン要求を受け付けると、認可サーバー１１０に対し、クライアントアプリケーション１３１がリソースサーバー１２０にアクセスするための認可トークンの取得処理を行う（トークン要求）。本工程の詳細は、図７、図８を用いて後述する。クライアントアプリケーション１３１の認可トークンの取得後、Ｓ６１０へ進む。

Ｓ６１０にて、クライアントアプリケーション１３１のＮＴＰサーバー４０１は、取得した認可トークンを用いて、リソースサーバー１２０のＮＴＰ要求ＡＰＩをコールする。これに応じて、リソースサーバー１２０の時刻情報が取得されることとなる。そして、Ｓ６１１へ進む。

Ｓ６１１にて、コントローラーファームウェア１３３のＮＴＰクライアント４０２は、クライアントアプリケーション１３１のＮＴＰサーバー４０１に従い、ＮＴＰによる時刻修正を行う。本工程の具体的な動作は、図９～図１１を用いて後述する。ＮＴＰ時刻修正の後、本処理フローを終了する。

［トークン取得処理］
以下、図６のＳ６０９の工程におけるトークン取得処理について、図７、図８を用いて詳述する。

（アサーション検証処理）
図７は、本実施形態に係るトークン取得時の時刻修正において認可サーバー１１０でのＪＷＴ形式のアサーションの検証およびトークンの発行処理のフローチャートである。

まず、本実施形態にて用いるアサーションに含まれる検証情報の一例を示す。
｛ “ｉｓｓ”：”ａａａ．ｉｎｃ”，
“ｓｕｂ”：”ｃｌｉｅｎｔ．ｉｄ”，
“ａｕｄ”：”ｈｔｔｐｓ：／／ｘｘｘ．ａａａ／ｓｅｒｖｉｃｅ－ｘｘｘ”，
“ｉａｔ”：１５１４７３２４００，
“ｅｘｐ”：１５１４７３２７００
｝
ここでは、「ｉｓｓ」としてクライアント端末１３０の識別子、「ｓｕｂ」としてユーザー識別子、利用を想定する主体の識別子（ａｕｄ）、発行時刻（ｉａｔ）、有効期限（ｅｘｐ）が含まれる構成とする。この検証用情報に対してクライアント端末１３０の秘密鍵で行った署名とヘッダ情報を加えてＪＷＴアサーションを構成する。

Ｓ７０１にて、認可サーバー１１０は、クライアント端末１３０から受信したトークン要求に含まれるアサーションの署名検証を行う。署名が正しい場合には（Ｓ７０１にてＹＥＳ）Ｓ７０２へ進み、不正な場合には（Ｓ７０１にてＮＯ）Ｓ７０８へ進む。

Ｓ７０２にて、認可サーバー１１０は、アサーションに含まれる検証情報の中から発行時刻（ｉａｔ）を取得し、発行時刻が認可サーバー１１０の定める正常な発行時刻範囲内に収まっているか否かを確認する。ここで定める正常な発行時刻の範囲とは、例えば、発行時刻として許容する現在時刻からのずれを５分とする場合、「認可サーバー１１０の現在時刻－５分」≦ｔ１≦「認可サーバー１１０の現在時刻＋５分」の範囲にある値ｔ１である。アサーションに含まれる検証情報の発行時刻（ｉａｔ）が正常な時間範囲に収まっている場合は（Ｓ７０２にてＹＥＳ）Ｓ７０３へ進み、範囲外の場合は（Ｓ７０２にてＮＯ）Ｓ７０７へ進む。

Ｓ７０３にて、認可サーバー１１０は、アサーションに含まれる検証情報の中から有効期限（ｅｘｐ）を取得し、有効期限が認可サーバー１１０の定める正常な有効期限範囲内に収まっているか否かを確認する。ここで定める正常な有効期限範囲は、認可サーバー１１０により決定される。例えば、アサーションの有効期限を５分とする場合、正常な有効期限範囲とは、「認可サーバー１１０の現在時刻」≦ｔ１≦「認可サーバー１１０の現在時刻＋５分」の範囲にある値ｔ１である。アサーションに含まれる有効期限が正常な時間の範囲に収まっている場合は（Ｓ７０３にてＹＥＳ）Ｓ７０４へ進み、範囲外の場合は（Ｓ７０３にてＮＯ）Ｓ７０６へ進む。

Ｓ７０４にて、認可サーバー１１０は、その他の情報についてのアサーション検証を行う。ここで行う検証の内容は特に限定するものではなく、例えば、アサーションに含まれる発行者の識別子がクライアント端末１３０であることを検証してもよいし、指定されたユーザー識別子が正規ユーザーであるかを検証してもよい。必要に応じて、本工程を省略してもよい。検証処理に合格した場合は（Ｓ７０４にてＹＥＳ）Ｓ７０５へ進み、不合格の場合は（Ｓ７０４にてＮＯ）Ｓ７０６へ進む。

Ｓ７０５にて、認可サーバー１１０は、トークン要求に対する応答として、クライアント端末１３０に対してリソースサーバー１２０にアクセスするための認可トークンを発行する。そして、本処理フローを終了する。

Ｓ７０６にて、認可サーバー１１０は、トークン要求に対する応答として、クライアント端末１３０に対してアサーションの内容が不正である旨のエラーを返す。そして、本処理フローを終了する。

Ｓ７０７にて、認可サーバー１１０は、発行時刻が正常な時間範囲に収まっていないことから、クライアント端末１３０の時計が正常に動作していないと判定する。そして、認可サーバー１１０は、トークン要求に対する応答として、クライアント端末１３０に対して認可サーバー１１０の現在時刻を含めたエラーを返す。そして、本処理フローを終了する。

Ｓ７０８にて、認可サーバー１１０は、トークン要求に対する応答として、クライアント端末１３０に対してアサーションの署名が不正である旨のエラーを返す。そして、本処理フローを終了する。

なお、上記のＳ７０２およびＳ７０３の処理にて用いる有効期限および発行時刻の正常範囲の定義は、上記で述べたものに準ずる必要はなく、認可サーバー１１０側にて他の基準に基づいて設定してよい。

（認可トークン取得処理）
図８は、本実施形態に係るトークン取得時の時刻修正においてクライアント端末１３０（トークンプロバイダー１３２）がＪＷＴアサーションを用いて認可トークンを取得処理のフローチャートである。

Ｓ８０１にて、クライアント端末１３０は、自身の現在時刻を元に、発行時刻（ｉａｔ）、有効期限（ｅｘｐ）を決定し、これらと、自身の識別子（ｉｓｓ）、ユーザー識別子（ｓｕｂ）、利用を想定する主体の識別子（ａｕｄ）の情報を含む検証情報を生成する。そして、クライアント端末１３０は、生成した検証情報に対して、予め保持している秘密鍵で署名し、アサーションとして発行する。例えば、発行時刻が「２０１８．０１．０１ １２：００：００」で有効時間を５分とする場合、有効期限は「２０１８．０１．０１ １２：０５：００」と決定される。

Ｓ８０２にて、クライアント端末１３０は、Ｓ８０１で発行したアサーションを認可サーバー１１０に送信し、トークン要求を行う。

Ｓ８０３にて、クライアント端末１３０は、トークン要求に対するレスポンスを受信する。

Ｓ８０４にて、クライアント端末１３０は、トークン取得に成功したか否かを判定する。認可トークンを取得できたと判定された場合には（Ｓ８０４にてＹＥＳ）本処理フローを終了する。認可トークンを取得できなかったと判定された場合には（Ｓ８０４にてＮＯ）Ｓ８０５へ進む。

Ｓ８０５にて、クライアント端末１３０は、レスポンスに認可サーバー１１０の現在時刻が含まれているか否かを判定する。現在時刻が含まれている場合には（Ｓ８０５にてＹＥＳ）Ｓ８０６へ進み、現在時刻が含まれていない場合には（Ｓ８０５にてＮＯ）本処理フローを終了する。ここで現在時刻が含まれている場合とは、図７のＳ７０７に示したように、クライアント端末１３０の時計が正常に動作していないものと認可サーバー１１０側で判定された場合に相当する。

Ｓ８０６にて、クライアント端末１３０は、認可サーバー１１０の現在時刻を設定した発行時刻および有効期限を予め保持している秘密鍵で署名し、アサーションを再度発行する。つまり、クライアント端末１３０は、認可サーバー１１０側の現在時刻を用いてアサーションを再発行することで、認可サーバー１１０とクライアント端末１３０との時刻の誤差を一時的に修正する。その後、Ｓ８０２に戻り、クライアント端末１３０は、再度発行したアサーションを認可サーバー１１０に再送する。

本処理フローにおいて、署名に使用する秘密鍵は、クライアント端末１３０が予め保持しているが、これに限るものではない。例えば、不図示の方法でクライアント端末１３０が認可サーバー１１０にアクセスして認証を行い、認可サーバー１１０から発行された秘密鍵を保持して利用してもよい。また、Ｓ８０５において、レスポンスに現在時刻が含まれていない場合、処理を終了しているが、認可トークン取得失敗時の対応はこれに限るものではない。例えば、別の失敗要因に起因するエラーにおいても、アサーションを修正し、再度認可トークン要求を行ってよい。

以上、図７および図８のフローにより、クライアント端末１３０側の現在時刻と、認可サーバー１１０の現在時刻との間で所定の範囲以上の誤差がある場合であっても、認可トークンを発行可能となる。

［ＮＴＰ時刻修正の動作］
続いて、本実施形態に係るＮＴＰ時刻修正処理について、図９～図１１を用いて詳述する。なお、本動作は、図６のＳ６１１の工程にて行われる動作に相当する。

図９は、図４で示したクライアント端末１３０の各モジュールに関し、ＮＴＰ時刻修正処理に係るモジュールについてさらに詳細に記載した図である。図９において、クライアント端末１３０、クライアントアプリケーション１３１、コントローラーファームウェア１３３、ＮＴＰサーバー４０１、ＮＴＰクライアント４０２については、図４に示したモジュールと同様である。

本実施形態に係るクライアント端末１３０のコントローラーファームウェア１３３は、Ｌｉｎｕｘ（登録商標）のようなＯＳのカーネル９０１上で動作する。カーネル９０１は、システムクロック９０２を有する。システムクロック９０２は、カーネル９０１内部の時計で、インターバルタイマーの割り込みにより時刻をカウントアップしている。システムクロック９０２は、クライアント端末１３０の起動時にマザーボード基盤を示すハードウェア９０３上に実装されたハードウェアクロック（例えば、ＣＭＯＳクロック）を参照し、システムクロック９０２を設定する。クライアント端末１３０の動作中は、ハードウェア９０３上に実装されたインターバルタイマー９０５の定期的な割り込みにより、システムクロック９０２を更新することにより、クライアント端末１３０の時刻がカウントアップされる。基本的に、コントローラーファームウェア１３３やクライアントアプリケーション１３１がクライアント端末１３０の時刻として取得、利用するのは、カーネル９０１のシステムクロック９０２の値である。

本実施形態に係るＮＴＰ時刻修正処理は、ＮＴＰクライアント４０２により定期的に実行される。ＮＴＰクライアント４０２は、ＮＴＰサーバー４０１から、ポーリング間隔（図５に示した入力フィールド５０２の設定に相当）に従い、定期的に設定済みのＮＴＰサーバー時刻を取得する。ＮＴＰクライアント４０２は、受信したＮＴＰサーバー４０１の時刻に従い、ａｄｊｔｉｍｅｘ（）を用いたシステムコールにより定期的にカーネル９０１内部のメモリに保持するシステムクロック９０２の値を修正する。

（システムクロックの遅れを修正する場合）
図１０は、ＮＴＰサーバー４０１の時刻よりシステムクロック９０２が示す時刻が遅れていた場合の、ＮＴＰクライアント４０２がシステムクロック９０２を修正する修正動作を説明するための図である。

ＮＴＰクライアント４０２は、ＮＴＰサーバー４０１より時刻「２０１８－０８－２９ ０８：５６：２５」に相当するパラメーターを取得する。その際、システムクロック９０２の時刻が「２０１８－０８－２９ ０８：５０：２５」であったとすると、ＮＴＰサーバー４０１の時刻に比べてシステムクロック９０２は６分の遅れがあることになる。これを修正する場合、ＮＴＰクライアント４０２が１秒毎にａｄｊｔｉｍｅｘ（）システムコールにより、システムクロック９０２に対し、１秒当たり＋０．０５秒の修正を行う。これを７２００回繰り返すことにより、７２００秒後に当初６分の遅れ段階的に解消させ、時刻を調整することができる。

（システムクロックの進みを修正する場合）
図１１は、ＮＴＰサーバー４０１の時刻よりシステムクロック９０２が進んでいた場合の、ＮＴＰクライアント４０２がシステムクロック９０２を修正する修正動作を説明するための図である。

ＮＴＰクライアント４０２は、ＮＴＰサーバー４０１より時刻「２０１８－０８－２９ ０８：５６：２５」に相当するパラメーターを取得する。その際、システムクロック９０２の時刻が「２０１８－０８－２９ ０９：０２：２５」であったとすると、ＮＴＰサーバー４０１の時刻に比べてシステムクロック９０２は６分の進みがあることになる。これを修正する場合、ＮＴＰクライアント４０２が１秒毎にａｄｊｔｉｍｅｘ（）システムコールにより、システムクロック９０２に対し、１秒当たり－０．０５秒の修正を行う。これを７２００回繰り返すことにより、７２００秒後に当初６分の進みを段階的に解消させ、時刻を調整することができる。

図１０、図１１にて説明したように、徐々に時刻修正を行う。その結果、コントローラーファームウェア１３３のイベントログ４０６に記録される各種イベントの間隔が０．０５秒以下の場合、イベント発生時刻順を逆転させることなく、各種イベントを記録することができる。

以上、本実施形態により、異なる２つの時刻修正を要する場合にも、安全で、かつ、確実に時刻合わせを行うことが可能となる。

＜第２の実施形態＞
本発明の第２の実施形態について説明する。本実施形態では、トークン取得時の時刻修正の方法が第１の実施形態とは異なる形態について説明する。なお、第１の実施形態と重複する構成については、説明を省略する。本実施形態では、クライアント端末１３０は、時計もしくはクライアント起動時からのカウントを取得するカウンターを保持しているものとする。

［処理フロー］
（認可トークン取得処理）
図１２は、本実施形態に係るトークン取得時の時刻修正の実施形態においてクライアント端末１３０がＪＷＴアサーションを用いて認可トークンを取得処理のフローチャートである。第１の実施形態の図８の代わりに実行され、図８と同じ処理については、同じ参照番号を付している。

Ｓ１２０１にて、クライアント端末１３０は、時刻補正情報が記憶されているかを確認する。時刻補正情報は、認可サーバー１１０とクライアント端末１３０の時刻の差異を記録した値である。この値は、初回時には保持されておらず、処理が繰り返されることで記憶される。時刻補正情報が記憶されていると判定された場合には（Ｓ１２０１にてＹＥＳ）Ｓ１２０２へ進み、記憶しないと判定された場合には（Ｓ１２０１にてＮＯ）Ｓ８０１へ進む。

Ｓ１２０２にて、クライアント端末１３０は、自身の現在時刻を時刻補正情報で補正した現在時刻を元に、発行時刻（ｉａｔ）、有効期限（ｅｘｐ）を決定する。そして、クライアント端末１３０は、これらと、自身の識別子（ｉｓｓ）、ユーザー識別子（ｓｕｂ）、利用を想定する主体の識別子（ａｕｄ）の情報を含む検証情報を生成する。そして、クライアント端末１３０は、生成した検証情報に対して、予め保持している秘密鍵で署名し、アサーションとして発行する。

以下の表１は、本実施形態に係る補正時刻情報を管理する時刻補正テーブルの一例である。

例えば、クライアント端末１３０の現在時刻が「２０１８．０１．０１ １２：００：００」であり、時刻補正テーブルにて保持されている補正時刻情報が「＋３２４００秒」（９時間に相当）であるとする。この場合、補正後の時刻は９時間後の「２０１８．０１．０１ ２１：００：００」となる。これにより、認可サーバー１１０との時刻ずれを補正することができる。その後、Ｓ８０２へ進む。

Ｓ８０５にて、レスポンスに認可サーバー１１０の現在時刻が含まれていると判定された場合（Ｓ８０５にてＹＥＳ）Ｓ１２０３へ進む。Ｓ１２０３にて、クライアント端末１３０は、Ｓ８０３にて取得したレスポンスにて示される認可サーバー１１０の現在時刻と、クライアント端末１３０の現在時刻の差を時刻補正情報として時刻補正テーブルに保持する。例えば、クライアント端末１３０の現在時刻が「２０１８．０１．０１ １：００：００」であり、認可サーバー１１０の現在時刻が「２０１８．０１．０１ １０：００：００」であるとする。この場合、その差が算出され、「＋３２４００秒」という時刻補正情報が時刻補正テーブルに保持される。その後、Ｓ１２０１へ戻る。

［本実施形態に係る別の構成例］
本実施形態の上記の例では、クライアント端末１３０が時計を保有していることを想定しているが、時計を持たない端末においてもクライアント端末のカウンター値をＵＮＩＸ時刻として処理を行うことで同様に補正することができる。以下の表２は、カウンター値での時刻補正を行う場合の時刻補正テーブルの構成例を示す。

例えば、クライアント端末１３０のカウンター値が“３０”のとき、カウント開始時刻「１９７０．０１．０１ ００：００：００」から算出して現在時刻を「１９７０．０１．０１ ０：００：３０」として扱い処理を行う。そして、認可サーバー１１０の現在時刻「２０１８．０１．０１ １０：００：００」との差分から「＋１５１４７６８３７０秒」という時刻補正情報を得ることができる。

以上、本実施形態により、異なる２つの時刻修正を要する場合にも、安全で、かつ、確実に時刻合わせを行うことが可能となる。

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

１１０…認可サーバー、１２０…リソースサーバー、１３０…クライアント端末、１３１ クライアントアプリケーション、１３２…トークンプロバイダー、１３３…コントローラーファームウェア、４０１…ＮＴＰサーバー、４０２…ＮＴＰクライアント

Claims (11)

1. 認可サーバーおよびリソースサーバーと通信可能に接続された情報処理装置であって、
   前記リソースサーバーが提供するサービスを利用するためのトークンの要求を、前記情報処理装置の時刻に基づいて生成された有効期限を含めて前記認可サーバーに送信する要求手段と、
   前記要求手段による要求の応答として前記認可サーバーの時刻情報を受信した場合、前記トークンの要求を、当該認可サーバーの時刻情報に基づいて生成された有効期限を含めて再送する送信手段と、
   前記要求に対する応答として取得した前記トークンを用いて、前記リソースサーバーに対して前記リソースサーバーの時刻情報を要求し、当該リソースサーバーの時刻情報に基づいて前記情報処理装置の時刻を修正する修正手段と
   を有することを特徴とする情報処理装置。
2. 前記修正手段は、前記情報処理装置の時刻を前記リソースサーバーの時刻に段階的に近づけて時刻を合わせるように修正することを特徴とする請求項１に記載の情報処理装置。
3. 前記要求手段による要求の応答として受信された前記認可サーバーの時刻情報は、前記情報処理装置の時刻を修正するための情報としては用いられないことを特徴とする請求項１または２に記載の情報処理装置。
4. 時刻の修正に関する設定を受け付ける設定手段を更に有し、
   時刻の修正を行わない設定が指定されている際に、前記リソースサーバーが提供するサービスを利用する場合、前記設定手段は、前記時刻の修正を行う設定に変更することを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
5. 前記修正手段は、前記設定手段にて時刻の修正を行う設定が指定され、かつ、時刻情報の参照先が指定されている場合、当該参照先にて提供される時刻情報に基づいて前記情報処理装置の時刻を修正することを特徴とする請求項４に記載の情報処理装置。
6. 前記リソースサーバーが提供するサービスは、前記情報処理装置にて時刻と対応づけて記録されたログの収集を含むことを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 前記要求手段による要求の応答として前記認可サーバーの時刻情報を受信した場合、当該認可サーバーの時刻情報と前記情報処理装置の時刻との差を補正情報として保持する保持手段を更に有し、
   前記送信手段は、前記情報処理装置の時刻を前記補正情報を用いて補正した時刻を用いて生成された有効期限を含めて、前記トークンの要求を再送することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
8. 情報処理装置、認可サーバー、およびリソースサーバーが通信可能に接続されたシステムであって、
   前記情報処理装置は、
   前記リソースサーバーが提供するサービスを利用するためのトークンの要求を、前記情報処理装置の時刻に基づいて生成された有効期限を含めて前記認可サーバーに送信する要求手段と、
   前記要求手段による要求の応答として前記認可サーバーの時刻情報を受信した場合、前記トークンの要求を、当該認可サーバーの時刻情報に基づいて生成された有効期限を含めて再送する送信手段と、
   前記要求に対する応答として取得した前記トークンを用いて、前記リソースサーバーに対して前記リソースサーバーの時刻情報を要求し、当該リソースサーバーの時刻情報に基づいて前記情報処理装置の時刻を修正する修正手段と
   を有し、
   前記認可サーバーは、
   リソースサーバーが提供するサービスを利用するためのトークンの要求を前記情報処理装置から受け付けた場合、当該要求の検証を行う検証手段と、
   前記検証手段による検証結果に応じて前記トークンを発行する発行手段と
   を有し、
   前記発行手段は、前記検証手段により前記要求に含まれる当該要求の有効期限の設定が前記認可サーバーの時刻に基づいて定義される範囲に含まれないと判定された場合、前記認可サーバーの時刻情報を前記情報処理装置に送信することを特徴とするシステム。
9. 認可サーバーおよびリソースサーバーと通信可能に接続された情報処理装置における時刻修正方法であって、
   前記リソースサーバーが提供するサービスを利用するためのトークンの要求を、前記情報処理装置の時刻に基づいて生成された有効期限を含めて前記認可サーバーに送信する要求工程と、
   前記要求工程による要求の応答として前記認可サーバーの時刻情報を受信した場合、前記トークンの要求を、当該認可サーバーの時刻情報に基づいて生成された有効期限を含めて再送する送信工程と、
   前記要求に対する応答として取得した前記トークンを用いて、前記リソースサーバーに対して前記リソースサーバーの時刻情報を要求し、当該リソースサーバーの時刻情報に基づいて前記情報処理装置の時刻を修正する修正工程と
   を有することを特徴とする時刻修正方法。
10. 情報処理装置、認可サーバー、およびリソースサーバーが通信可能に接続されたシステムにおける前記情報処理装置の時刻修正方法であって、
    前記情報処理装置において、
    前記リソースサーバーが提供するサービスを利用するためのトークンの要求を、前記情報処理装置の時刻に基づいて生成された有効期限を含めて前記認可サーバーに送信する要求工程と、
    前記要求工程による要求の応答として前記認可サーバーの時刻情報を受信した場合、前記トークンの要求を、当該認可サーバーの時刻情報に基づいて生成された有効期限を含めて再送する送信工程と、
    前記要求に対する応答として取得した前記トークンを用いて、前記リソースサーバーに対して前記リソースサーバーの時刻情報を要求し、当該リソースサーバーの時刻情報に基づいて前記情報処理装置の時刻を修正する修正工程と
    を有し、
    前記認可サーバーにおいて、
    リソースサーバーが提供するサービスを利用するためのトークンの要求を前記情報処理装置から受け付けた場合、当該要求の検証を行う検証工程と、
    前記検証工程による検証結果に応じて前記トークンを発行する発行工程と
    を有し、
    前記発行工程において、前記検証工程により前記要求に含まれる当該要求の有効期限の設定が前記認可サーバーの時刻に基づいて定義される範囲に含まれないと判定された場合、前記認可サーバーの時刻情報を前記情報処理装置に送信することを特徴とする時刻修正方法。
11. コンピューターを、
    リソースサーバーが提供するサービスを利用するためのトークンの要求を、前記コンピューターの時刻に基づいて生成された有効期限を含めて認可サーバーに送信する要求手段、
    前記要求手段による要求の応答として前記認可サーバーの時刻情報を受信した場合、前記トークンの要求を、当該認可サーバーの時刻情報に基づいて生成された有効期限を含めて再送する送信手段、
    前記要求に対する応答として取得した前記トークンを用いて、前記リソースサーバーに対して前記リソースサーバーの時刻情報を要求し、当該リソースサーバーの時刻情報に基づいて前記コンピューターの時刻を修正する修正手段
    として機能させるためのプログラム。

Images