JP2018195081A - 情報処理システム、制御方法及びそのプログラム - Google Patents

Abstract

【課題】 クラウドシステムを介してデバイスの機能を使う際に、ローカルユーザー認証情報をデバイスで特定し、その実行結果に対応するクラウドユーザー認証情報をクラウドシステムで特定し、リクエストとレスポンスとを紐付けることを目的とする。また、クラウドユーザー認証情報を切り替えずに、他のローカルユーザー認証情報を用いてデバイスの機能を実行することを目的とする。
【解決手段】 クラウドシステムとデバイスが、クラウドユーザー認証情報とローカルユーザー認証情報とを紐付けて管理し、デバイスの機能をクライアントデバイスに第一表示し、第一表示されたクライアントデバイスで選択されたデバイスの機能に応じて、ローカルユーザー認証情報を第二表示し、第二表示されたクライアントデバイスにおける選択に応じてローカルユーザー認証情報と実行要求とをデバイスに送信し、クラウドユーザー認証情報と実行結果とをクラウドシステムに送信する。
【選択図】 図８

Description

本発明は、クラウドシステムを介してデバイスの機能を実行する情報処理システム、制御方法及びそのプログラムに関するものである。

クライアントデバイスからクラウドシステムを介して他のデバイスにデータを送信するようなサービスが出てきている。また、デバイスの機能を利用するユーザー（以下、ローカルユーザー）を識別し、そのユーザーが利用できるデバイスの機能を制限するために、ローカルユーザーアカウントを設けるデバイスがある。このようなデバイスにおいてデバイスの機能を実行するためには、ローカルユーザーアカウントが必要となる。一方、クラウドシステムにおいてクラウドサービスを利用するユーザー（以下、クラウドユーザー）を識別し、そのユーザーが利用できるクラウドサービスを制限するために、クラウドユーザーアカウントを設けるクラウドシステムがある。このようなクラウドシステムにおいてクラウドサービスを実行するためには、クラウドユーザーアカウントが必要となる。

特許文献１には、ユーザーアカウント情報によってユーザーが認証された場合に、印刷ジョブの印刷を実行する印刷システムについて開示している。

特開２０１６−１８３３１

一人のユーザーが、デバイスにおいてデバイスの機能を利用するためにローカルユーザーアカウントを登録し、クラウドシステムにおいてクラウドサービスを利用するためにクラウドユーザーアカウントを登録しているものとする。両方のユーザーアカウントを用いて、クラウドサービスの一つであるＭＦＰ等のマルチユーザーデバイスの機能の実行を要求し、要求された機能がマルチユーザーデバイスにおいて実行され、その実行結果がマルチユーザーデバイスからクラウドシステムに送信される形態が考えられる。その形態において、マルチユーザーデバイスがクラウドシステムから実行要求をｐｕｌｌ型通信によって取得し、その実行要求に対する実行結果をマルチユーザーデバイスがクラウドシステムに対し送信する場合がある。ｐｕｌｌ型通信は、マルチユーザーデバイスがクラウドシステムに対して実行要求の取得をリクエストし、そのレスポンスとしてマルチユーザーデバイスが実行要求をクラウドシステムから受信することで通信が終了する。そのため、その実行結果をマルチユーザーデバイスからクラウドシステムに送信しても、実行要求を取得したｐｕｌｌ型通信と実行結果を送信する通信は互いに独立した非同期通信であるため、どの実行要求に対してどのような実行結果が得られたのかをクラウドシステムでは判断できない。つまり、どのリクエスト（実行要求）に対するレスポンス（実行結果）なのかを知るために、リクエストとレスポンスとを紐付ける手段が必要となる。

また、一人のユーザーが異なる複数のローカルユーザーアカウントを用いて、デバイスの機能を実行する場合がある。その際、クラウドシステムを介して、複数のローカルユーザーアカウントでデバイスの機能を実行するときの利便性を向上させることが課題となる。

本発明では、クラウドシステムを介して、複数のローカルユーザーアカウントでデバイスの機能を実行するときの利便性を向上させることを目的とする。

クラウドシステムが、クラウドサービスを利用する複数のクラウドユーザーを一意に識別するためのクラウドユーザー認証情報と、デバイスの機能を利用する複数のローカルユーザーを一意に識別するためのローカルユーザー認証情報と、前記ローカルユーザー認証情報を用いて実行可能な前記デバイスの機能に関する情報とを紐付けて管理するクラウド管理手段と、前記デバイスが、前記クラウドユーザー認証情報と前記ローカルユーザー認証情報とを紐付けて管理するデバイス管理手段と、を有する情報処理システムであって、前記クラウド管理手段によって管理されている前記デバイスの機能に関する情報をクライアントデバイスに第一表示させ、第一表示された前記クライアントデバイスにおいて選択された前記デバイスの機能に関する情報と前記クラウド管理手段によって紐付いて管理されている前記ローカルユーザー認証情報を、前記クライアントデバイスに第二表示させる表示作成手段と、第二表示された前記クライアントデバイスにおいて選択された前記ローカルユーザー認証情報を用いて、第一表示された前記クライアントデバイスにおいて選択された前記デバイスの機能の選択を受け付ける選択受付手段と、前記クラウドシステムが、前記クライアントデバイスからユーザー認証情報を受信して前記クラウドユーザーを認証した後に、前記クラウドユーザー認証情報に対して前記クラウド管理手段によって紐付けて管理されているローカルユーザー認証情報と、前記選択受付手段によって受付された選択に対応した前記デバイスの機能を実行するための実行要求とを前記デバイスに送信する実行要求送信手段と、前記デバイスが前記ローカルユーザー認証情報に基づいて、前記実行要求送信手段によって送信された実行要求を実行する実行手段と、前記クラウドシステムから前記実行要求とともに受信した前記ローカルユーザー認証情報に対して前記デバイス管理手段によって紐付けて管理されているクラウドユーザー認証情報と、前記実行手段によって実行された実行結果とを前記デバイスが前記クラウドシステムに送信する実行結果送信手段と、を有する。

また、クラウドシステムが、クラウドサービスを利用する複数のクラウドユーザーを一意に識別するためのクラウドユーザー認証情報と、デバイスの機能を利用する複数のローカルユーザーを一意に識別するためのローカルユーザー認証情報と、前記ローカルユーザー認証情報を用いて実行可能な前記デバイスの機能に関する情報とを紐付けて管理するクラウド管理手段と、前記デバイスが、前記クラウドユーザー認証情報と前記ローカルユーザー認証情報とを紐付けて管理するデバイス管理手段と、を有する情報処理システムであって、前記クラウド管理手段によって管理されているローカルユーザー認証情報をクライアントデバイスに第一表示させ、第一表示された前記クライアントデバイスにおいて選択された前記ローカルユーザー認証情報と前記クラウド管理手段によって紐付いて管理されている前記デバイスの機能に関する情報を、前記クライアントデバイスに第二表示させる表示作成手段と、第二表示された前記クライアントデバイスにおいて選択された前記デバイスの機能の選択を受け付ける選択受付手段と、前記クラウドシステムが、前記クライアントデバイスからユーザー認証情報を受信して前記クラウドユーザーを認証した後に、前記クラウドユーザー認証情報に対して前記クラウド管理手段によって紐付けて管理されているローカルユーザー認証情報と、前記選択受付手段によって受付された選択に対応した前記デバイスの機能を実行するための実行要求とを前記デバイスに送信する実行要求送信手段と、前記デバイスが前記ローカルユーザー認証情報に基づいて、前記実行要求送信手段によって送信された実行要求を実行する実行手段と、前記クラウドシステムから前記実行要求とともに受信した前記ローカルユーザー認証情報に対して前記デバイス管理手段によって紐付けて管理されているクラウドユーザー認証情報と、前記実行手段によって実行された実行結果とを前記デバイスが前記クラウドシステムに送信する実行結果送信手段と、を有する。

本発明により、クラウドシステムを介して、複数のローカルユーザーアカウントでデバイスの機能を実行するときの利便性を向上させることができる。

本発明の情報処理システムの全体図である。 情報処理装置２００の内部構成図である。 情報処理システム１０７を構成する各装置とクライアントデバイス１０２の機能ブロック図である。 認証サーバー１０３がデバイス１０５を認証する過程を示すシーケンス図である。 認証連携情報を発行する過程を示すシーケンス図である。 認証サーバー１０３におけるローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付けるユーザー紐付け処理を示すシーケンス図である。 デバイス１０５におけるローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付けるユーザー紐付け処理を示すシーケンス図である。 実施例１における機能呼び出し処理を示すシーケンス図である。 実施例１における、Ｗｅｂブラウザ３００の表示画面のイメージ図である。 Ｗｅｂブラウザ３００の実行結果画面のイメージ図である。 結果取得処理のフロー図である。 デフォルト画面のイメージ図である。 デバイス１０５における機能呼び出し処理を示すシーケンス図である。 実施例２における、Ｗｅｂブラウザ３００の表示画面のイメージ図である。 実施例３における機能呼び出し処理を示すシーケンス図である。 実施例３における、Ｗｅｂブラウザ３００の表示画面のイメージ図である。 実施例３における、Ｗｅｂブラウザ３００の実行結果画面のイメージ図である。 実施例４における再実行処理を示すシーケンス図である。 実施例４における再実行画面のイメージ図である。 実施例４における再実行処理を示すシーケンス図である。 共通鍵を用いた場合の、デバイス１０５におけるユーザー紐付け処理を示すシーケンス図である。 共通鍵を用いた場合の機能呼び出し処理を示すシーケンス図である。 実施例６における認証連携情報を発行する過程を示すシーケンス図である。 デバイス１０５におけるローカルユーザーＵＵＩＤと認証連携情報との紐付け処理を示すシーケンス図である。 認証サーバー１０３とデバイス１０５におけるローカルユーザーＵＵＩＤと認証連携情報との紐付け処理を示すシーケンス図である。

以下、本発明を実施するための最良の形態について実施例を用いて説明する。

図１を用いて、本発明の実施形態に係る情報処理システム１０７を構成するデバイス１０５とクラウドシステム１０６、さらに情報処理システム１０７に接続するクライアントデバイス１０２について説明する。図１では、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１００を経由してクライアントデバイス１０２が、情報処理システム１０７を構築するサーバーコンピューター群とデバイス１０５とを接続している状態が示されている。ＷＡＮ １００はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０１によって各デバイスと接続されている。

クライアントデバイス１０２はＰＣやスマードフォン、タブレット、画像形成装置等の情報処理装置である。認証サーバー１０３は、クラウドユーザーやローカルユーザー等のユーザーや、ＭＦＰ等のデバイス１０５を認証し、その認証情報を登録する。

サービスサーバー１０４は、ＷＡＮ１００を経由してクライアントデバイス１０２とデバイス１０５と通信可能であり、Ｍｅｓｓａｇｅ Ｑｕｅｕｉｎｇ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ （ＭＱＴＴ） Ｂｒｏｋｅｒによるメッセージ通信を行うサーバー等が挙げられる。ＭＱＴＴとはｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅモデルのメッセージ通信プロトコルである。ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅモデルは、メッセージ送信者（以下、ｐｕｂｌｉｓｈｅｒ）からメッセージ受信者（以下、ｓｕｂｓｃｒｉｂｅｒ）に対して、メッセージ仲介者であるＭＱＴＴ ｂｒｏｋｅｒを介してメッセージを配信する。実施例では、サービスサーバー１０４がＭＱＴＴ ｂｒｏｋｅｒ の機能を有するものとして説明する。ｓｕｂｓｃｒｉｂｅｒは、メッセージの送信先（以下、トピック）としてｓｕｂｓｃｒｉｂｅｒ自身を指定してメッセージをサービスサーバー１０４に送信し、そのトピックと一致したメッセージをサービスサーバー１０４から受信できるように予約する（以下、ｓｕｂｓｃｒｉｂｅ）。ｓｕｂｓｃｒｉｂｅするためにｓｕｂｓｃｒｉｂｅｒがサービスサーバー１０４に送信するメッセージをｓｕｂｓｃｒｉｂｅメッセージと呼ぶ。

ｐｕｂｌｉｓｈｅｒは、サービスサーバー１０４に対してトピックを指定したメッセージを送信する。サービスサーバー１０４は、そのトピックと同じトピックをｓｕｂｓｃｒｉｂｅしているｓｕｂｓｃｒｉｂｅｒに対してメッセージを配信する（以下、ｐｕｂｌｉｓｈ）。ｐｕｂｌｉｓｈｅｒがｐｕｂｌｉｓｈするためにトピックを指定してサービスサーバー１０４に送信するメッセージ、およびｓｕｂｓｃｒｉｂｅｒに送信されるメッセージをｐｕｂｌｉｓｈメッセージと呼ぶ。

トピックは「／」で区切られた階層構造（例：／Ａ／ＢＣ／Ｄ／Ｅ）になっており、トピックの完全一致または一部一致をｓｕｂｓｃｒｉｂｅｒ側で指定することで、指定した条件に合ったトピックのメッセージをｓｕｂｓｃｒｉｂｅｒが受信できる。サービスサーバー１０４は、受信したｐｕｂｌｉｓｈメッセージのトピックとｓｕｂｓｃｒｉｂｅメッセージのトピックとの一致不一致を確認しており、一致した場合はｐｕｂｌｉｓｈメッセージをｓｕｂｓｃｒｉｂｅｒに送信する。これにより、ファイヤーウォールでサービスサーバー１０４からデバイス１０５への通信が遮断されていても、ＭＱＴＴを用いることでデバイス１０５への通信が可能となる。

