(57)【要約】      （修正有）【課題】複数のアプリケーションのそれぞれを区別しつつ、複数のアプリケーションでＷｅｂサービス提供サーバが管理するデータを共有できるようにする仕組みを提供する。【解決手段】新クライアント端末内の端末内アプリケーションが、リソースサーバ１２０に対する認証情報の更新を認証認可サーバ１１０に要求する。端末内アプリケーションは、認証認可サーバ１１０から新認証情報を取得する。そして、認証認可サーバ１１０が、旧認証情報に対応するアプリケーションを識別するための第１の識別情報と、新認証情報に対応するアプリケーションを識別するための第２の識別情報とを関連付けて管理する。【選択図】図１
2016081351.tif 000002
【特許請求の範囲】
【請求項１】
データ同期対象のアプリケーションへＷｅｂサービス提供サーバと連携する際に必要な情報を同期するシステムであって、
前記情報のうち、前記Ｗｅｂサービス提供サーバに対する認証情報の更新を前記Ｗｅｂサービス提供サーバに対応する認証サービス提供サーバへ要求する認証情報要求手段と、
前記要求に応じた認証サービス提供サーバから新認証情報を取得する取得手段とを備え、
前記認証サービス提供サーバは、旧認証情報に対応するアプリケーションを識別するための第１の識別情報と、前記新認証情報に対応するアプリケーションを識別するための第２の識別情報とを関連付けて管理する
ことを特徴とする情報処理システム。
【請求項２】
前記認証情報要求手段は、前記認証情報の更新の要求の際に、旧認証情報を無効にするか否かを示す設定情報を前記認証サービス提供サーバに対して送信し、
前記認証サービス提供サーバは、前記認証情報要求手段から受信した前記設定情報に基づいて、前記旧認証情報を無効にするか否かを決定する
ことを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記設定情報は、前記Ｗｅｂサービスが提供するサービスに応じて予め決められる
ことを特徴とする請求項２に記載の情報処理システム。
【請求項４】
前記認証情報要求手段は、
前記旧認証情報を無効にするか否かを選択するための選択画面を表示し、
前記選択画面を用いた選択に応じて、前記旧認証情報を無効にすることを示す設定情報を送信するか、前記旧認証情報を無効にしないことを示す設定情報を送信するかを決定する
ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
【請求項５】
前記認証情報要求手段は、前記認証情報の更新の要求の際に、アプリケーションによるＷｅｂサービス提供サーバの利用時に更新されるトークンを前記認証サービス提供サーバに対して送信し、
前記認証サービス提供サーバは、前記認証情報要求手段から受信した前記トークンが更新されている場合に、エラーを通知する
ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム。
【請求項６】
前記アプリケーションによるＷｅｂサービス提供サーバの利用時に更新されるトークンは、リフレッシュトークンである
ことを特徴とする請求項５に記載の情報処理システム。
【請求項７】
前記取得手段は、前記取得された新認証情報を用いて前記Ｗｅｂサービス提供サーバに対してアクセスし、
前記Ｗｅｂサービス提供サーバは、
アプリケーションに紐付けてデータを管理しており、
前記取得手段からのアクセスに応じて、前記新認証情報の検証を前記認証サービス提供サーバに対して要求し、
前記認証サービス提供サーバによる前記新認証情報の検証に成功した場合に、旧認証情報に対応するアプリケーションに紐付いているデータを、前記新認証情報に対応するアプリケーションに引き継ぐ
ことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理システム。
【請求項８】
前記認証サービス提供サーバは、前記新認証情報の検証に成功した場合に、前記新認証情報に関連する旧認証情報に対応する前記第１の識別情報を前記Ｗｅｂサービス提供サーバに対して送信し、
前記Ｗｅｂサービス提供サーバは、前記認証サービス提供サーバから受信した前記第１の識別情報に基づいて、旧認証情報に対応するアプリケーションに紐付いているデータを、前記新認証情報に対応するアプリケーションに引き継ぐ
ことを特徴とする請求項７に記載の情報処理システム。
【請求項９】
請求項１乃至８のいずれか１項に記載の前記認証情報要求手段と前記取得手段とをアプリケーションとして備える情報処理装置。
【請求項１０】
データ同期対象のアプリケーションへＷｅｂサービス提供サーバと連携する際に必要な情報を同期する情報処理システムが有する認証サービス提供サーバであって、
情報処理装置から、前記情報のうち、前記Ｗｅｂサービス提供サーバに対する認証情報の更新の要求を受け付ける受け付け手段と、
前記情報処理装置に対して、新認証情報を送信する送信手段と、
旧認証情報に対応するアプリケーションを識別するための第１の識別情報と、前記新認証情報に対応するアプリケーションを識別するための第２の識別情報とを関連付けて管理する管理手段とを備える
ことを特徴とする認証サービス提供サーバ。
【請求項１１】
データ同期対象のアプリケーションへＷｅｂサービス提供サーバと連携する際に必要な情報を同期するシステムの制御方法であって、
前記情報のうち、前記Ｗｅｂサービス提供サーバに対する認証情報の更新を前記Ｗｅｂサービス提供サーバに対応する認証サービス提供サーバへ要求する工程と、
前記要求に応じた認証サービス提供サーバから新認証情報を取得する工程と、
旧認証情報に対応するアプリケーションを識別するための第１の識別情報と、前記新認証情報に対応するアプリケーションを識別するための第２の識別情報とを関連付けて管理する工程とを有する
ことを特徴とする制御方法。
【請求項１２】
請求項１１に記載の制御方法をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、情報処理装置、認証サービス提供サーバ、制御方法およびコンピュータプログラムに関する。
【背景技術】
【０００２】
インターネット上で提供されるクラウドサービスを、携帯端末、デジタル家電、オフィス機器といった各種デバイスから利用するサービスが提案されている。また、一人のユーザが複数のデバイスを保持し、様々なクラウドサービスを利用するユースケースも増えている。多くの端末メーカーは、端末のデータをクラウドサービス等でバックアップし、同じ端末へのリストアや、別の端末へのデータコピー、データ移行といったサービスを提供している。
【０００３】
特許文献１は、バックアップサーバに端末利用者ごとのユーザＩＤを作成し、ユーザＩＤに紐付けた端末間で端末のデータをバックアップ・リストアするシステムを開示している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−２８８２７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
端末にインストールされたアプリケーションに対応するアプリケーションデータは、端末内だけでなく、連携するクラウドサービス側に保持されることが多くなってきている。また、多くのアプリケーションは、アプリケーション利用者にユーザ登録をさせることなく、インストールするだけで利用できる。したがって、端末単位でアプリケーションを識別してデータを管理するシステムが一般的である。
【０００６】
多くの端末利用者にとって、端末データのバックアップ・リストアをし、複数デバイスで同じデータを利用（共有）したり、新しいデバイスにデータを移行したりといったことを簡単に実現したいという要求がある。
【０００７】
一方、アプリケーションの販売者は、アプリケーション内で利用するコンテンツ等を個別に購入させ課金するビジネスを行っている。したがって、複数の端末で購入コンテンツが同時利用されたり、１回購入したコンテンツを複数回利用されたりすることを防止したいので、多くの課金系のアプリケーションでは、端末のバックアップされない領域に、複製されたくないデータが保持されている。したがって、端末移行時には、アプリケーション毎に、アプリケーションサービスを提供するＷｅｂサービス提供サーバにて、機種変手続きの実行後にデータ移行したり、Ｗｅｂサービス提供サーバにユーザ登録してから移行作業をしたりする必要があった。
【０００８】
本発明は、複数のアプリケーションのそれぞれを区別しつつ、複数のアプリケーションでＷｅｂサービス提供サーバが管理するデータを共有できるようにする仕組みの提供を目的とする。
【課題を解決するための手段】
【０００９】
本発明の一実施形態の情報処理システムは、データ同期対象のアプリケーションへＷｅｂサービス提供サーバと連携する際に必要な情報を同期するシステムである。前記情報処理システムは、前記情報のうち、前記Ｗｅｂサービス提供サーバに対する認証情報の更新を前記Ｗｅｂサービス提供サーバに対応する認証サービス提供サーバへ要求する認証情報要求手段と、前記要求に応じた認証サービス提供サーバから新認証情報を取得する取得手段とを備える。前記認証サービス提供サーバは、旧認証情報に対応するアプリケーションを識別するための第１の識別情報と、前記新認証情報に対応するアプリケーションを識別するための第２の識別情報とを関連付けて管理する。
【発明の効果】
【００１０】
本発明の情報処理システムによれば、複数のアプリケーションのそれぞれを区別しつつ、複数のアプリケーションでＷｅｂサービス提供サーバが管理するデータを共有できるようになる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態の情報処理システムの構成を示す図である。
【図２】認証認可サーバ、リソースサーバ、クライアント端末、バックアップ装置のハードウェア構成の一例である。
【図３】認証認可サーバ、リソースサーバ、クライアント端末、バックアップ装置のモジュール構成を示す図である。
【図４】バックアップ処理とリストア処理を説明する図である。
【図５】データの引継ぎ処理を説明する図である。
【図６】図５のステップＳ５０３、Ｓ５０４の処理の詳細を説明する図である。
【図７】他の実施形態における認証認可サーバの処理を説明する図である。
【図８】選択画面の一例である。
【発明を実施するための形態】
【００１２】
図１は、本実施形態の情報処理システムの構成を示す図である。
本実施形態においては、インターネット上のサーバにアプリケーションサービスが設置されていることを想定している。アプリケーションサービスは、クライアント端末と連携し、様々な機能を提供する。以降、アプリケーションサービスのように、インターネット上で機能を提供しているサービスを、リソースサービスと呼ぶ。本実施形態においては、クライアント端末上にインストールされたアプリケーションと、リソースサービスを提供するＷｅｂサービス提供サーバとが連携することを想定している。以降、上記アプリケーションを端末内アプリケーションと呼ぶ。
【００１３】
また、本実施の形態における権限の移譲では、ＯＡｕｔｈの仕組みを利用する。ＯＡｕｔｈでは、ユーザから移譲された権限の証明するための情報として、トークンと呼ばれる情報を利用する。さらに、本実施形態において、クライアント端末に対応する仮想的なサーバ上のユーザをデバイスクライアントと呼ぶ。
【００１４】
図１に示す情報処理システムは、認証認可サーバ１１０乃至バックアップ装置１８０を備える。認証認可サーバ１１０乃至バックアップ装置１８０は、ＬＡＮ１０１およびＷＡＮ１００を介して通信する。ＬＡＮは、Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋの略称である。また、ＷＡＮは、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋの略称である。ＷＡＮ１００によって、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。
【００１５】
認証認可サーバ１１０は、ＯＡｕｔｈ認証方式によるユーザの認証処理を実行する認証サービス提供サーバである。リソースサーバ１２０は、リソースサービスを提供するＷｅｂサービス提供サーバである。この例では、リソースサーバ１２０は、印刷サービスを提供する。図１に示す例では、各サーバは１台ずつ設置されているが、複数台で認証認可サーバシステムを構成していてもよい。
【００１６】
クライアント端末１５０は、本実施形態の情報処理装置である。この例では、クライアント端末１５０は、スマートフォンといったモバイル端末である。クライアント端末１５０には、Ｗｅｂブラウザや端末内アプリケーションがインストールされている。バックアップ装置１８０は、クライアント端末１５０のデータをバックアップ・リストアする機能を提供する。
【００１７】
認証認可サーバ１１０、リソースサーバ１２０、クライアント端末１５０、バックアップ装置１８０は、それぞれ個別のＬＡＮ上に設けられていてもよいし、同一のＬＡＮ上に設けられていてもよい。また、認証認可サーバ１１０とリソースサーバ１２０とは、同一のサーバ上に設けられていてもよい。
【００１８】
図２は、本実施形態の認証認可サーバ、リソースサーバ、クライアント端末、バックアップ装置のハードウェア構成の一例である。
ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２４１からＲＡＭ２３２にロードされたＯＳやアプリケーション等のプログラムを実行する。また、ＣＰＵ２３１は、システムバス２３４に接続される各ブロックを制御する。ＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。ＲＡＭ２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。操作部Ｉ／Ｆ２３５は、操作部２３９からの入力を制御する。
【００１９】
ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ２４０の表示を制御する。ディスクコントローラ（ＤＫＣ）２３７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２３８は、ＷＡＮ１００もしくはＬＡＮ１０１を介して接続されたサーバコンピューターや他の機器との通信制御処理を実行する。なお、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２３１であり、ソフトウェア上の主体は外部メモリ２４１にインストールされたアプリケーションプログラムである。
【００２０】
図３は、認証認可サーバ、リソースサーバ、クライアント端末、バックアップ装置のモジュール構成を示す図である。
図３（Ａ）に示すように、認証認可サーバ１１０は、認証認可モジュール３１０を備える。リソースサーバ１２０は、リソースサーバモジュール３２０を備える。クライアント端末１５０は、リソースサーバ１２０と連携するための端末内アプリケーションを備える。バックアップ装置１８０は、バックアップデータ管理モジュール３８０を備える。バックアップデータ管理モジュール３８０は、端末データのバックアップ処理・リストア処理・データ管理等を行う。
【００２１】
認証認可サーバ１１０が外部メモリ２４１にて記憶するデータテーブルに関して以下に説明する。以下に説明するデータテーブルは、認証認可サーバ１１０の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバに記憶するよう構成することもできる。
【００２２】
認証認可サーバ１１０は、表１に示すデバイスクライアント管理テーブルにおいて、デバイスクライアントの情報を管理する。
【表１】
2016081351.tif 000003
【００２３】
デバイスクライアント管理テーブルは、デバイスクライアントを一意に識別する「クライアントＩＤ」、クライアントＩＤで認証するための「シークレット」、クライアントがどんな権限を持つかを示す「ロール」をデータ項目として持つ。「ロール」は、どのアプリケーションサービスを利用することが可能かを示す。「ロール」には、例えば、「Ａｐｐ１Ｒｏｌｅ」や「Ａｐｐ２Ｒｏｌｅ」といったサービスごとに定義されたロールが設定される。また、デバイスクライアント管理テーブルには、クライアントＩＤが過去どのクライアントＩＤと紐づいていたかを示す「関連クライアントＩＤ」が設定される。
【００２４】
また、認証認可サーバ１１０は、表２に示す認可トークン管理テーブルにおいて、ＯＡｕｔｈのためのトークンを管理する。
【表２】
2016081351.tif 000004
【００２５】
認可トークン管理テーブルは、「認可トークンＩＤ」、「スコープ」、「有効期限」、「リフレッシュトークンＩＤ」、「リフレッシュ期限」、「クライアントＩＤ」をデータ項目として持つ。
【００２６】
認可トークンは、クライアントからスコープが指定されて発行を要求される。認証認可サーバは、要求元クライアントが要求スコープに対して権限を持つ場合には、認可トークンとリフレッシュトークンを生成し、クライアントに返信する。例えば、クライアントＩＤ「ｍｏｂｉｌｅ００００１」に対して、ＩＤ「ＡＴ＿０００１」の認可トークンがスコープ「Ａｐｐ１」有効期限「２０１４／４／８  ０：００」で発行される。そのトークンをリフレッシュするためのリフレッシュトークンがＩＤ「ＲＴ＿０００１」、リフレッシュ期限「２０１４／４／８  １：００」で発行される。
【００２７】
また、認証認可サーバ１１０は、表３に示すスコープ管理テーブルにおいて、ＯＡｕｔｈのためのスコープを管理する。
【表３】
2016081351.tif 000005
【００２８】
スコープ管理テーブルは、「スコープ」、「ロール」をデータ項目として持つ。「ロール」を持つクライアントは、「スコープ」に対してアクセス権限があることを示す。以上が、認証認可サーバ１１０が外部メモリ２４１にて記憶するデータテーブルに関する説明である。
【００２９】
次に、クライアント端末１５０が、外部メモリ２４１に記憶するデータを説明する。クライアント端末１５０は、端末自身のデータを保持するための記憶領域と、アプリケーション毎のデータを保持するための記憶領域とを持つ。また、それぞれのデータ領域には、バックアップ対象領域と、バックアップ非対称領域が存在する。例えば、端末自身のデータでバックアップ対象領域にあるデータには、アドレス帳や写真といったコンテンツデータ、日付と時刻の表示方法や言語環境の設定といった端末設定情報が含まれる。また、端末自身のデータでバックアップ非対称領域にあるデータには、端末ＩＤやバックアップ装置１８０への接続ＩＤが含まれる。
【００３０】
次に、アプリケーション毎のデータ（アプリケーションデータ）に関して説明する。表４に、アプリケーションデータの一例を示す。
【表４】
2016081351.tif 000006
【００３１】
アプリケーションデータのバックアップ対象領域には、アプリケーションがインストールされている端末を一意に識別する「端末ＩＤ」が存在する。「端末ＩＤ」は、クライアント端末１５０にて端末内アプリケーションが初回起動時に取得・保存するＩＤである。端末ＩＤとしては、端末内アプリケーションのインストール毎に生成される一意の値や端末ごとに設定されたＩＤといった、各端末で異なる値になるＩＤが利用される。これにより、端末を一意に識別可能としている。
【００３２】
また、アプリケーションデータには、認証認可サーバ１１０へアクセスするための「クライアント」、「シークレット」、認証認可サーバ１１０から取得したリフレッシュトークンが含まれる。「クライアント」には、クライアントＩＤが設定される。クライアントＩＤは、アプリケーション毎に設定されるので、アプリケーションを識別するための識別情報としても機能する。なお、アプリケーションデータには、アプリケーション自身の機能提供に必要な情報も含まれている。
【００３３】
次に、リソースサーバ１２０が外部メモリ２４１に記憶するデータの説明を行う。リソースサーバ１２０は、表５に示すクライアントデータ管理テーブルにおいて、「クライアントＩＤ」に紐づけて、アプリケーションデータを管理する。
【表５】
2016081351.tif 000007
【００３４】
次に、バックアップ装置１８０が外部メモリ２４１に記憶するデータの説明を行う。バックアップ装置１８０は、表６に示すユーザ管理テーブルにおいて、バックアップ装置１８０にログインするためのユーザ情報と端末のデータを管理する。
【表６】
2016081351.tif 000008
ユーザ管理テーブルは、ユーザを一意に識別する「ユーザＩＤ」、ユーザＩＤで認証するための「パスワード」、「端末データ」をデータ項目として持つ。
【００３５】
次に、クライアント端末１５０がバックアップ装置１８０にデータを保存する処理と、データをリストアする処理とを説明する。これらの処理により、クライアント端末１５０内のバックアップ対象データ全てをバックアップ装置１８０に保存したり、バックアップ装置１８０に保存されているデータをクライアント端末１５０にリストアしたりすることができる。
【００３６】
図４は、バックアップ処理とリストア処理を説明する図である。
事前にバックアップ装置１８０にユーザを登録してあり、クライアント端末１５０にバックアップ装置１８０のユーザＩＤとパスワードを保存してある前提で説明する。なお、特定のユーザのみしかアクセスできないローカルのバックアップ装置を適用して、ユーザ認証を不要としてもよい。
【００３７】
まず、バックアップ処理について説明する。ステップＳ４０１において、クライアント端末１５０が、バックアップ装置１８０にログインする。本ログインでは、クライアント端末１５０は、バックアップ装置１８０のユーザＩＤとパスワードとが利用される。バックアップ装置１８０は、ユーザ管理テーブルにてユーザＩＤとパスワードとを用いて、認証処理を実行し、認証に成功した場合は、以降の処理に進む。
【００３８】
次に、ステップＳ４０２において、クライアント端末１５０が、バックアップ対象領域に保存されているデータをバックアップ端末１８０に送信することで、データのバックアップをリクエストする。リクエストを受信したバックアップ装置１８０が、ステップＳ４０１でログインしたユーザＩＤと紐づけて端末のデータを保存する。
【００３９】
次に、リストア処理について説明する。ステップＳ４０３において、クライアント端末１５０が、バックアップ装置１８０にログインする。本ログインでは、バックアップ装置１８０のユーザＩＤとパスワードが利用される。バックアップ装置１８０ユーザ管理テーブルにてユーザＩＤとパスワードとを用いて、認証処理を実行し、認証に成功した場合は、以降の処理に進む。
【００４０】
ステップＳ４０４において、バックアップ装置１８０が、ユーザＩＤに紐づいて管理されている端末データをバックアップデータとしてクライアント端末１５０に送信する。クライアント端末１５０が、受信したバックアップデータをバックアップ対象領域のデータに保存する。
【００４１】
次に、旧クライアント端末（以下、「旧端末」と記載）１５０から新クライアント端末（以下、「新端末」と記載）１５０にデータを引き継ぎ、継続利用するための処理について説明する。データの引き継ぎ処理は、旧端末１５０にデータのバックアップを行い、新端末１５０にデータをリストアした後に実行される。
【００４２】
図５は、データの引継ぎ処理を説明する図である。
新端末１５０にて、端末内アプリケーション３５０が起動された際に処理が開始される。
【００４３】
ステップＳ５０１において、端末内アプリケーション３５０が、クライアント端末１５０が変更になっているかをチェックする。本チェックには、表４に示すアプリケーションデータの端末ＩＤを利用する。端末内アプリケーション１５１は、起動時にクライアント端末１５０から端末ＩＤを取得し、保存してあるアプリケーションデータの端末ＩＤと比較することで、同一端末での起動か、異なる端末での起動かを判別する。同一の端末での起動である場合は、以降の処理は行わず通常の利用となる。異なる端末での起動である場合は、後続の処理が継続される。
【００４４】
ステップＳ５０２において、端末内アプリケーション３５０が、認証認可サーバ１１０にクライアント更新要求を行う（認証情報要求手段として機能する）。クライアント更新要求は、リソースサーバ１２０への認証情報を含むクライアントの情報（この例では、クライアントＩＤ、シークレット、リフレッシュトークン）の更新を求める要求である。クライアント更新要求を行う際に、端末内アプリケーション３５０は、バックアップより復元された、旧クライアントＩＤとシークレット、クライアントを無効にするか否かを示す設定情報をパラメータとして渡す。旧クライアントＩＤとシークレットを無効にするか否かは、サービスの仕様により事前に決定され、連携する端末内アプリケーション３５０でどちらを送信するかを決める。旧クライアントＩＤと新クライアントＩＤとでデータを共有させたい場合には、無効にしない設定とし、旧クライアントＩＤで利用できるデータを新クライアントＩＤに引継ぎさせたい場合には無効にする設定とする。もちろん、サービスとしてどちらでも良い場合には、端末内アプリケーション３５０で選択させることも考えられる。この場合、ステップＳ５０２を実行する前に端末内アプリケーション３５０が、図８に示す選択画面を表示し選択させる。
【００４５】
図５の説明に戻る。ステップＳ５０３において、クライアント更新要求に応じて、認証認可サーバ１１０が、クライアントＩＤとシークレットのペアが正しいかを検証する。検証に失敗した場合は、エラーを通知する。検証に成功した場合は、後続の処理が継続される。
【００４６】
次に、ステップＳ５０４において、認証認可サーバ１１０が、新しいクライアントＩＤ、シークレット、リフレッシュトークンを新しいクライアントの情報として発行する。そして、認証認可サーバ１１０が、ステップＳ５０５において、新しいクライアントの情報を端末アプリケーション３５０に返信する。
【００４７】
ステップＳ５０２からステップＳ５０５の処理を具体例を用いてさらに説明する。ステップＳ５０２において、端末アプリケーション３５０が、クライアントＩＤ「ｍｏｂｉｌｅ００００１」と、このクライアントＩＤに対応するシークレット、クライアントを無効にすることを示す設定情報を含むパラメータで要求を出したとする。認証認可サーバ１１０は、ステップＳ５０３、Ｓ５０４の処理を行う。
【００４８】
図６は、図５のステップＳ５０３、Ｓ５０４の処理の詳細を説明するフローチャートである。
ステップＳ６０１において、認証認可サーバ１１０が、表１のクライアント管理テーブルを利用し、クライアントＩＤとシークレットのペアを検証する。検証に失敗した場合はステップＳ６０６において、認証認可サーバ１１０がエラーを通知する。
【００４９】
検証に成功した場合、ステップＳ６０２において、認証認可サーバ１１０が、新しいクライアントのＩＤ（新クライアントＩＤ）として、「ｍｏｂｉｌｅ００００３」を生成する。この際、認証認可サーバ１１０は、クライアントＩＤ「ｍｏｂｉｌｅ００００１」のロール設定を引き継ぐ。クライアントＩＤ「ｍｏｂｉｌｅ００００１」は、引継ぎ元のクライアントのＩＤ（旧クライアントＩＤ）である。さらに、認証認可サーバ１１０は、関連クライアントＩＤに旧クライアントＩＤ「ｍｏｂｉｌｅ００００１」を設定する。これにより、旧クライアントＩＤと関連クライアントＩＤとが関連付けられる。前述したように、クライアントＩＤは、アプリケーション毎に設定されるので、アプリケーションを識別するための識別情報としても機能する。旧クライアントＩＤは、旧認証情報に対応するアプリケーションを識別するための第１の識別情報であり、新クライアントＩＤは、新認証情報に対応するアプリケーションを識別するための第２の識別情報である。したがって、本設定により、複数のアプリケーションのそれぞれを区別しつつ、複数のアプリケーションでＷｅｂサービス提供サーバが管理するデータを共有できるようになる。
【００５０】
次に、ステップＳ６０３において、認証認可サーバ１１０が、新しい認可トークンの生成を行う。具体的には、認証認可サーバ１１０は、表２の認可トークン管理テーブルにて、クライアントＩＤ「ｍｏｂｉｌｅ００００１」が発行した認可トークンＩＤ「ＡＴ０００１」のスコープ設定を引き継ぐ。そして、認証認可サーバ１１０は、新しい認可トークンＩＤ「ＡＴ０００２」、リフレッシュトークンＩＤ「ＲＴ０００２」を生成する。
【００５１】
次に、ステップＳ６０４において、認証認可サーバ１１０が、端末内アプリケーション３５０から受信している設定情報に基づいて、旧クライアントを無効にするか否かを判断する。この例では、設定情報が、旧クライアントを無効にすることを示す。したがって、ステップＳ６０４において、認証認可サーバ１１０は、「ｍｏｂｉｌｅ００００１」のクライアントを削除し、さらに認可トークンＩＤ「ＡＴ０００１」とリフレッシュトークンＩＤ「ＲＴ０００１」のトークンを無効にする。
【００５２】
なお、設定情報が、旧クライアントを無効にしないことを示す場合には、認証認可サーバ１１０は、旧クライアントやトークンの削除処理を実行しない。これにより、旧クライアントと新クライアントの双方がリソースサーバ１２０が提供するＷｅｂサービスを利用することが可能となる。
【００５３】
ステップＳ５０５において、認証認可サーバ１１０が、クライアントＩＤ「ｍｏｂｉｌｅ０００３」、シークレット、認可トークンＩＤ「ＡＴ０００２」、リフレッシュトークンＩＤ「ＲＴ０００２」を新端末の情報として端末内アプリケーション３５０に返却する。返却された新端末の情報は、リソースサーバ１２０と連携する際に必要な情報であり、上記の処理によって、データ同期対象のアプリケーション（新端末の端末内アプリケーション３５０）に新端末の情報が同期される。
【００５４】
図５の説明に戻り、ステップＳ５０６以降の処理を説明する。
ステップＳ５０６において、端末内アプリケーション３５０が、新端末の情報を保存する。具体的には表４に示すアプリケーションデータにおいて、端末ＩＤを、ステップＳ５０１での端末チェックで取得した新しい端末ＩＤに設定し、クライアント、シークレット、リフレッシュトークンにステップＳ５０５で戻された値を設定する。
【００５５】
次に、ステップＳ５０７において、端末内アプリケーション３５０が、リソースサーバ１２０にリソース要求を行う。リソース要求には、ステップＳ５０５において取得したトークンを付与して送信する。要求を受け付けたリソースサーバ１２０が、要求元と権限確認のために、認証認可サーバ１１０にステップＳ５０８のトークン検証要求を送信する。トークン検証要求には、端末内アプリケーション３５０から受け取ったトークンと、リソースサーバが求めるスコープとを指定する。
【００５６】
認証認可サーバ１１０が、受け取ったトークンを次の手順で検証し、ステップＳ５０９において検証結果を返信する。認証認可サーバ１１０は、まず、受け取ったトークンが存在するか、期限が有効か、検証依頼されたスコープをトークンが保持しているかをチェックする。例えば、アクセストークン「ＡＴ０００２」、スコープ「Ａｐｐ１」を検証要求されたとする。認証認可サーバ１１０は、表２に示す認可トークン管理テーブルに基づいて、アクセストークン「ＡＴ０００２」がスコープ「Ａｐｐ１」を持っているか、有効期限内かを検証する。この例では、検証に成功するので、引き続きクライアント情報の取得を行う。アクセストークン「ＡＴ０００２」は、クライアント「ｍｏｂｉｌｅ００００３」であり、さらに表１のクライアント管理テーブルより、関連クライアントが「ｍｏｂｉｌｅ００００１」であることがわかる。したがって、ステップＳ５０９において、認証認可サーバ１１０は、検証に成功したことを示す検証結果と、クライアントが「ｍｏｂｉｌｅ００００３」であり、関連クライアントが「ｍｏｂｉｌｅ００００１」であること（クライアント情報）を返却する。
【００５７】
検証結果とクライアント情報を受け取ったリソースサーバ１２０は、関連クライアントがあるので、ステップＳ５１０の新クライアント識別リソース処理を実施する。ステップＳ５１０において、リソースサーバ１２０は、まず、クライアント「ｍｏｂｉｌｅ００００３」に対応したデータが存在するかを、表５に示すクライアントデータ管理テーブルでチェックする。クライアント「ｍｏｂｉｌｅ００００３」に対応したデータが存在しない場合には、データの引き継ぎ処理を実施する。関連クライアントは「ｍｏｂｉｌｅ００００１」であるので、「ｍｏｂｉｌｅ００００１」のアプリデータの紐付けを「ｍｏｂｉｌｅ００００３」に変更する。本処理でリソースサーバ１２０上のデータが旧端末１５０から新端末１５０へ引き継がれる。データの引き継ぎ処理が終了した後に、リソースサーバ１２０は、通常のリソース要求に対する処理を行い、ステップＳ５１１において、処理結果を返信する。以上の処理により、旧端末１５０から新端末１５０にデータを引き継ぎ、リソースサービス１２０を継続利用することが可能となる。
【００５８】
なお、ステップＳ６０４において、認証認可サーバが、旧クライアントを無効にしない場合に、新端末の端末内アプリケーション３５０からリソース要求がされたときは、リソースサーバ１２０は、以下の処理を実行する。リソースサーバ１２０は、上記と同様に、認証認可サーバ１１０から、検証に成功したことを示す検証結果と、クライアントが「ｍｏｂｉｌｅ００００３」であり、関連クライアントが「ｍｏｂｉｌｅ００００１」であること（クライアント情報）を受け取る。そして、リソースサーバ１２０は、関連クライアントに紐付いているデータを端末内アプリケーション３５０に返却する。リソースサーバ１２０が、関連クライアントとデータとの紐付けを維持したまま、このデータを「ｍｏｂｉｌｅ００００３」に紐付けるようにしてもよい。
【００５９】
次に、他の実施形態について説明する。他の実施形態では、前述した処理と比べて、図５のステップＳ５０２、Ｓ５０３の処理が異なる。前述した処理だと旧端末１５０にて作成したバックアップデータが古い場合に、リストア処理で不整合が発生する場合がある。例えば、バックアップ後にさらに旧端末１５０にて端末内アプリケーション３５０がリソースサーバ１２０を利用した場合を想定する。この場合、バックアップデータの内容が、リソースサーバ１２０の最新の状態とは異なってしまう。この状態で、このバックアップデータを新端末１５０にリストアすると、新端末１５０のデータとリソースサーバ１２０のデータは異なることになるので、データの破損や処理の継続ができないといった課題が発生する。
【００６０】
そこで、他の実施形態では、リフレッシュトークンを利用することでこの課題を解決する。リフレッシュトークンには有効期限が設定されており、端末内アプリケーション３５０は、起動時やトークン期限切れ時に新しいリフレッシュトークンを取得して、リソースサーバ１２０にアクセスする。つまり、リフレッシュトークンは、端末アプリケーション３５０によるリソースサーバ１２０の利用時に更新される。したがって、バックアップ時のリフレッシュトークンとリストア時のリフレッシュトークンが異なるときには、旧端末は、バックアップ後にリソースサーバ１２０を利用したということになる。
【００６１】
具体的な処理の流れを説明する。ステップＳ５０２において、端末内アプリケーション３５０がクライアント更新要求を実施する際に、表４に示すアプリケーションデータから復元した、リフレッシュトークンも合わせて送信する。要求を受け付けた認証認可サーバ１１０は、図６の処理に変えて、図７の処理を行う。
【００６２】
図７は、他の実施形態における認証認可サーバの処理を説明するフローチャートである。ステップＳ６０１からＳ６０６の処理は、図６を参照して前述した通りである。ステップＳ７０１において、認証認可サーバ１１０は、リフレッシュトークンも検証する。より詳細には、認証認可サーバ１１０は、表２に示す認可トークン管理テーブルにて、旧クライアントＩＤに紐づいているリフレッシュトークンと、ステップＳ５０２で渡されたリフレッシュトークンとが同一であるかの検証処理を追加で行う。本検証処理で、リフレッシュトークンが同一でない場合は、リフレッシュトークンが変更されたことになる。したがって、この場合は、ステップＳ７０２において、認証認可サーバ１１０が、検証に失敗したと判断して、端末内アプリケーション３５０に対してエラーを応答する。本検証処理で、リフレッシュトークンが同一である場合は、認証認可サーバ１１０は、検証に成功したと判断して、後続の処理を行う。以上により、バックアップデータの引継ぎを禁止することが可能となり、端末内アプリケーション３５０のデータとリソースサーバ１２０のデータの不整合を防止できる。
【００６３】
（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００６４】
１１０  認証サーバ
１２０  リソースサーバ
１５０  クライアント端末
１８０  バックアップサービス
【図１】
2016081351.tif 000009
【図２】
2016081351.tif 000010
【図３】
2016081351.tif 000011
【図４】
2016081351.tif 000012
【図５】
2016081351.tif 000013
【図６】
2016081351.tif 000014
【図７】
2016081351.tif 000015
【図８】
2016081351.tif 000016