後述の実施例は、サービスサーバー１０４がＭＱＴＴ ｂｒｏｋｅｒの機能を有するものとして説明するが、デバイス１０５がサービスサーバー１０４からリクエストを取得できれば、他のプロトコルを用いた形態でもよい。例えば、デバイス１０５がサービスサーバー１０４に対して定期的に情報取得のためのリクエストを行い、そのレスポンスとしてサービスサーバー１０４からのリクエストを受信する形態も考えられる。

サービスサーバー１０４はクライアントデバイス１０２に対して、印刷サービスと設定変更サービス等のサービスを提供する。印刷サービスについては、デバイス１０５が画像形成装置などの印刷機能を有する場合、デバイス１０５に対する印刷要求を受信し、印刷結果を確認するための画面をＷｅｂブラウザ３００に提供する。設定変更サービスについては、デバイス１０５における設定変更を受け付けるための画面やクラウドユーザーが要求した設定変更結果を確認する画面をクライアントデバイス１０２に提供する。クライアントデバイス１０２上でのユーザー操作に従って発行される設定変更のリクエストは、サービスサーバー１０４を経由してデバイス１０５に届く。また、サービスサーバー１０４は、印刷サービスや設定変更サービス等を提供するための機能呼び出し制御サービスも提供する。機能呼び出し制御サービスでは、印刷サービスや設定変更サービス等を提供するためにクライアントデバイス１０２から要求されたリクエストの受付やデバイス１０５から受信した実行結果を、指示したクラウドユーザーにのみ表示させるための制御を行う。後述の実施例では、サービスサーバー１０４がデバイス１０５の印刷サービスを提供する例で説明するが、設定変更サービスなどの他のサービスでも良い。また、印刷サービス、あるいは設定変更サービス等のいずれか一つのサービスのみを提供する形態でもよく、複数のサービスを提供する形態であっても良い。

デバイス１０５は、画像形成装置、ＰＣ、スマートフォン等の情報処理装置であり、複数のローカルユーザーに関する情報を管理する機能を有するデバイスである。デバイス１０５は、ＭＱＴＴ Ｂｒｏｋｅｒであるサービスサーバー１０４に対してトピックを指定したｓｕｂｓｃｒｉｂｅメッセージを送信することで、そのトピックと一致したｐｕｂｌｉｓｈメッセージを受信することができる。

また、本発明の認証サーバー１０３やサービスサーバー１０４等の各サーバーコンピューターは複数台で構成されていてもよく、または、ひとつのコンピューターサーバーが認証サーバー１０３やサービスサーバー１０４の機能を兼ね備えていても良い。例えば、サービスサーバー１０４は、ＭＱＴＴ Ｂｒｏｋｅｒと機能呼び出し制御サービスを提供する機能呼び出し制御サーバーとに分割することもできる。

図２は、図１に示したクラウドシステム１０６を構成するサーバーコンピューターである情報処理装置２００の内部構成について示したブロック図である。なお、図２に示されるブロック図は、クライアントデバイス１０２およびデバイス１０５も情報処理装置２００と同様の内部構造を有しているものとする。

情報処理装置２００において、ＣＰＵ２０２、ＲＯＭ２０３、ＲＡＭ２０４、ＨＤＤ２０５が内部バス２０１を介して接続されている。ＣＰＵ２０２は、ＲＯＭ２０３のブートプログラムを実行してＨＤＤ２０５に記憶されているＯＳや制御プログラムをＲＡＭ２０４に展開し、そのプログラムに基づいて、情報処理装置２００の制御を行うユニットである。

ＲＯＭ２０３は、情報処理装置２００のブートプログラムや各種データ等が格納されている記憶装置である。

ＲＡＭ２０４は、ＣＰＵ２０２が命令を実行する際に使用するワークメモリである。ＲＯＭ２０３に保存されていたプログラムがＲＡＭ２０４へとロードされ、そのプログラムの命令をＣＰＵ２０２が順次読みだし命令を実行する。

ＨＤＤ２０５は外部記憶装置であり、ＯＳや各種プログラムを格納している。

ネットワークＩ／Ｆ２０６は、内部バス２０１を介してＣＰＵ２０２、ＲＯＭ２０３、ＲＡＭ２０４、ＨＤＤ２０５と接続されており、ＬＡＮ１００等のネットワークを介して情報処理装置２００への情報の入出力を行う。

尚、後述の全ての説明においては、特に断りのない限りコンピューターサーバーやデバイス等のハード上の主体はＣＰＵ２０２であり、ソフトウェア上の主体はＨＤＤ２０５にインストールされたアプリケーションプログラムである。

図３を用いて、クライアントデバイス１０２と認証サーバー１０３、サービスサーバー１０４、デバイス１０５が有する機能について説明する。クライアントデバイス１０２が有するＷｅｂブラウザ３００を含め、実施例における情報処理システム１０７内の装置が有する機能は、各装置のＣＰＵ２０２がＲＡＭ２０４にロードされたアプリケーションプログラムを実行することで実現される。機能の中でも特に、認証サーバー１０３やサービスサーバー１０４等のサーバーコンピューター上で実現される機能または機能群のことをクラウドサービスという。

クライアントデバイス１０２はＷｅｂブラウザ３００を備え、Ｗｅｂブラウザ３００は認証サーバー１０３やサービスサーバー１０４との通信を行う。Ｗｅｂブラウザ３００は、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を利用するためのユーザーエージェントによって実現する機能であり、後述のＷｅｂブラウザ３０７も同様である。Ｗｅｂブラウザ３００に入力される情報とは具体的に、デバイス１０５の機能に関する情報やローカルユーザーＵＵＩＤ等のローカルユーザー認証情報であり、詳細については後述する。

認証サーバー１０３は通信部３０１と認証部３０２とを備える。認証部３０２は、通信部３０１を介してクライアントデバイス１０２やサービスサーバー１０４、デバイス１０５との通信を行う機能である。

サービスサーバー１０４は、通信制御部３０３と設定管理部３０４と印刷管理部３０５と機能・ユーザー管理部３０６とを備える。通信制御部３０３は、ＭＱＴＴにおけるｓｕｂｓｃｒｉｂｅメッセージの受付やｐｕｂｌｉｓｈメッセージの配信を行う機能である。また、設定管理部３０４は通信制御部３０３を介して、クライアントデバイス１０２の設定画面を介した要求の受付や、クライアントデバイス１０２で実行結果画面を表示するための設定情報を管理する機能である。印刷管理部３０５は、機能呼び出し制御部３１０からの印刷要求の受付や、Ｗｅｂブラウザ３００で印刷画面を表示するための印刷情報を管理している。機能・ユーザー管理部３０６は、ログイン中のクラウドユーザーが利用可能なローカルユーザー認証情報や利用可能な機能等を管理しており、通信制御部３０３を介して、リクエストの受付やそれに対する応答等を行っている。また、機能・ユーザー管理部３０６は、Ｗｅｂブラウザ３００に表示する画面を生成し、Ｗｅｂブラウザ３００に送信する機能も有する。表１において、機能・ユーザー管理部３０６が管理しているテーブルの一例を示す。

デバイス識別情報は、デバイス１０５を一意に識別する情報である。以降の実施例では、デバイス識別情報は証明書の形態を持つものとして説明するが、認証部３０２がデバイス１０５を一意に識別できさえすれば、デバイス識別情報は証明書の形態や数値文字列の形態などでも良い。

また、ローカルユーザーＵＵＩＤはローカルユーザーを一意に識別するための情報であり、詳細は後述する。表１の例によれば、ユーザーがローカルユーザーＵＵＩＤ「ＡＡＡ１」を用いて、「印刷」機能と「設定値変更」機能と「フォームアップデート」機能とを利用することができる。表１は機能・ユーザー管理部３０６が管理しているテーブルの一例であり、ローカルユーザーＵＵＩＤとその利用可能な機能が結びついてさえいれば、表１以外の形態でも良い。

デバイス１０５は、Ｗｅｂブラウザ３０７とローカルログイン部３０８、認証サーバー連携部３０９、機能呼び出し制御部３１０とを備える。Ｗｅｂブラウザ３０７は、認証サーバー１０３やサービスサーバー１０４と通信を行う機能である。ローカルログイン部３０８は、デバイス１０５の利用者であるローカルユーザーを認証するための機能である。なお、このローカルログイン部３０８は、不図示の認証サーバーと通信することでローカルユーザーを認証するように構成することもできる。

認証サーバー連携部３０９は認証連携情報の発行要求を行う。また、認証サーバー連携部３０９は、クラウドシステム１０６の利用者であるクラウドユーザーを一意に識別するための情報であるクラウドユーザー認証情報と、ローカルユーザーを一意に識別するための情報であるローカルユーザー認証情報とを紐付ける機能でもある。

認証連携情報とはクラウドユーザー認証情報とローカルユーザー認証情報とを紐付けるために用いられる認証情報である。認証連携情報の一例として、パスコード等が挙げられる。クラウドユーザー認証情報は、クラウドユーザーがクラウドシステム１０６ログインした時に生成される認証情報の総称であり、クラウドユーザーＩＤやクラウドユーザーＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）等のクラウドユーザーを一意に識別するための情報が含まれる。ＵＵＩＤとは、ユーザーを一意に識別するための識別子であり、ＩＤとは違って他のユーザーと重複しないことを前提に作られている。つまり、クラウドユーザーＵＵＩＤを用いることで、マルチテナントシステムにおいてテナントごとに設定されたユーザー情報も全て識別できるものとする。後述の例では、クラウドユーザー認証情報としてトークンの形態を用いて説明しているが、クラウドユーザーを識別できる情報であればどのような形態でもよい。一方、ローカルユーザー認証情報とは、ローカルユーザーがデバイス１０５にログインした時に生成される認証情報の総称であり、ローカルユーザーＩＤやローカルユーザーＵＵＩＤ等のローカルユーザーを一意に識別するための情報が含まれる。後述の例では、ローカルユーザー認証情報としてトークンの形態を用いて説明しているが、ローカルユーザーを識別できる情報であればどのような形態でもよい。後述では、認証連携情報を用いてクラウドユーザーＵＵＩＤとローカルユーザーＵＵＩＤとを紐付けた紐付け情報を例に説明する。

機能呼び出し制御部３１０は、後述のクラウドユーザーＵＵＩＤとローカルユーザーＵＵＩＤとを紐付けるユーザー紐付け処理において、ｓｕｂｓｃｒｉｂｅメッセージをサービスサーバー１０４に送信し、サービスサーバー１０４からの処理要求を待つ。

図４を用いて、認証サーバー１０３がデバイス１０５を認証する過程を説明する。この過程は、デバイス１０５において認証サーバー連携部３０９がインストールされ、初めて認証サーバー連携部３０９が起動したタイミングで開始されるものとする。認証サーバー１０３の通信部３０１はデバイス１０５の認証が必要になるように構成されている。

Ｓ１．１にて、認証サーバー連携部３０９が通信部３０１に対してデバイス登録要求を送信する。具体的には、認証サーバー連携部３０９からデバイス登録要求を受信した通信部３０１は、ＳＳＬ／ＴＬＳ通信のネゴシエーションを開始する。その際、通信部３０１は、認証サーバー連携部３０９に対してデバイス認証情報を要求して受信する。デバイス認証情報とは、デバイス１０５を特定するためにＳＳＬ／ＴＬＳ通信に用いられる証明書である。Ｓ１．２において、通信部３０１は不図示の証明書ストアにて設定されている証明書を用いて、Ｓ１．１で取得したデバイス認証情報を検証し、認証サーバー連携部３０９をデバイス１０５の登録要求元として認証する。Ｓ１．３にて、通信部３０１が認証部３０２に対して、認証サーバー連携部３０９から受信したデバイス登録要求とデバイス認証情報とを送信する。Ｓ１．４において認証部３０２は、Ｓ１．３で取得したデバイス認証情報を基に、デバイス１０５を一意に識別するためのデバイス識別情報を発行する。Ｓ１．５にて、認証部３０２は通信部３０１を介して認証サーバー連携部３０９に対して、デバイス登録要求に対する応答としてデバイス識別情報を送信する。

以上が、認証サーバー１０３がデバイス１０５を認証する過程である。この過程で認証部３０２が発行したデバイス識別情報を用いることで、認証サーバー連携部３０９はデバイス１０５を特定することが可能となる。また、本実施例の事前設定は、認証サーバー連携部３０９を認証部３０２への登録する登録処理としているが、その処理には必ずしも限定されない。例えば、認証部３０２が発行したデバイス識別情報を認証サーバー連携部３０９へ手動で登録しても良い。また、出荷時に認証サーバー連携部３０９へ埋め込まれているデバイス認証情報をそのまま利用しても良い。また、以降の実施例では、「外部から通信部３０１を介して認証部３０２への通信」を、「外部から認証部３０２への通信」と記載する。

［実施例１］
デバイス１０５がマルチユーザーデバイスである場合、一つのローカルユーザーＵＵＩＤに対して複数のクラウドユーザーＵＵＩＤの紐付けを許容する。実行結果がどのクラウドユーザーＵＵＩＤに対するものなのかをクラウドシステム１０６で特定し、リクエストとレスポンスとを紐付ける形態を実施例１で説明する。デバイス１０５の登録処理が成された状態（図４）で、認証部３０２が管理するクラウドユーザーＵＵＩＤとローカルログイン部３０８が管理するローカルユーザーＵＵＩＤとを紐付けるための認証連携情報を発行する過程を図５で説明する。

Ｓ２．１においてローカルログイン部３０８は、ローカルログイン部３０８において定められている認証方法によってユーザーのログイン処理を受け付ける。認証方法としては例えば、ユーザーＩＤとパスワードとの組み合わせを検証する方法、指紋等の生体情報を検証する方法、非接触型のＩＣカードを利用する方法、更には複数の認証方法を組み合わせる多要素認証方法等が考えられる。また、不図示の認証サーバーと通信することでユーザーを認証するように構成することもできる。実施例１では、ローカルユーザーＩＤとパスワードとの組み合わせを検証する認証方法を用いた場合を例として説明する。表２は、ローカルログイン部３０８が管理するユーザー情報の一例である。

Ｓ２．２にて、ローカルログイン部３０８ローカルユーザーＩＤとパスワードの組を用いてローカルユーザー認証を行う。具体的には、表１のユーザー情報を参照してローカルユーザー認証を行う。例えば、ユーザーがローカルユーザーＩＤ「ａｄｍｉｎ」とパスワード「ａｄｍｉｎ」を入力した場合、ローカルログイン部３０８はローカルユーザーＩＤ「ａｄｍｉｎ」のローカルユーザーとしてユーザーを認証する。

Ｓ２．３でローカルログイン部３０８は、Ｓ２．２で認証されたユーザーのローカルユーザー認証情報を生成し保存する。このローカルユーザー認証情報は、ユーザーが不図示のログアウト操作を実施するか、設定された時刻が経過するまで有力な状態で保存される。ローカルユーザー認証情報には、認証したユーザーのローカルユーザーＩＤ、ローカルユーザーＵＵＩＤ及び権限情報等が格納されている。つまり、表１で示したユーザー情報とほとんど同じ情報をローカルユーザー認証情報は含む。なお、ローカルログイン部３０８がローカルユーザー認証情報を直接格納する形態に限らない。ローカルユーザー認証情報と紐付けられたトークンをローカルログイン部３０８が格納し、そのトークンを参照することでローカルログイン部３０８とは別の場所に格納されたローカルユーザー認証情報を用いる形態でもよい。

Ｓ２．４において、Ｗｅｂブラウザ３０７はユーザーの操作により認証連携情報の発行要求を受け付ける。受け付けた発行要求に応じて、Ｗｅｂブラウザ３０７は認証サーバー連携部３０９に対して認証連携情報の発行要求を送信する（Ｓ２．５）。Ｓ２．６で認証サーバー連携部３０９は、ローカルログイン部３０８に対してローカルユーザーＵＵＩＤの取得要求を行う。Ｓ２．６の要求に対して、ローカルログイン部３０８は認証サーバー連携部３０９にローカルユーザーＵＵＩＤを応答する（Ｓ２．７）。Ｓ２．８にて、認証サーバー連携部３０９は認証部３０２に認証連携情報の発行要求を送信する。その際、Ｓ２．７で受信したローカルユーザーＵＵＩＤとＳ１．５で受信したデバイス識別情報とを認証部３０２に送信する。

Ｓ２．９で認証部３０２は認証連携情報を発行する。その際に発行される認証連携情報と有効期限のテーブルの例を表３に示す。実施例１では認証連携情報を文字列としているが、後述するようにＱＲコード（登録商標）などの形態の情報であっても構わない。また、実施例１では認証連携情報に有効期限が定められているが、無期限の認証連携情報でも良い。

Ｓ２．１０において、認証部３０２はＳ２．９で発行された認証連携情報とＳ２．８で受信したローカルユーザーＵＵＩＤ及びデバイス識別情報とを紐付けて管理する。紐付け情報の例を表４に示す。

Ｓ２．１１にて、認証部３０２が認証サーバー連携部３０９に対して認証連携情報を応答する。認証サーバー連携部３０９は、ローカルユーザーＵＵＩＤとＳ２．１１で受信した認証連携情報とを紐付ける（Ｓ２．１２）。その際に生成されるマッピングテーブルの例を表５に示す。

Ｓ２．１３において、認証サーバー連携部３０９はＷｅｂブラウザ３０７に、Ｓ２．５の認証連携情報の発行要求に対する応答を行う。具体的には、Ｓ２．１１で応答された認証連携情報をＷｅｂブラウザ３０７に送信し、Ｗｅｂブラウザ３０７は認証連携情報を表示する。これにより、ユーザーは認証連携情報を入手できる。Ｓ２．１４で、後述するユーザー紐付け処理のために、認証サーバー連携部３０９は機能呼び出し制御部３１０に対して、通信制御部３０３へのｓｕｂｓｃｒｉｂｅメッセージの送信を依頼する。Ｓ２．１５にて、機能呼び出し制御部３１０が通信制御部３０３に対してｓｕｂｓｃｒｉｂｅメッセージを送信する。ｓｕｂｓｃｒｉｂｅメッセージを送信する際のトピックはデバイス識別情報である。具体的には、トピックは「／」で区切られた階層構造（例：／Ａ／ＢＣ／Ｄ／Ｅ）になっており、ｓｕｂｓｃｒｉｂｅｒが受信したい情報の分類を定義できるので、例えば「（デバイス１０５が設置されている場所）／（デバイス識別情報）」というように、メッセージの送信先を指定する。これによりデバイス１０５のデバイス識別情報をトピックとするｐｕｂｌｉｓｈメッセージを、機能呼び出し制御部３１０が受信できる。また、機能呼び出し制御部３１０は通信制御部３０３との通信を維持するために、通信の切断を検知する度に通信制御部３０３に対してｓｕｂｓｃｒｉｂｅメッセージを送信する。

以上が認証連携情報を発行する過程である。これにより、認証サーバー１０３とデバイス１０５は、認証連携情報を用いたマッピングテーブル（表４、表５）を所有できる。また、ユーザーも認証連携情報を入手できる。複数の認証連携情報を発行するためには、図５に示したシーケンスを繰り返す必要がある。例えばシーケンスを２回繰り返した結果、認証サーバー連携部３０９において生成されるマッピングの例を表６に示す。

次に、認証サーバー１０３においてローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付けるユーザー紐付け処理について、図６を用いて説明する。Ｓ３．１でＷｅｂブラウザ３００はユーザーからログイン操作を受け付け、Ｓ３．２でＷｅｂブラウザ３００は認証部３０２に対してログイン処理を要求する。このログイン処理は認証部３０２において定められている認証方法によって行われる。認証方法としては例えば、ユーザーＩＤとパスワードの組み合わせを検証する方法を利用する方法等がある。実施例１では、クラウドユーザーＩＤとパスワードの組み合わせを例として説明する。表７に認証部３０２が管理するユーザー情報の一例を示す。

Ｓ３．３において認証部３０２はクラウドユーザー認証を行い、Ｓ３．４で認証したクラウドユーザーのクラウドユーザー認証情報を生成し保存する。クラウドユーザー認証情報は、ユーザーが不図示のログアウト操作を実施するか、設定された時刻が経過するまで有力な状態で保存される。クラウドユーザー認証情報には、認証したクラウドユーザーのクラウドユーザーＩＤ、クラウドユーザーＵＵＩＤが格納されている。つまり、表７で示したユーザー情報とほとんど同じ情報をクラウドユーザー認証情報は含む。なお、認証部３０２が各認証情報を直接格納する形態のみならず、各認証情報が参照可能に紐付けられたトークンを認証部３０２が格納し、そのトークンを参照することで認証部３０２とは別の場所に格納された認証情報を用いるようにした形態でもよい。

Ｓ３．５において、認証部３０２はＷｅｂブラウザ３００にログイン処理に対する応答を行う。その際、Ｓ３．４において生成されたクラウドユーザーＵＵＩＤと紐付くセッションＩＤがＷｅｂブラウザ３００に送信される。セッションＩＤとは、ログインしたユーザーを識別するための識別子であり、本実施例ではＳ３．４において生成されたクラウドユーザーＵＵＩＤと紐付いて認証部３０２で管理されている。Ｓ３．５においてセッションＩＤをＷｅｂブラウザ３００が受信することで、Ｗｅｂブラウザ３００のＣｏｏｋｉｅ（不図示）にセッションＩＤが管理される。後述の実施例では特に断りがない限り、Ｗｅｂブラウザ３００と認証部３０２における通信では、このセッションＩＤの受送信が行われる。

Ｓ３．６で、認証連携情報の入力要求をユーザーから受け付け、Ｓ３．７でＷｅｂブラウザ３００は認証部３０２に対して認証連携情報の入力要求を送信する。認証部３０２はＷｅｂブラウザ３００からの認証連携情報入力要求に対して入力画面を応答する（Ｓ３．８）。Ｓ３．９にてＷｅｂブラウザ３００はユーザーによる認証連携情報の入力操作を受け付け、Ｓ３．１０において、受け付けた認証連携情報を認証部３０２に送信し、認証連携情報を用いた紐付け処理を要求する。具体的に、認証連携情報「ＸＸＸ−ＹＹＹ−ＺＺＺ」をＷｅｂブラウザ３００の入力画面に入力されたものとする。Ｓ３．１１において認証部３０２は、Ｓ３．１０で受信した認証連携情報と認証部３０２が管理しているクラウドユーザーＵＵＩＤとを紐付ける。具体的には、認証部３０２が管理しているセッションＩＤと、Ｓ３．１０でＷｅｂブラウザから受信したセッションＩＤとを照合し、そのセッションＩＤを介してクラウドユーザーＵＵＩＤと認証連携情報とを紐付ける。その際に生成される紐付け情報の例を表８に示す。

Ｓ３．１２において、認証部３０２が、Ｓ２．１０で作成したマッピングテーブル（表４）とＳ３．１１で作成したマッピングテーブル（表８）とを一つのマッピングテーブルにまとめ、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付ける。具体的には、表４と表８とが共通の認証連携情報を有するのでその認証連携情報を介して、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付ける。その際に生成される紐付け情報の例を表９に示す。

Ｓ３．１３において、認証部３０２が通信制御部３０３を介して機能・ユーザー管理部３０６に対して、クラウドユーザーＵＵＩＤとローカルユーザーＵＵＩＤとセッションＩＤとが紐づいた紐付け情報を送信する。

Ｓ３．１４において、機能・ユーザー管理部３０６はクラウドユーザーＵＵＩＤとローカルユーザーＵＵＩＤと利用可能な機能とを紐付ける紐付け処理を実行する。具体的には、Ｓ３．１２で生成された紐付け情報（表９）と、機能・ユーザー管理部３０６が管理する情報（表１）とがローカルユーザーＵＵＩＤを共通して有しているので、そのローカルユーザーＵＵＩＤを介してクラウドユーザーＵＵＩＤとローカルユーザーＵＵＩＤと利用可能な機能とを紐付ける。その際に生成されるテーブルの一例を表１０に示す。表１０は一例であり、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとその利用可能な機能が結びついてさえいれば、どのような形態でも良い。また、表１０には示していないが、クラウドユーザーＵＵＩＤと、Ｓ３．１３で機能・ユーザー管理部３０６が受信したセッションＩＤとが紐付いている。後述の表１１と表１２においても同様である。

また、認証サーバー１０３において複数のローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付けるためには、Ｓ３．６〜Ｓ３．１４（図６）のシーケンスを繰り返す必要がある。シーケンスを繰り返した結果、認証部３０２において生成されるマッピングの例を表１１に、機能・ユーザー管理部３０６において生成されるマッピングの例を表１２に示す。

以上が、認証サーバー１０３においてローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとが紐付く紐付け処理である。表９〜表１２のようなマッピングテーブルを作成する際に、認証連携情報が有効期限を迎え無効化されていれば、マッピングテーブル作成に失敗し、そのユーザー紐付け処理を終了する。その際に、マッピングテーブル作成に失敗した旨をＷｅｂブラウザ３００に通知しても良い。

次に、デバイス１０５においてローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付けるユーザー紐付け処理を、図７を用いて説明する。Ｓ４．１において、認証部３０２が通信制御部３０３に対して、Ｓ３．９で入力された認証連携情報とクラウドユーザーＵＵＩＤの紐付け依頼とともにｐｕｂｌｉｓｈメッセージを送信する。ｐｕｂｌｉｓｈメッセージを送信する際のトピックはデバイス識別情報とする。これにより、Ｓ２．１５で機能呼び出し制御部３１０が通信制御部３０３に送信したｓｕｂｓｃｒｉｂｅメッセージと同じトピックのｐｕｂｌｉｓｈメッセージを送信することができる。認証部３０２が送るメッセージは、通信制御部３０３がＭＱＴＴと他のプロトコルとの変換機能を備えていれば、ＭＱＴＴのｐｕｂｌｉｓｈメッセージでなくても構わない。

Ｓ４．２において、ｓｕｂｓｃｒｉｂｅメッセージを送信した機能呼び出し制御部３１０に対して、クラウドユーザーＵＵＩＤの紐付け依頼としてｐｕｂｌｉｓｈメッセージを送る。その際、クラウドユーザーＵＵＩＤと認証連携情報も同時に送信される。Ｓ４．３にて、機能呼び出し制御部３１０は認証サーバー連携部３０９にクラウドユーザーＵＵＩＤの紐付け要求を送信する。その際、Ｓ４．２で受信した認証連携情報とクラウドユーザーＵＵＩＤも同時に通知する。Ｓ４．４において認証サーバー連携部３０９は、Ｓ４．３で受信したクラウドユーザーＵＵＩＤと認証連携情報とを用いて、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとの紐付け処理を行う。認証サーバー連携部３０９は、ローカルユーザーＵＵＩＤと認証連携情報との紐付け情報を管理している（Ｓ２．１２）ため、認証連携情報を介してローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付けることができる。図７のシーケンスを複数回繰り返すことで、デバイス１０５において複数のローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付けることができる。その際に生成される紐付け情報の例を表１３に示す。

以上が、デバイス１０５におけるローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付けるユーザー紐付け処理である。図６のユーザー紐付け処理により認証サーバー１０３ではローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとが紐づき、図７のユーザー紐付け処理によりデバイス１０５ではローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとが紐付いた。

次にデバイス１０５における機能呼び出し処理を図８で説明する。実施例１において、既に説明しているステップと同じステップには同じ符番をふり、説明は省略する。Ｓ５．１においてＷｅｂブラウザ３００は、現在ログインしているクラウドユーザーが利用可能な機能の要求操作を受け付ける。Ｓ５．２において、Ｓ５．１でＷｅｂブラウザ３００は受け付けたユーザーの操作に応じて、機能・ユーザー管理部３０６に利用可能な機能を要求する。

Ｓ５．３において、機能・ユーザー管理部３０６はＷｅｂブラウザ３００に利用可能な機能を応答する。具体的には機能・ユーザー管理部３０６は表１２を参照して、Ｓ５．２で送信されたセッションＩＤと紐付く利用可能な機能をＷｅｂブラウザ３００に送信する。機能・ユーザー管理部３０６においてセッションＩＤとクラウドユーザーＵＵＩＤとが紐付いている（Ｓ３．１４）ので、Ｓ５．２でＷｅｂブラウザ３００が機能・ユーザー管理部３０６にセッションＩＤを送信することで、表１２によってセッションＩＤと紐付くクラウドユーザーＵＵＩＤが特定される。さらにそのクラウドユーザーＵＵＩＤと紐付く利用可能な機能が表１２で特定され、特定された利用可能な機能をＷｅｂブラウザ３００に送信する。Ｗｅｂブラウザ３００が利用可能な機能を表示したときの表示画面の一例を図９（ａ）に示す。図９（ａ）では、利用可能な機能として「印刷」、「設定値変更」、「ファームアップデート」の３つの機能が表示されている。本実施例では、図９の表示画面を機能・ユーザー管理部３０６で作成されているものとするが、サービスサーバー１０４または認証サーバー１０３であれば、Ｗｅｂブラウザ３００の表示画面はどこが作成されても良い。後述の表示画面（図１０、１２、１４、１６、１７、１９）も同様である。

Ｓ５．４において、ユーザーの操作によりＷｅｂブラウザ３００は機能選択操作を受け付ける。図９（ａ）はユーザーが「印刷」機能を選択した様子を示す。Ｓ５．５において、Ｗｅｂブラウザ３００は利用可能なローカルユーザーＵＵＩＤの要求を機能・ユーザー管理部３０６に対して送信する。

Ｓ５．６において、機能・ユーザー管理部３０６はＳ５．５で受信したセッションＩＤと機能・ユーザー管理部３０６で管理している紐付け情報（表１２）に基づいて、Ｗｅｂブラウザ３００にログインしているクラウドユーザーが利用可能なローカルユーザーＵＵＩＤを応答する。具体的には、機能・ユーザー管理部３０６においてセッションＩＤとクラウドユーザーＵＵＩＤとが紐付いている（Ｓ３．１４）ので、Ｓ５．５でＷｅｂブラウザ３００が機能・ユーザー管理部３０６にセッションＩＤを送信することで、表１２を用いてセッションＩＤと紐付くクラウドユーザーＵＵＩＤが特定される。さらにそのクラウドユーザーＵＵＩＤと紐付くローカルユーザーＵＵＩＤが表１２で特定され、特定されたローカルユーザーＵＵＩＤをＷｅｂブラウザ３００に送信する。その際の表示画面の一例を図９（ｂ）に示す。図９（ｂ）では、利用可能なローカルユーザーＵＵＩＤとして「ＡＡＡ１」と「ＡＡＡ２」とが表示されている。ユーザー操作により本画面の選択がされると、後述のＳ５．８のステップが開始される。

Ｓ５．７において、Ｗｅｂブラウザ３００はユーザーからローカルユーザー選択操作を受け付ける。図９（ｃ）では、ユーザーはローカルユーザーＵＵＩＤ「ＡＡＡ１」を選択した様子を示す。Ｓ５．８において、Ｓ５．７で選択されたローカルユーザーＵＵＩＤを用いて、Ｓ５．４で選択されたデバイス１０５の機能を実行するための実行要求がＷｅｂブラウザ３００から機能・ユーザー管理部３０６に送信される。その際、ローカルユーザーＵＵＩＤとデバイス識別情報も機能・ユーザー管理部３０６に送信される。今回、Ｗｅｂブラウザ３００とサービスサーバー１０４間のメッセージ通信プロトコルがＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）だとすると、Ｓ５．８でＷｅｂブラウザ３００から送信される実行要求は、ＨＴＴＰの方式に従ったリクエストメッセージである。以降のＷｅｂブラウザ３００とサービスサーバー１０４間のやり取りも同様である。

Ｓ５．９において、Ｓ５．８で受信したローカルユーザーＵＵＩＤとデバイス識別情報と実行要求とが機能・ユーザー管理部３０６から印刷管理部３０５に送信される。具体的には、Ｓ５．８で実行要求として受信したリクエストメッセージが、印刷管理部３０５に送信される。

Ｓ５．１０において、印刷管理部３０５は通信制御部３０３に対して、Ｓ５．９で受信したローカルユーザーＵＵＩＤとデバイス識別情報と実行要求とを送信する。今回は、サービスサーバー１０４がＭＱＴＴによるメッセージ通信を行うサーバーである場合を例に説明しているので、ｐｕｂｌｉｓｈメッセージとして実行要求が印刷管理部３０５から通信制御部３０３に対して送信される。

Ｓ５．１３で通信制御部３０３は機能呼び出し制御部３１０に、Ｓ５．４で選択された機能の実行要求を送信する。その際、Ｓ５．１０で取得したローカルユーザーＵＵＩＤを同時に送信する。今回は、サービスサーバー１０４がＭＱＴＴによるメッセージ通信を行うサーバーである場合を例に説明しているので、ｐｕｂｌｉｓｈメッセージとして実行要求が機能呼び出し制御部３１０に送信される。その際のトピックはデバイス識別情報である。また、Ｓ５．４で「印刷」機能を選択しているので、Ｓ５．１３で送信される実行要求は印刷機能を実現するための実行要求である。

Ｓ５．１４にて機能呼び出し制御部３１０は、ｐｕｂｌｉｓｈメッセージとして受信した実行要求を実行する。その際、Ｓ５．７で選択されたローカルユーザーＵＵＩＤから特定されるローカルユーザーとして機能が実行される。例えば、図９（ｃ）ではローカルユーザーＵＵＩＤ「ＡＡＡ１」が選択されているので、デバイス１０５が保有するユーザーテーブル（表２）より、ローカルユーザーＩＤ「ａｄｍｉｎ」として機能が実行される。Ｓ５．１５にて機能呼び出し制御部３１０は、Ｓ５．１３で受信したローカルユーザーＵＵＩＤと紐づくクラウドユーザーＵＵＩＤの取得要求を認証サーバー連携部３０９に対して送信する。Ｓ５．１６で認証サーバー連携部３０９は、取得要求を受けたクラウドユーザーＵＵＩＤを応答する。Ｓ５．１７にて、機能呼び出し制御部３１０は通信制御部３０３に対して実行結果の応答を行う。その際、Ｓ５．１６で取得したクラウドユーザーＵＵＩＤも送信される。

Ｓ５．１８にて通信制御部３０３が印刷管理部３０５に実行結果の応答を行う。印刷管理部３０５は、Ｓ５．１７で受信したクラウドユーザーＵＵＩＤを用いることで、どのクラウドユーザーによる実行要求に対して結果が応答されたのかを特定することができる。また、印刷管理部３０５が認証部３０２から、クラウドユーザーＵＵＩＤと紐付くローカルユーザーＵＵＩＤを取得することで、どのローカルユーザーによる実行要求に対して結果が応答されたのかも特定することができる。実行結果とそれを実行した際に用いたローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤは、最終的には印刷管理部３０５または不図示のデータベースで管理される。その際、印刷管理部３０５において各実行結果に対し、セッションＩＤと、実行結果を一意に識別する識別子とが紐付いて管理されている。

以上が、デバイス１０５における機能呼び出し処理である。これにより、ユーザーはクライアントデバイス１０２を介して、デバイス１０５が公開している機能を実行可能なユーザーで利用することができ、その実行結果を確認することができる。

デバイス１０５の機能を実行した後、クライアントデバイス１０２のＷｅｂブラウザ３００は不図示の実行結果画面の要求をユーザーから受け付け、実行結果画面を表示することができる。その実行結果画面の例を図１０（ａ）に示す。図１０（ａ）には、デバイス名や各デバイスの機能を実行した日時、選択されたローカルユーザーＵＵＩＤが表示されている。「ユーザー選択」欄において「手動」と表示されているが、本実施例において「ユーザー選択」欄は設けられていなくてもよい。

また、その実行結果画面（図１０（ａ））を表示するための、結果取得処理のフローの一例を図１１に示す。本フローの起動は、ユーザーがデバイス１０５の機能の実行要求をしたときである。Ｓ６．１において、機能・ユーザー管理部３０６が実行結果画面を要求したクラウドユーザーのクラウドユーザーＵＵＩＤを認証部３０２から取得する。Ｓ６．２で機能・ユーザー管理部３０６は、Ｓ５．８で取得したローカルユーザーＵＵＩＤとデバイス識別情報を用いて、デバイス１０５の実行結果に関する情報を格納する印刷管理部３０５または、不図示のデータベースから実行結果を取得する。以上が結果取得処理のフローである。これにより、デバイス１０５の機能がユーザーによって選択され、その機能を利用可能なローカルユーザーＵＵＩＤを表示することで、クラウドシステムを介して複数のローカルユーザーアカウントでデバイスの機能を実行するときの利便性を向上させることができる。

［実施例２］
実施例１では、Ｗｅｂブラウザ３００において利用可能な機能を表示し、その中から選択された機能が利用できるローカルユーザーＵＵＩＤをさらに表示する形態を説明した。実施例２では、Ｗｅｂブラウザ３００において利用可能なローカルユーザーＵＵＩＤを表示し、その中から選択されたローカルユーザーＵＵＩＤが実行可能な機能を選択する形態を説明する。実施例２における認証連携情報を発行する処理やユーザー紐付け処理については、実施例１の場合と同様なので説明は省略する。

実施例２における機能呼び出し処理を図１３で説明する。ただし、実施例１の場合（図８）と同様のステップについては同じ符番を振り、詳細な説明を省略する。Ｓ７．１において、Ｗｅｂブラウザ３００はユーザーの操作により利用可能なローカルユーザーＵＵＩＤの要求操作を受ける。Ｓ７．２においてＷｅｂブラウザ３００は、機能・ユーザー管理部３０６に対して利用可能なローカルユーザーＵＵＩＤの要求を送信する。

Ｓ７．３で機能・ユーザー管理部３０６は、利用可能なローカルユーザーＵＵＩＤをＷｅｂブラウザ３００に応答する。具体的には、機能・ユーザー管理部３０６においてセッションＩＤとクラウドユーザーＵＵＩＤとが紐付いている（Ｓ３．１４）ので、Ｓ７．２でＷｅｂブラウザ３００が機能・ユーザー管理部３０６にセッションＩＤを送信することで、表１２を用いてセッションＩＤと紐付くクラウドユーザーＵＵＩＤが特定される。さらにそのクラウドユーザーＵＵＩＤと紐付くローカルユーザーＵＵＩＤが表１２で特定され、特定されたローカルユーザーＵＵＩＤをＷｅｂブラウザ３００に送信する。その際、機能・ユーザー管理部３０６は表１２を参照して、Ｓ７．２で受信したセッションＩＤと紐付くローカルユーザーＵＵＩＤを応答する。Ｗｅｂブラウザ３００が、利用可能なローカルユーザーＵＵＩＤを表示したときの表示画面の一例を図１４（ａ）に示す。図１４（ａ）では、利用可能なローカルユーザーＵＵＩＤとして「ＡＡＡ１」と「ＡＡＡ２」が表示されている。Ｓ７．４において、Ｗｅｂブラウザ３００はユーザーからローカルユーザーＵＵＩＤの選択操作を受け付ける。Ｗｅｂブラウザ３００においてユーザーが選択した様子の一例を図１４（ｂ）に示す。今回は、「ＡＡＡ１」が選択されたものとする。

Ｓ７．５において、Ｗｅｂブラウザ３００は機能・ユーザー管理部３０６に利用可能な機能の要求を送信する。その際、Ｓ７．４で選択したローカルユーザーＵＵＩＤも同時に送信する。Ｓ７．６にて、機能・ユーザー管理部３０６はＷｅｂブラウザ３００に利用可能な機能を応答する。具体的には、機能・ユーザー管理部３０６が表１２を参照して、Ｓ７．５で受信したローカルユーザーＵＵＩＤとセッションＩＤとに基づき、受信したローカルユーザーＵＵＩＤとセッションＩＤとに紐付いている利用可能機能を応答する。Ｗｅｂブラウザ３００で利用可能な機能が表示されたときの例を図１４（ｂ）に示す。図１４（ｂ）では、ユーザーが選択することができる機能として「印刷」、「設定値変更」、「フォームアップデート」が表示されている。

Ｓ７．７において、Ｗｅｂブラウザ３００はユーザーから利用可能機能の選択操作を受け付ける。ユーザーがＷｅｂブラウザ３００において機能を選択したときの様子の一例を図１４（ｃ）に示す。図１４（ｃ）では、「印刷」機能が選択されている。

Ｓ７．７で利用可能な機能をユーザーが選択したことで、Ｗｅｂブラウザ３００から機能・ユーザー管理部３０６へ実行要求が送信される（Ｓ５．８）。送信された実行要求が機能・ユーザー管理部３０６から印刷管理部３０５に送信される（Ｓ５．９）。印刷管理部３０５は通信制御部３０３に対して実行要求を送信する（Ｓ５．１０）。通信制御部３０３はＳ５．１０で受信した実行要求を送信する（Ｓ５．１３）。Ｓ５．１３で受信した実行要求の内容に応じて、機能呼び出し制御部３１０は選択された機能を実行する（Ｓ５．１４）。選択された機能を実行した後、機能呼び出し制御部３１０は認証サーバー連携部３０９にクラウドユーザーＵＵＩＤの取得要求を送信する（Ｓ５．１５）。認証サーバー連携部３０９は取得要求を受けたクラウドユーザーＵＵＩＤを機能呼び出し制御部３１０に応答する（Ｓ５．１６）。機能呼び出し制御部３１０は通信制御部３０３に対して実行結果の応答を行う（Ｓ５．１７）。応答された実行結果を通信制御部３０３が印刷管理部３０５に送信する（Ｓ５．１８）。

以上が、実施例２における機能呼び出し処理である。これにより、ローカルユーザーＵＵＩＤがユーザーによって選択され、選択されたローカルユーザーＵＵＩＤが利用可能なデバイス１０５の機能を表示することで、クラウドシステムを介して複数のローカルユーザーアカウントでデバイスの機能を実行するときの利便性を向上させることができる。また、実施例１と実施例２とでは、デバイス１０５の機能の表示とローカルユーザーＵＵＩＤの表示の順番が異なるが、ユーザーの要望によって実施例１と実施例２を使い分けることができる。例えば、ユーザー自身が使いたいデバイス１０５の機能を優先して、その機能に対するローカルユーザーＵＵＩＤを選択したい場合は実施例１を用いる方が適切であり、ある特定のローカルユーザーＵＵＩＤが利用可能なデバイス１０５の機能のみをユーザーが使いたい場合は、実施例２を用いる方が適切である。

［実施例３］
実施例３では、Ｗｅｂブラウザ３００においてユーザーによって選択された機能に応じて、利用可能なローカルユーザーＵＵＩＤを自動で選択し、選択されたローカルユーザーＵＵＩＤを用いて機能を実行する形態を説明する。実施例３における認証連携情報を発行する処理やユーザー紐付け処理については、実施例１の場合と同様なので説明は省略する。

実施例３における機能呼び出し処理を図１５で説明する。ただし、実施例１の場合（図８）と同様のステップについては同じ符番を振り、詳細な説明を省略する。Ｗｅｂブラウザ３００はユーザーから利用可能な機能の要求操作を受け付け（Ｓ５．１）、機能・ユーザー管理部３０６に対して利用可能な機能を要求する（Ｓ５．２）。機能・ユーザー管理部３０６はＳ５．２において受信したセッションＩＤに基づいて、Ｗｅｂブラウザ３００に利用可能な機能を応答する（Ｓ５．３）。Ｗｅｂブラウザ３００が利用可能な機能を表示したときの表示画面の一例は図９（ａ）で示した通りである。Ｓ５．４でＷｅｂブラウザ３００はユーザーから機能選択操作を受け付ける。ユーザーは「印刷」機能を選択した様子の一例は図９（ａ）に示した通りである。Ｓ５．５で、Ｗｅｂブラウザ３００は機能・ユーザー管理部３０６に利用可能なローカルユーザーＵＵＩＤを要求する。

Ｓ８．１で機能・ユーザー管理部３０６において、優先順位によるローカルユーザーＵＵＩＤの選択が行われる。機能・ユーザー管理部３０６ではデバイス１０５の各機能に対して、デバイス１０５の機能を利用できるローカルユーザーＵＵＩＤの優先順位が定められている。その優先順位のデータの一例を表１４に示す。

Ｓ８．１では表１４に基づき、優先順位が上位のローカルユーザーＵＵＩＤが選択される。その優先順位とは、Ｓ５．４で選択された機能を優先的に利用できるローカルユーザーＵＵＩＤの順番のことである。優先順位の決め方は、ローカルユーザーＵＵＩＤと機能とが紐付けされた順番や、ａｄｍｉｎ権限を持つローカルユーザーを優先する等の決め方が考えられるがその方式は問わない。また、ローカルユーザーＵＵＩＤと優先順位が紐付いてさえいれば表１４の形態でなくてもよい。今回は、Ｓ５．４で「印刷」機能が選択されており、表１４より「印刷」機能を優先的に利用できるローカルユーザーＵＵＩＤは「ＡＡＡ１」であるため、Ｓ８．１においてはＡＡＡ１が選択される。

Ｓ８．２において、機能・ユーザー管理部３０６はＷｅｂブラウザ３００にローカルユーザーＵＵＩＤを応答する。その際のＷｅｂブラウザ３００の表示の一例を図１６（ａ）に示す。図１６（ａ）では、優先順位を考慮して選択したローカルユーザーＵＵＩＤ「ＡＡＡ１」が自動で選択されている。「ＡＡＡ１による機能実行」ボタンを押下することで、後述のＳ８．３が実行される。一方、「別のユーザーを選択」ボタンを押下すると、図８（実施例１）のＳ５．５が開始され、ユーザーが手動でローカルユーザーＵＵＩＤを選択できるようになる。その際に表示される画面は図９（ｂ）に示した通りである。Ｓ８．２においてＷｅｂブラウザ３００に表示される画面は、図１６（ａ）の形態に限定されない。図１６（ｂ）のように、自動でローカルユーザーＵＵＩＤ「ＡＡＡ１」が選択されているものの、「実行可能ユーザ」欄がプルダウンできるようになっており、図１６（ｂ）や（ｃ）のように手動でローカルユーザーＵＵＩＤを変更できる形態等も考えられる。

Ｓ８．３において、Ｗｅｂブラウザ３００はユーザーの操作により実行開始操作を受け付ける。これによりユーザーはローカルユーザーＵＵＩＤを選択することなく、Ｓ５．８の実行要求印刷要求のステップが開始される。

Ｗｅｂブラウザ３００から機能・ユーザー管理部３０６へ実行要求が送信される（Ｓ５．８）。実行要求が機能・ユーザー管理部３０６から印刷管理部３０５に送信される（Ｓ５．９）。印刷管理部３０５は通信制御部３０３に対して、実行要求を送信する（Ｓ５．１０）。通信制御部３０３が機能呼び出し制御部３１０に対して実行要求を送信する（Ｓ５．１３）。機能呼び出し制御部３１０は送信された実行要求を実行する（Ｓ５．１４）。機能呼び出し制御部３１０がクラウドユーザーＵＵＩＤの取得要求を認証サーバー連携部３０９に対して送信し（Ｓ５．１５）、認証サーバー連携部３０９は取得要求を受けたクラウドユーザーＵＵＩＤを応答する（Ｓ５．１６）。機能呼び出し制御部３１０はＳ５．１６で受信したクラウドユーザーＵＵＩＤとともに通信制御部３０３に実行結果を送信する（Ｓ５．１７）。通信制御部３０３は印刷管理部３０５に実行結果を送信する（Ｓ５．１８）。

以上が、実施例３における機能呼び出し処理である。これによりユーザーは、クライアントデバイス１０２を介して、デバイス１０５が公開している機能を実行可能なユーザーで利用することができ、その実行結果を確認することができる。さらに、利用可能なローカルユーザーＵＵＩＤが自動で選択されるため、ユーザーは利用可能な機能を選択するだけで、その機能を実行することができる。また、実施例３で示したローカルユーザーＵＵＩＤの自動選択の方法は、上記で説明した実施例１と実施例２でローカルユーザーＵＵＩＤを選択する際に組み合わせることが可能である。

また、結果取得処理（図１１）や実行結果画面（図１０（ａ））は実施例１と同様のステップで得られるので説明は省略する。実施例３の場合の実行結果画面の一例を、図１７に示す。実施例１のように手動でローカルユーザーＵＵＩＤを選択した場合は「ユーザ選択」欄が「手動」と表示され、実施例３のように自動でローカルユーザーＵＵＩＤを選択した場合は「ユーザ選択」欄が「自動」と表示される。ローカルユーザーＵＵＩＤの選択を自動で行うか手動で行うかは、初期設定画面や初期設定ファイル等で予め設定してもよい。

［実施例４］
デバイス１０５の機能の実行結果が失敗したときや、失敗でなくても再度同じ機能を実行したいときに、実行結果画面等の履歴からその機能を再実行する使用形態が考えられる。再実行とは、実行履歴から実行結果をユーザーが選択し、選択された実行結果と同じ設定条件（同じローカルユーザーＵＵＩＤとデバイス１０５の機能に関する情報）、または選択された実行結果と同じデバイス１０５の機能の情報を用いて、実行要求をサービスサーバー１０４に対して送信することである。

実施例４では、再実行する際の処理について図１８を用いて説明する。まず、実施例４における認証連携情報を発行する処理やユーザー紐付け処理については、実施例１の場合と同様なので、説明は省略する。

次に、再実行の際の機能呼び出し処理については図１８を用いて説明する。実行結果画面（図１０（ｂ））上の「再実行」ボタンを押下することで、図１８の処理が開始される。Ｓ９．１において、ユーザーの操作によりＷｅｂブラウザ３００が再実行の要求操作を受け付ける。Ｓ９．２において、Ｗｅｂブラウザ３００が機能・ユーザー管理部３０６に対して利用可能なローカルユーザーＵＵＩＤを要求する。その際、ユーザーがＳ９．１において再実行を選択した実行結果を一意に識別する識別子も送信される。実行結果を一意に識別する識別子（以下、実行結果の識別子）は、印刷管理部３０５において実行結果を保存する際に各実行結果に対して発行される識別子である。図１１のＳ６．２において実行結果を取得する際に、実行結果画面（図１０、図１７）に表示される実行結果の識別子が特定され、実行結果画面とともに実行結果の識別子がＷｅｂブラウザ３００に送信される。その際にＷｅｂブラウザ３００が受信した実行結果の識別子をＳ９．２において機能・ユーザー管理部３０６に送信する。

Ｓ９．３において、機能・ユーザー管理部３０６は印刷管理部３０５に対してＳ９．２で受信したセッションＩＤと実行結果の識別子とともに、利用可能なローカルユーザーＵＵＩＤを要求する。Ｓ９．４において、印刷管理部３０５は機能・ユーザー管理部３０６に対して、利用可能なローカルユーザーＵＵＩＤを応答する。その際、Ｓ９．３で受信したセッションＩＤと実行結果の識別子とに紐付くローカルユーザーＵＵＩＤを機能・ユーザー管理部３０６に送信する。

Ｓ９．５において、機能・ユーザー管理部３０６はＳ９．４で受信した利用可能なローカルユーザーＵＵＩＤをＷｅｂブラウザ３００に応答する。その結果、得られるＷｅｂブラウザ３００の表示の一例は図９（ｂ）に示した通りである。図９（ｂ）において、ローカルユーザーＵＵＩＤを選択すると、後述のＳ５．８のステップが開始される。ユーザーがローカルユーザーＵＵＩＤを選択した結果、得られるＷｅｂブラウザ３００の表示の一例を図９（ｃ）に示す。今回は、ローカルユーザーＵＵＩＤ「ＡＡＡ１」を用いて、「印刷」機能を再実行することが選択されている。

Ｗｅｂブラウザ３００はユーザーからローカルユーザー選択操作を受け付ける（Ｓ５．７）。Ｓ５．７で選択されたローカルユーザーＵＵＩＤとＳ９．１で選択された機能の実行要求とがＷｅｂブラウザ３００から機能・ユーザー管理部３０６へと送信される（Ｓ５．８）。今回は、図１０（ｂ）より「印刷」機能を実行するための実行要求が送信される。ローカルユーザーＵＵＩＤとデバイス識別情報と実行要求とが機能・ユーザー管理部３０６から印刷管理部３０５に送信される（Ｓ５．９）。印刷管理部３０５は通信制御部３０３に対して、Ｓ５．９で受信したローカルユーザーＵＵＩＤとデバイス識別情報と実行要求とを送信する（Ｓ５．１０）。通信制御部３０３は機能呼び出し制御部３１０に対して、ローカルユーザーＵＵＩＤとともに実行要求を送信する（Ｓ５．１３）。その際に送信される実行要求はｐｕｂｌｉｓｈメッセージとして機能呼び出し制御部３１０に送信される。機能呼び出し制御部３１０は、Ｓ５．１３で受信したｐｕｂｌｉｓｈメッセージの内容に応じて機能を実行する（Ｓ５．１４）。その際、Ｓ５．７で選択されたローカルユーザーＵＵＩＤから特定されるローカルユーザーとして機能が実行される。具体的には、図９（ｃ）ではローカルユーザーＵＵＩＤ「ＡＡＡ１」が選択されているので、デバイス１０５が保有するユーザーテーブル（表２）より、ローカルユーザーＩＤ「ａｄｍｉｎ」として印刷機能が実行される。

機能呼び出し制御部３１０は、Ｓ５．１３で受信したローカルユーザーＵＵＩＤと紐づくクラウドユーザーＵＵＩＤの取得要求を認証サーバー連携部３０９に対して送信する（Ｓ５．１５）。認証サーバー連携部３０９は取得要求を受けたクラウドユーザーＵＵＩＤを応答する（Ｓ５．１６）。機能呼び出し制御部３１０は通信制御部３０３に対して、Ｓ５．１６で受信したクラウドユーザーＵＵＩＤとともに実行結果を応答する（Ｓ５．１７）。通信制御部３０３は印刷管理部３０５に実行結果の応答を行う（Ｓ５．１８）。

以上が、実行結果画面の履歴よりその機能を再実行する処理である。これにより、使いたい機能を選び直さなくても、実行結果画面の履歴から再度同じ機能を選択できる。また、今回は図１０（ｂ）を用いて、「印刷」機能が「正常終了」している状態から「再実行」を選択し、ローカルユーザーＵＵＩＤを選択する形態を説明したが、その形態に限らない。例えば図１９（ｂ）のように、「印刷」機能が「エラー終了」している状態から、「再実行」を押下し、再度同じ機能を実行する形態も考えられる。

「印刷」機能が「エラー終了」の状態に関しては、図１９（ｂ）のように「詳細表示」を押下してから、図１９（ｃ）のように再実行する形態も考えられる。その場合の処理について、図２０を用いて説明する。図２０は、図１８の過程の前に後述のＳ１０．１〜Ｓ１０．３が追加したものである。図１８と重複するＳ９．１以降の説明は省略する。

Ｓ１０．１において、ユーザーの操作によりＷｅｂブラウザ３００は詳細表示の要求操作を受け付ける。その際のＷｅｂブラウザ３００の表示の一例を図１９（ｂ）に示す。Ｓ１０．１でユーザーは図１９（ｂ）の「詳細表示」ボタンを押下したものとする。Ｓ１０．２において、Ｗｅｂブラウザ３００は機能・ユーザー管理部３０６に対して詳細表示を要求する。その際、ユーザーがＳ１０．１において詳細表示を選択した実行結果を一意に識別する識別子も送信される。Ｓ１０．３において、機能・ユーザー管理部３０６は印刷管理部３０５に対してＳ１０．２で受信したセッションＩＤと実行結果の識別子とともに、詳細表示の要求を送信する。Ｓ１０．４において印刷管理部３０５は機能・ユーザー管理部３０６に対して受信したセッションＩＤと実行結果の識別子とに紐付く実行結果の詳細表示を応答する。Ｓ１０．５において、機能・ユーザー管理部３０６はＷｅｂブラウザ３００に対して詳細表示を応答する。その際の詳細表示画面の一例を図１９（ｃ）に示す。今回のエラーの原因は「紙ジャムによる印刷停止」であることがわかる。ユーザーが図１９（ｃ）で「再実行」を押下すると、Ｓ９．１以降の処理が開始される。

上記では、「再実行」を選択しローカルユーザーＵＵＩＤを選択する形態を説明したがその形態に限らない。例えば、図１９（ｂ）において「再実行」を選択した結果、図９（ｃ）の表示画面になり、利用可能な機能やローカルユーザーＵＵＩＤを再度選択しなくてもよい形態等も考えられる。その場合、Ｓ９．１においてＷｅｂブラウザ３００が機能・ユーザー管理部３０６に実行結果の識別子を送信した結果、ユーザーが再実行を選択した実行結果に基づくローカルユーザーＵＵＩＤと利用可能な機能が表示（図９（ｃ））され、Ｓ５．８で実行要求が機能・ユーザー管理部３０６に送信される。

以上が、印刷機能が「エラー終了」状態のときのエラーの詳細を表示するステップから、再実行するステップまでの過程である。これにより、エラーの内容を確認することができ、さらに同じ機能に関する情報、同じローカルユーザーＵＵＩＤを用いて再実行することができる。

［実施例５］
デバイス１０５が保有するローカルユーザーＵＵＩＤと認証サーバー１０３で保有するクラウドユーザーＵＵＩＤが漏洩することで、ユーザーのなりすましが行われる可能性がある。そのため、ユーザー紐付け処理において共通鍵を発行し機能呼び出し処理において署名情報を付与することで、デバイス１０５への実行要求の改竄を検知することができる。実行要求の改竄で例えば、デバイス１０５への実行要求が「印刷機能を実行する」ための実行要求だとすると、この実行要求が改竄されて「設定を変更する」など、ユーザーが意図していない実行要求がデバイス１０５で実行されてしまう。実施例５では、共通鍵を利用した場合のユーザー紐付け処理と機能呼び出し処理について説明する。実施例１のユーザー紐付け処理（図６、図７）と、機能呼び出し処理（図８）とで同様のステップについては詳細な説明は省略する。

まず、共通鍵を用いた場合の、認証サーバー１０３におけるローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとのユーザー紐付け処理について図６を用いて説明する。Ｓ３．１１を後述のＳ１１．１、Ｓ３．１２を後述のＳ１１．２に置き換えることで、共通鍵を用いた場合の認証サーバー１０３におけるユーザー紐付け処理が実現する。Ｓ３．６〜Ｓ３．１０において、ユーザーによってＷｅｂブラウザ３００に入力された認証連携情報とともに認証連携情報を用いた紐付け処理の要求を認証部３０２に対して送信する。Ｓ１１．１において、認証部３０２においてクラウドユーザーＵＵＩＤと認証連携情報との紐付け処理を行い、その紐付け情報に対して共通鍵を発行する。発行した共通鍵の一例を表１５に示す。

Ｓ１１．２において認証部３０２は、Ｓ２．１０で作成したマッピングテーブル（表４）と、Ｓ１１．１で作成したマッピングテーブル（表１５）を一つにまとめ、クラウドユーザーＵＵＩＤとローカルユーザーＵＵＩＤとデバイス識別情報と共通鍵とを紐付ける。その際に生成される紐付け情報の例を表１６に示す。具体的には、表４と表１５では認証連携情報が共通しているので、それを介して表１６の紐付け情報を作成する。

認証サーバー１０３において、複数のローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤと共通鍵とを紐付けるためには、図６のシーケンスを繰り返す必要がある。シーケンスを繰り返した結果、機能・ユーザー管理部３０６において生成されるマッピングの例を表１７に示す。

以上が、共通鍵を用いた場合の、認証部３０２におけるローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとのユーザー紐付け処理である。これにより認証部３０２は、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとが紐づいた共通鍵を保持できる。

次に、共通鍵を用いた場合の、デバイス１０５におけるローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとのユーザー紐付け処理について図２１を用いて説明する。Ｓ１２．１において、認証サーバー１０３は通信制御部３０３に対して、認証連携情報とクラウドユーザーＵＵＩＤと共通鍵の紐付け依頼を送信する。具体的には、認証部３０２がＳ３．９において入力された認証連携情報とＳ１１．１において発行された共通鍵ともに通信制御部３０３に対してｐｕｂｌｉｓｈメッセージを送信する。ｐｕｂｌｉｓｈメッセージを送信する際のトピックはデバイス識別情報とする。これにより、Ｓ２．１５において機能呼び出し制御部３１０が送信したｓｕｂｓｃｒｉｂｅメッセージと同じトピックのｐｕｂｌｉｓｈメッセージを送信することができる。この際に認証部３０２が送るメッセージは、通信制御部３０３がＭＱＴＴと他のプロトコルとの変換機能を備えていれば、ＭＱＴＴのｐｕｂｌｉｓｈメッセージでなくても構わない。

Ｓ１２．２において通信制御部３０３は機能呼び出し制御部３１０に対して、クラウドユーザーＵＵＩＤの紐付け依頼としてｐｕｂｌｉｓｈメッセージを送る。そのメッセージとともに、クラウドユーザーＵＵＩＤと認証連携情報と共通鍵が送信される。Ｓ１２．３にて、機能呼び出し制御部３１０が認証サーバー連携部３０９に対して、クラウドユーザーＵＵＩＤの紐付け要求を送信する。その際、Ｓ１２．２で受信した認証連携情報とクラウドユーザーＵＵＩＤ、共通鍵も同時に通知する。Ｓ１２．４では、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤと共通鍵とを紐付ける紐付け処理を行う。認証サーバー連携部３０９は、Ｓ２．１２で生成されたローカルユーザーＵＵＩＤと認証連携情報とを紐付けた紐付け情報と、Ｓ１２．３で受信したクラウドユーザーＵＵＩＤと認証連携情報と共通鍵とを用いて、紐付け処理を行う。

以上が、共通鍵を用いた場合の、デバイス１０５におけるローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとのユーザー紐付け処理である。これにより認証サーバー連携部３０９は、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤと紐づいた共通鍵を保持できる。上記した内容では、対称鍵暗号の共通鍵基盤を前提として鍵交換を行った。しかしこれに限定されることはなく、例えば非対称鍵暗号の公開鍵基盤を用いても良い。その場合、Ｓ１１．１において、認証部３０２で非対称鍵ペア（公開鍵、秘密鍵）を発行し、Ｓ１２．２において公開鍵を機能呼び出し制御部３１０に送信する。その後、認証サーバー連携部３０９で非対称鍵ペアを発行し、その公開鍵を認証部３０２に送信することが考えられる。デバイス１０５が鍵発行機能を備えていない場合は、認証部３０２が代行して非対称鍵ペアを２ペア発行しても良い。また、本願発明では、対象鍵暗号と非対象鍵暗号を暗号鍵と表現している。

次に、共通鍵を用いた場合の機能呼び出し処理を、図２２を用いて説明する。図８と同じステップには同じ符番をふり、詳細な説明は省略する。

ユーザーの操作によりＷｅｂブラウザ３００は利用可能な機能の要求操作を受け付け（Ｓ５．１）、通信制御部３０３に対して利用可能な機能を要求する（Ｓ５．２）。機能・ユーザー管理部３０６はＷｅｂブラウザ３００に利用可能な機能を応答する（Ｓ５．３）。ユーザーの操作によりＷｅｂブラウザ３００が機能選択操作を受け付ける（Ｓ５．４）。Ｗｅｂブラウザ３００は利用可能なローカルユーザーＵＵＩＤの要求を機能・ユーザー管理部３０６に対して送信する（Ｓ５．５）。機能・ユーザー管理部３０６がＳ５．５で受信したセッションＩＤと機能・ユーザー管理部３０６で管理している紐付け情報（表１２）に基づいて、Ｗｅｂブラウザ３００にログインしているクラウドユーザーが利用可能なローカルユーザーＵＵＩＤを応答する（Ｓ５．６）。Ｗｅｂブラウザ３００がユーザーからローカルユーザー選択操作を受け付ける（Ｓ５．７）。Ｓ５．７で選択されたローカルユーザーＵＵＩＤと、Ｓ５．４で選択されたデバイス１０５の機能を実行するための実行要求とがＷｅｂブラウザ３００から機能・ユーザー管理部３０６へと送信される（Ｓ５．８）。機能・ユーザー管理部３０６は、Ｓ５．８で受信したローカルユーザーＵＵＩＤとデバイス識別情報と実行要求とを印刷管理部３０５に送信する（Ｓ５．９）。印刷管理部３０５は通信制御部３０３に対して、Ｓ５．９で受信したローカルユーザーＵＵＩＤとデバイス識別情報と実行要求とを送信する（Ｓ５．１０）。

Ｓ１３．１において、通信制御部３０３は認証部３０２に対して共通鍵の取得要求を行う。その際、ローカルユーザーＵＵＩＤとデバイス識別情報とを認証部３０２に送信する。Ｓ１１．２でローカルユーザーＵＵＩＤと認証連携情報との紐付け情報に対して共通鍵が発行されているので、Ｓ１３．１でローカルユーザーＵＵＩＤを送信することで、認証部３０２は要求されている共通鍵を特定することができる。Ｓ１３．２で認証部３０２は通信制御部３０３に対して共通鍵の取得応答を行う。通信制御部３０３が共通鍵を取得することで、サービスサーバー１０４において共通鍵とローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとが紐付く。

Ｓ１３．３において、通信制御部３０３は共通鍵を用いて実行要求に対して署名情報を付与する。送信されるリクエストはＪＷＴ（ＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ）形式の文字列として生成され、更にＪＷＳ（ＪＳＯＮ Ｗｅｂ Ｓｉｇｎａｔｕｒｅ）で定義される署名情報が付与される。署名情報の形式は、必ずしもＪＷＴ、ＪＷＡに限定されるわけではない。後述の署名情報についても同様である。

Ｓ１３．４において、通信制御部３０３は機能呼び出し制御部３１０に対して、Ｓ５．１０で取得したローカルユーザーＵＵＩＤとＳ１３．３で署名情報を付与した実行要求をｐｕｂｌｉｓｈメッセージとして送信する。その際のトピックはデバイス識別情報である。これにより、Ｓ２．１５で機能呼び出し制御部３１０が送信したｓｕｂｓｃｒｉｂｅメッセージと同じトピックのｐｕｂｌｉｓｈメッセージを送信することができる。Ｓ５．４において、ユーザーが「印刷」機能を選択したとすると、Ｓ１３．４では、印刷機能を実行するための実行要求が機能呼び出し制御部３１０に送信される。Ｓ１３．５において、機能呼び出し制御部３１０は認証サーバー連携部３０９に対してクラウドユーザーＵＵＩＤと共通鍵の取得要求を行う。

Ｓ１３．６において、認証サーバー連携部３０９は機能呼び出し制御部３１０に対してクラウドユーザーＵＵＩＤと共通鍵を応答する。認証サーバー連携部３０９においてローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤと共通鍵とが紐付いている（Ｓ１２．４）ので、認証サーバー連携部３０９は機能呼び出し制御部３１０に応答すべきクラウドユーザーＵＵＩＤと共通鍵を特定することができる。

Ｓ１３．７において、機能呼び出し制御部３１０はＳ１３．６で受信した共通鍵を用いて、実行要求に付与された署名情報を検証する。検証後、Ｓ１３．４で受信したｐｕｂｌｉｓｈメッセージの内容に応じて、印刷機能を実行する。Ｓ１３．８において、機能呼び出し制御部３１０は実行結果に署名情報を付与し、通信制御部３０３に対して実行結果を応答する。Ｓ１３．９において、機能呼び出し制御部３１０はＳ１３．２で受信した共通鍵を用いて、実行結果に付与された署名情報を検証する。検証後、通信制御部３０３は印刷管理部３０５に対してクラウドユーザーＵＵＩＤと実行要求の実行結果を送信する（Ｓ５．１８）。以上が、共通鍵を用いた場合の機能呼び出し処理である。実施例５により、クライアントデバイス１０２を介してデバイス１０５が公開している機能を利用でき、さらにデバイス１０５への実行要求の改竄検知を行うことができる。

［実施例６］
実施例１では、ユーザーがデバイス１０５において認証連携情報を取得し、取得した認証連携情報をクライアントデバイス１０２に入力し、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤを紐付けた。実施例６では、クライアントデバイス１０２で認証連携情報を取得し、取得した認証連携情報をデバイス１０５に入力し、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付ける形態を説明する。

まず、クライアントデバイス１０２における認証連携情報の発行処理を、図２３を用いて説明する。ただし、以前に生成したクラウドユーザー認証情報が有効であるものとして、Ｓ３．１〜Ｓ３．５の説明は省略する。Ｓ１４．１において、Ｗｅｂブラウザ３００はユーザーの操作により認証連携情報の発行要求を受け付ける。Ｓ１４．２において、Ｗｅｂブラウザ３００は認証部３０２に対して認証連携情報の発行要求を行う。Ｓ１４．３において、受信した発行要求に応じて認証部３０２は認証連携情報を発行する。Ｓ１４．４において、Ｓ１４．３で発行した認証部３０２はＳ１４．３で発行した認証連携情報とクラウドユーザーＵＵＩＤとを紐付けた紐付け情報を管理する。具体的には、Ｓ１４．２において認証部３０２は認証連携情報の発行要求とともにセッションＩＤを受信するため、そのセッションＩＤを介してＳ１４．３において発行された認証連携情報とクラウドユーザーＵＵＩＤとが紐付く。その際に生成される紐付け情報の一例を表１８に示す。

Ｓ１４．５で認証部３０２はＷｅｂブラウザ３００に対して、自身が発行した認証連携情報を応答し、ユーザーは認証連携情報を入手することができる。以上が、クライアントデバイス１０２における認証連携情報の発行処理である。Ｓ１４．１からＳ１４．５のシーケンスを繰り返すことで、一つのクラウドユーザーＵＵＩＤに対して複数の認証連携情報が発行される。シーケンスを２回繰り返した場合に生成される紐付け情報の例を表１９に示す。

次に図２４を用いて、デバイス１０５においてローカルユーザーＵＵＩＤと認証連携情報とを紐付けるユーザー紐付け処理を説明する。ただし、既に説明した過程と同じものについては説明を省略する。Ｓ１５．１において、Ｗｅｂブラウザ３０７は認証連携情報の入力操作をユーザーから受け付け、Ｓ１５．２で認証サーバー連携部３０９に対して認証連携情報の紐付け処理を要求する。具体的に、ユーザーの操作によってＷｅｂブラウザ３０７は認証連携情報「ＸＸＸ−ＹＹＹ−ＺＺＺ」を受信したとする。Ｓ２．６とＳ２．７において、認証サーバー連携部３０９はローカルログイン部３０８からローカルユーザーＵＵＩＤを取得する。Ｓ１５．３において、認証サーバー連携部３０９はＳ１５．１で受信した認証連携情報と、Ｓ２．７で受信したローカルユーザーＵＵＩＤとを紐付ける。その際に生成される紐付け情報の一例を表２０に示す。

以上が、デバイス１０５におけるローカルユーザーＵＵＩＤと認証連携情報とを紐付けるユーザー紐付け処理である。図２４のシーケンスを繰り返すことで、ローカルユーザーＵＵＩＤと認証連携情報とが紐づいた紐付け情報をデバイス１０５で複数管理することができる。図２４のシーケンスを２回繰り返した場合に生成される紐付け情報の例を表２１に示す。

次に、認証サーバー１０３とデバイス１０５におけるローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付けるユーザー紐付け処理について図２５で説明する。Ｓ１６．１において、認証サーバー連携部３０９は認証部３０２に対して認証連携情報とローカルユーザーＵＵＩＤとデバイス識別情報とを同時に送り、認証連携情報の紐付け要求を行う。具体的に送信される認証連携情報は「ＸＸＸ−ＹＹＹ−ＺＺＺ」、ローカルユーザーＵＵＩＤは「ＡＡＡ１」、デバイス識別情報は「０００１」であるものとする。Ｓ１６．２において、認証部３０２が受信した認証連携情報とローカルユーザーＵＵＩＤとデバイス識別情報とを用いて紐付け処理を実行する。その際に生成される紐付け情報の一例を表２２に示す。

Ｓ１６．３において、認証部３０２が管理する紐付け情報（表１８、表２２）を用いて、クラウドユーザーＵＵＩＤとローカルユーザーＵＵＩＤとデバイス識別情報とを紐付ける。その際にできるマッピングテーブルの例は表９に示した通りである。Ｓ１６．４にて、認証部３０２は認証サーバー連携部３０９に対して、クラウドユーザーＵＵＩＤと認証連携情報とを送信することで紐付け要求に対して応答する。具体的に、認証連携情報「ＸＸＸ−ＹＹＹ−ＺＺＺ」とクラウドユーザーＵＵＩＤ「ＣＣＣ１」を認証サーバー連携部３０９に送信したものとする。Ｓ１６．５において、認証サーバー連携部３０９はＳ１６．４で受信した認証連携情報とクラウドユーザーＵＵＩＤとを紐付ける。

Ｓ１６．６で認証サーバー連携部３０９は、Ｓ１６．５で紐付けた紐付け情報とＳ１５．３で紐付けた紐付け情報（表２０）とを用いて、クラウドユーザーＵＵＩＤとローカルユーザーＵＵＩＤとを紐付ける。この際にできる紐付け情報の例を表２３に示す。

Ｓ１６．７にて、Ｓ１５．２の紐付け処理の要求に対する応答として、認証サーバー連携部３０９はＷｅｂブラウザ３０７に紐付け処理の完了を応答する。これにより、ユーザーに紐付け処理が完了したことが通知される。以上が、認証サーバー１０３とデバイス１０５におけるローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとのユーザー紐付け処理である。Ｓ１６．１からＳ１６．６のシーケンスを繰り返すことで、一つのクラウドユーザーＵＵＩＤに対して複数のローカルユーザーＵＵＩＤの紐付け情報を生成することができる。シーケンスを２回繰り返したことで得られる紐付け情報の例を表２４に示す。

これにより、クライアントデバイス１０２で認証連携情報を取得し、取得した認証連携情報をデバイス１０５に入力することで、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとを紐付けることができる。ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤとのユーザー紐付け処理後の機能呼び出し処理は実施例１（図８）と同様なので省略する。

［他の実施例］
実施例４で説明した再実行を選択する処理については、実行結果をサービスサーバー１０４が選択した後の処理なので、実施例１〜実施例３との組み合わせが可能である。実施例５は、ローカルユーザーＵＵＩＤとクラウドユーザーＵＵＩＤと認証連携情報との紐付け情報に対して共通鍵を発行し、署名情報を共通鍵で検証する処理なので、実施例１〜４との組み合わせが可能である。実施例６は、認証連携情報の発行処理や紐付け情報の生成処理の別形態なので、機能呼び出し処理以降の処理と組み合わせが可能である。また、実施例２〜６に記載されていない部分は、実施例１に記載されていることと同じである。

上記の実施例で示したステップにおいて受送信される情報は、上記で例として示した情報のみならず、その情報を含みさえすればどのような情報を受送信しても良い。例えば、クラウドユーザーＩＤなどの他のクラウドユーザー認証情報とともにクラウドユーザーＵＵＩＤを送信する形態等も考えられる。ローカルユーザーＵＵＩＤの場合も同様である。

上記の実施例では、Ｗｅｂブラウザ３００が利用可能なローカルユーザーＵＵＩＤを表示する形態で説明した。しかし、ユーザーが、利用したいローカルユーザーを一意に特定できる情報であれば、Ｗｅｂブラウザ３００に表示される情報の形態は問わない。

また、上記の実施例では、一つのクラウドユーザーＵＵＩＤに対して複数のローカルユーザーＵＵＩＤが紐付く形態で説明したが、複数のクラウドユーザーＵＵＩＤと複数のローカルユーザーＵＵＩＤとが紐付く形態でも上記の実施例は成り立つ。

さらに、上記で説明した結果取得処理のフローは、図１０や図１１の形態に限らない。例えば、ユーザーは結果画面要求時にリクエストの選択を行わず、これまでの実行結果から最新の情報のみを閲覧するような形態等も考えられる。また、ユーザーの実行結果画面要求に応じて実行結果を取得するのではなく、Ｓ５．１８で印刷管理部３０５が実行結果を取得した際に実行結果画面を作成することも考えられる。

また、上記では図９のようにユーザーが機能を選択し、ローカルユーザーＵＵＩＤを選択してデバイス１０５の機能を実行する形態を説明した。その形態のみならず、クラウドユーザーが直近で選択したローカルユーザーＵＵＩＤとそれにより実行した機能を、ユーザーの選択を経ずにＷｅｂブラウザ３００が最初から表示（図９（ｃ））するデフォルトの形態も考えられる。図９（ｃ）のようにデフォルトによる設定が表示されていても、図１２のように、利用するローカルユーザーＵＵＩＤや機能を設定変更することも可能である。また、デフォルトの形態でＷｅｂブラウザ３００が表示する情報は、クラウドユーザーが直近で選択した情報のみならず、ユーザーが使いたいローカルユーザーＵＵＩＤとデバイス１０５の機能を予め設定し、その設定情報をクラウドユーザーＵＵＩＤと紐付けて管理する形態等が考えられる。

上記の実施例では、Ｗｅｂブラウザ３００の表示画面でローカルユーザーＵＵＩＤとデバイス１０５の機能を同じ画面上で表示している（図９、１２、１４、１６）が、ローカルユーザーＵＵＩＤと利用可能なデバイス１０５の機能をそれぞれ別の画面に表示する形態も考えられる。例えば、図９（ｂ）において、「機能」と「実行可能ユーザ」を同じ画面に表示している。しかし、それ以外の形態で例えば、ユーザーがＷｅｂブラウザ３００で「機能」を選択すると、別の画面に切り替わって「実行可能ユーザ」だけが表示され、ユーザーがその中から「実行可能ユーザ」を選択する形態も可能である。

本発明の目的は、以下の処理を実行することによっても達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

上述した各実施例によれば、クライアントデバイス１０２からクラウドシステム１０６経由でデバイス１０５の機能を実行する際に、クラウドユーザーＵＵＩＤと紐づくローカルユーザーＵＵＩＤを用いて実行することができる。さらには、クラウドシステム１０６及びデバイス１０５間の非同期処理において、リクエストとレスポンスを紐付けるための識別子を用いること無く、クラウドユーザーに対してデバイス１０５の機能の実行結果を通知することができる。

また以上、本発明の好ましい形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０２ クライアントデバイス
１０３ 認証サーバー
１０４ サービスサーバー
１０５ デバイス
３００ Ｗｅｂブラウザ
３０１ 通信部
３０２ 認証部
３０３ 通信制御部
３０４ 設定管理部
３０５ 印刷管理部
３０６ 機能・ユーザー管理部
３０７ Ｗｅｂブラウザ
３０９ 認証サーバー連携部
３１０ 機能呼び出し制御部

Claims (16)

1. クラウドシステムが、クラウドサービスを利用する複数のクラウドユーザーを一意に識別するためのクラウドユーザー認証情報と、デバイスの機能を利用する複数のローカルユーザーを一意に識別するためのローカルユーザー認証情報と、前記ローカルユーザー認証情報を用いて実行可能な前記デバイスの機能に関する情報とを紐付けて管理するクラウド管理手段と、
   前記デバイスが、前記クラウドユーザー認証情報と前記ローカルユーザー認証情報とを紐付けて管理するデバイス管理手段と、
   を有する情報処理システムであって、
   前記クラウド管理手段によって管理されている前記デバイスの機能に関する情報をクライアントデバイスに第一表示させ、第一表示された前記クライアントデバイスにおいて選択された前記デバイスの機能に関する情報と前記クラウド管理手段によって紐付いて管理されている前記ローカルユーザー認証情報を、前記クライアントデバイスに第二表示させる表示作成手段と、
   第二表示された前記クライアントデバイスにおいて選択された前記ローカルユーザー認証情報を用いて、第一表示された前記クライアントデバイスにおいて選択された前記デバイスの機能の選択を受け付ける選択受付手段と、
   前記クラウドシステムが、前記クライアントデバイスからユーザー認証情報を受信して前記クラウドユーザーを認証した後に、前記クラウドユーザー認証情報に対して前記クラウド管理手段によって紐付けて管理されているローカルユーザー認証情報と、前記選択受付手段によって受付された選択に対応した前記デバイスの機能を実行するための実行要求とを前記デバイスに送信する実行要求送信手段と、
   前記デバイスが前記ローカルユーザー認証情報に基づいて、前記実行要求送信手段によって送信された実行要求を実行する実行手段と、
   前記クラウドシステムから前記実行要求とともに受信した前記ローカルユーザー認証情報に対して前記デバイス管理手段によって紐付けて管理されているクラウドユーザー認証情報と、前記実行手段によって実行された実行結果とを前記デバイスが前記クラウドシステムに送信する実行結果送信手段と、
   を有する情報処理システム。
2. クラウドシステムが、クラウドサービスを利用する複数のクラウドユーザーを一意に識別するためのクラウドユーザー認証情報と、デバイスの機能を利用する複数のローカルユーザーを一意に識別するためのローカルユーザー認証情報と、前記ローカルユーザー認証情報を用いて実行可能な前記デバイスの機能に関する情報とを紐付けて管理するクラウド管理手段と、
   前記デバイスが、前記クラウドユーザー認証情報と前記ローカルユーザー認証情報とを紐付けて管理するデバイス管理手段と、
   を有する情報処理システムであって、
   前記クラウド管理手段によって管理されているローカルユーザー認証情報をクライアントデバイスに第一表示させ、第一表示された前記クライアントデバイスにおいて選択された前記ローカルユーザー認証情報と前記クラウド管理手段によって紐付いて管理されている前記デバイスの機能に関する情報を、前記クライアントデバイスに第二表示させる表示作成手段と、
   第二表示された前記クライアントデバイスにおいて選択された前記デバイスの機能の選択を受け付ける選択受付手段と、
   前記クラウドシステムが、前記クライアントデバイスからユーザー認証情報を受信して前記クラウドユーザーを認証した後に、前記クラウドユーザー認証情報に対して前記クラウド管理手段によって紐付けて管理されているローカルユーザー認証情報と、前記選択受付手段によって受付された選択に対応した前記デバイスの機能を実行するための実行要求とを前記デバイスに送信する実行要求送信手段と、
   前記デバイスが前記ローカルユーザー認証情報に基づいて、前記実行要求送信手段によって送信された実行要求を実行する実行手段と、
   前記クラウドシステムから前記実行要求とともに受信した前記ローカルユーザー認証情報に対して前記デバイス管理手段によって紐付けて管理されているクラウドユーザー認証情報と、前記実行手段によって実行された実行結果とを前記デバイスが前記クラウドシステムに送信する実行結果送信手段と、
   を有する情報処理システム。
3. 前記クラウド管理手段は、
   第一表示された前記クライアントデバイスにおいて選択された前記デバイスの機能と、前記クラウド管理手段において管理されている前記ローカルユーザー認証情報の優先順位とに基づいて、前記クライアントデバイスにおいて第二表示する前記ローカルユーザー認証情報が選択されることを特徴とする請求項１に記載の情報処理システム。
4. 前記ローカルユーザー認証情報の優先順位は、
   前記デバイスの機能を優先的に利用できる前記ローカルユーザー認証情報の優先順位であることを特徴とする請求項３に記載の情報処理システム。
5. 前記クラウドユーザー認証情報は、
   前記クラウドユーザーを一意に識別し、他のクラウドユーザー認証情報と重複することのないクラウドユーザーＵＵＩＤであり、
   前記ローカルユーザー認証情報は、
   前記ローカルユーザーを一意に識別し、他のローカルユーザー認証情報と重複することのないローカルユーザーＵＵＩＤであることを特徴とする請求項１乃至請求項４のいずれか一つに記載の情報処理システム。
6. 前記クラウド管理手段は、
   前記クラウドユーザー認証情報と前記クラウドユーザー認証情報とを紐付けるための認証連携情報を介して前記クラウドユーザー認証情報と前記ローカルユーザー認証情報とを紐付けたクラウド紐付け情報を管理し、
   前記デバイス管理手段は、
   前記認証連携情報を介して前記クラウドユーザー認証情報と前記ローカルユーザー認証情報とを紐付けたデバイス紐付け情報を管理することを特徴とする請求項１乃至請求項５のいずれか一つに記載の情報処理システム。
7. 前記認証連携情報は、
   ユーザーが前記デバイスにログインし、前記認証連携情報を発行するための発行要求が前記クラウドシステムに送信されたことで、前記クラウドシステムが前記認証連携情報を発行することを特徴とする請求項６に記載の情報処理システム。
8. 前記認証連携情報は、
   前記ユーザーが前記クライアントデバイスにログインし、前記認証連携情報を発行するための発行要求が前記クラウドシステムに送信されたことで、前記クラウドシステムが前記認証連携情報を発行することを特徴とする請求項６に記載の情報処理システム。
9. 前記実行要求送信手段は、
   前記クラウド紐付け情報に対して紐付けられた暗号鍵を用いて、前記デバイスの機能を実行するための実行要求に署名情報を付与して前記デバイスに送信し、前記デバイスにおいて前記署名情報が検証されることを特徴とする請求項６乃至請求項８のいずれか一つに記載の情報処理システム。
10. 前記実行結果送信手段は、
    前記デバイス紐付け情報に対して紐付けられた暗号鍵を用いて、前記実行結果に前記署名情報を付与して前記クラウドシステムに送信し、前記クラウドシステムにおいて前記署名情報が検証されることを特徴とする請求項６乃至請求項９のいずれか一つに記載の情報処理システム。
11. 前記情報処理システムは、
    前記実行結果と、前記実行結果とともに受信したクラウドユーザー認証情報と、前記クラウド管理手段によって前記クラウドユーザー認証情報と紐付けて管理されているローカルユーザー認証情報とを管理する実行結果管理手段をさらに有し、
    前記実行要求送信手段は、
    前記クライアントデバイスが前記実行結果管理手段から前記実行結果を取得して表示画面に表示し、前記表示画面におけるユーザーの選択に応じて前記実行手段によって実行された実行要求を再び前記デバイスに送信することを特徴とする請求項１乃至請求項１０のいずれか一つに記載の情報処理システム。
12. 前記表示画面は、
    前記実行手段によって実行された実行要求に基づき、再び前記デバイスに前記実行要求を送信することをユーザーが選択するための手段を含むことを特徴とする請求項１１に記載の情報処理システム。
13. クラウドシステムが、クラウドサービスを利用する複数のクラウドユーザーを一意に識別するためのクラウドユーザー認証情報と、デバイスの機能を利用する複数のローカルユーザーを一意に識別するためのローカルユーザー認証情報と、前記ローカルユーザー認証情報を用いて実行可能な前記デバイスの機能に関する情報とを紐付けて管理するクラウド管理ステップと、
    前記デバイスが、前記クラウドユーザー認証情報と前記ローカルユーザー認証情報とを紐付けて管理するデバイス管理ステップと、
    を有する制御方法であって、
    前記クラウド管理ステップによって管理されている前記デバイスの機能に関する情報をクライアントデバイスに第一表示させ、第一表示された前記クライアントデバイスにおいて選択された前記デバイスの機能に関する情報と前記クラウド管理ステップによって紐付いて管理されている前記ローカルユーザー認証情報を、前記クライアントデバイスに第二表示させる表示作成ステップと、
    第二表示された前記クライアントデバイスにおいて選択された前記ローカルユーザー認証情報を用いて、第一表示された前記クライアントデバイスにおいて選択された前記デバイスの機能の選択を受け付ける選択受付ステップと、
    前記クラウドシステムが、前記クライアントデバイスからユーザー認証情報を受信して前記クラウドユーザーを認証した後に、前記クラウドユーザー認証情報に対して前記クラウド管理ステップによって紐付けて管理されているローカルユーザー認証情報と、前記選択受付ステップによって受付された選択に対応した前記デバイスの機能を実行するための実行要求とを前記デバイスに送信する実行要求送信ステップと、
    前記デバイスが前記ローカルユーザー認証情報に基づいて、前記実行要求送信ステップによって送信された実行要求を実行する実行ステップと、
    前記クラウドシステムから前記実行要求とともに受信した前記ローカルユーザー認証情報に対して前記デバイス管理ステップによって紐付けて管理されているクラウドユーザー認証情報と、前記実行ステップによって実行された実行結果とを前記デバイスが前記クラウドシステムに送信する実行結果送信ステップと、
    を有する制御方法。
14. クラウドシステムが、クラウドサービスを利用する複数のクラウドユーザーを一意に識別するためのクラウドユーザー認証情報と、デバイスの機能を利用する複数のローカルユーザーを一意に識別するためのローカルユーザー認証情報と、前記ローカルユーザー認証情報を用いて実行可能な前記デバイスの機能に関する情報とを紐付けて管理するクラウド管理ステップと、
    前記デバイスが、前記クラウドユーザー認証情報と前記ローカルユーザー認証情報とを紐付けて管理するデバイス管理ステップと、
    を有する制御方法であって、
    前記クラウド管理ステップによって管理されているローカルユーザー認証情報をクライアントデバイスに第一表示させ、第一表示された前記クライアントデバイスにおいて選択された前記ローカルユーザー認証情報と前記クラウド管理ステップによって紐付いて管理されている前記デバイスの機能に関する情報を、前記クライアントデバイスに第二表示させる表示作成ステップと、
    第二表示された前記クライアントデバイスにおいて選択された前記デバイスの機能の選択を受け付ける選択受付ステップと、
    前記クラウドシステムが、前記クライアントデバイスからユーザー認証情報を受信して前記クラウドユーザーを認証した後に、前記クラウドユーザー認証情報に対して前記クラウド管理ステップによって紐付けて管理されているローカルユーザー認証情報と、前記選択受付ステップによって受付された選択に対応した前記デバイスの機能を実行するための実行要求とを前記デバイスに送信する実行要求送信ステップと、
    前記デバイスが前記ローカルユーザー認証情報に基づいて、前記実行要求送信ステップによって送信された実行要求を実行する実行ステップと、
    前記クラウドシステムから前記実行要求とともに受信した前記ローカルユーザー認証情報に対して前記デバイス管理ステップによって紐付けて管理されているクラウドユーザー認証情報と、前記実行ステップによって実行された実行結果とを前記デバイスが前記クラウドシステムに送信する実行結果送信ステップと、
    を有する制御方法。
15. クラウドシステムが、クラウドサービスを利用する複数のクラウドユーザーを一意に識別するためのクラウドユーザー認証情報と、デバイスの機能を利用する複数のローカルユーザーを一意に識別するためのローカルユーザー認証情報と、前記ローカルユーザー認証情報を用いて実行可能な前記デバイスの機能に関する情報とを紐付けて管理するクラウド管理ステップと、
    前記デバイスが、前記クラウドユーザー認証情報と前記ローカルユーザー認証情報とを紐付けて管理するデバイス管理ステップと、
    を有する制御方法を実現するためのプログラムであって、
    前記クラウド管理ステップによって管理されている前記デバイスの機能に関する情報をクライアントデバイスに第一表示させ、第一表示された前記クライアントデバイスにおいて選択された前記デバイスの機能に関する情報と前記クラウド管理ステップによって紐付いて管理されている前記ローカルユーザー認証情報を、前記クライアントデバイスに第二表示させる表示作成ステップと、
    第二表示された前記クライアントデバイスにおいて選択された前記ローカルユーザー認証情報を用いて、第一表示された前記クライアントデバイスにおいて選択された前記デバイスの機能の選択を受け付ける選択受付ステップと、
    前記クラウドシステムが、前記クライアントデバイスからユーザー認証情報を受信して前記クラウドユーザーを認証した後に、前記クラウドユーザー認証情報に対して前記クラウド管理ステップによって紐付けて管理されているローカルユーザー認証情報と、前記選択受付ステップによって受付された選択に対応した前記デバイスの機能を実行するための実行要求とを前記デバイスに送信する実行要求送信ステップと、
    前記デバイスが前記ローカルユーザー認証情報に基づいて、前記実行要求送信ステップによって送信された実行要求を実行する実行ステップと、
    前記クラウドシステムから前記実行要求とともに受信した前記ローカルユーザー認証情報に対して前記デバイス管理ステップによって紐付けて管理されているクラウドユーザー認証情報と、前記実行ステップによって実行された実行結果とを前記デバイスが前記クラウドシステムに送信する実行結果送信ステップと、
    を有する制御方法を実現するためのプログラム。
16. クラウドシステムが、クラウドサービスを利用する複数のクラウドユーザーを一意に識別するためのクラウドユーザー認証情報と、デバイスの機能を利用する複数のローカルユーザーを一意に識別するためのローカルユーザー認証情報と、前記ローカルユーザー認証情報を用いて実行可能な前記デバイスの機能に関する情報とを紐付けて管理するクラウド管理ステップと、
    前記デバイスが、前記クラウドユーザー認証情報と前記ローカルユーザー認証情報とを紐付けて管理するデバイス管理ステップと、
    を有する制御方法を実現するためのプログラムであって、
    前記クラウド管理ステップによって管理されているローカルユーザー認証情報をクライアントデバイスに第一表示させ、第一表示された前記クライアントデバイスにおいて選択された前記ローカルユーザー認証情報と前記クラウド管理ステップによって紐付いて管理されている前記デバイスの機能に関する情報を、前記クライアントデバイスに第二表示させる表示作成ステップと、
    第二表示された前記クライアントデバイスにおいて選択された前記デバイスの機能の選択を受け付ける選択受付ステップと、
    前記クラウドシステムが、前記クライアントデバイスからユーザー認証情報を受信して前記クラウドユーザーを認証した後に、前記クラウドユーザー認証情報に対して前記クラウド管理ステップによって紐付けて管理されているローカルユーザー認証情報と、前記選択受付ステップによって受付された選択に対応した前記デバイスの機能を実行するための実行要求とを前記デバイスに送信する実行要求送信ステップと、
    前記デバイスが前記ローカルユーザー認証情報に基づいて、前記実行要求送信ステップによって送信された実行要求を実行する実行ステップと、
    前記クラウドシステムから前記実行要求とともに受信した前記ローカルユーザー認証情報に対して前記デバイス管理ステップによって紐付けて管理されているクラウドユーザー認証情報と、前記実行ステップによって実行された実行結果とを前記デバイスが前記クラウドシステムに送信する実行結果送信ステップと、
    を有する制御方法を実現するためのプログラム。

Images