特開 2024-171748 情報処理装置及び接続判定方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024171748

(43)【公開日】2024-12-12

(54)【発明の名称】情報処理装置及び接続判定方法

(51)【国際特許分類】

   G06F 21/33 20130101AFI20241205BHJP

【ＦＩ】

G06F21/33

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2023088931

(22)【出願日】2023-05-30

(71)【出願人】

【識別番号】000005049

【氏名又は名称】シャープ株式会社

(74)【代理人】

【識別番号】100112335

【弁理士】

【氏名又は名称】藤本 英介

(74)【代理人】

【識別番号】100101144

【弁理士】

【氏名又は名称】神田 正義

(74)【代理人】

【識別番号】100101694

【弁理士】

【氏名又は名称】宮尾 明茂

(74)【代理人】

【識別番号】100124774

【弁理士】

【氏名又は名称】馬場 信幸

(72)【発明者】

【氏名】富田 央子

(57)【要約】

【課題】事前に認可が必要な認証方式であっても、ユーザが想定した接続情報を用い、サービス提供装置に対する接続の可否を判定することが可能な情報処理装置等を提供する。
【解決手段】接続情報の入力を受付ける入力部と、受付けた前記接続情報に基づきサービス提供装置に対する接続を制御する制御部とを備え、前記制御部は、前記サービス提供装置における認証方式が事前に認可を要する認証方式である場合、認可に伴う認証情報の取得状況に応じて、受付けた前記接続情報に基づく接続が可能か否かを判定する情報処理装置。
【選択図】図２

【特許請求の範囲】

【請求項1】

接続情報の入力を受付ける入力部と、
受付けた前記接続情報に基づきサービス提供装置に対する接続を制御する制御部とを備え、
前記制御部は、
前記サービス提供装置における認証方式が事前に認可を要する認証方式である場合、認可に伴う認証情報の取得状況に応じて、受付けた前記接続情報に基づく接続が可能か否かを判定することを特徴とする情報処理装置。

【請求項2】

接続に成功した前記接続情報を第１の接続情報として記憶する記憶部を備え、
前記制御部は、
前記認証情報が取得状態である場合、前記記憶部に記憶した前記第１の接続情報と受付けた前記接続情報とを比較することにより接続が可能か否かを判定することを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記制御部は、
前記第１の接続情報と受付けた前記接続情報とが一致する場合、接続が可能と判定し、前記第１の接続情報と受付けた前記接続情報とが不一致である場合、接続が不可能と判定することを特徴とする請求項２に記載の情報処理装置。

【請求項4】

前記制御部は、
前記認証情報が未取得である場合、接続が不可能と判定することを特徴とする請求項１に記載の情報処理装置。

【請求項5】

前記制御部は、
前記認証情報が未取得である場合、前記認証情報が未取得、取得処理中、又は無効である旨を報知することを特徴とする請求項１に記載の情報処理装置。

【請求項6】

前記制御部は、
前記認証情報が未取得である場合、前記接続情報の入力の受付けを制限することを特徴とする請求項１に記載の情報処理装置。

【請求項7】

前記制御部は、
前記認証方式が事前に認可を要しない認証方式である場合又は事前の認可が未認可である場合、受付けた前記接続情報を用いて接続が可能か否かを判定することを特徴とする請求項１に記載の情報処理装置。

【請求項8】

前記制御部は、
前記認証情報の取得状況をトークンの取得状態で判定することを特徴とする請求項１に記載の情報処理装置。

【請求項9】

接続情報の入力を受付け、
受付けた前記接続情報に基づきサービス提供装置に対する接続が可能か否かを判定する接続判定方法であって、
前記サービス提供装置における認証方式が事前に認可を要する認証方式である場合、認可に伴う認証情報の取得状況に応じて、受付けた前記接続情報に基づく接続が可能か否かを判定することを特徴とする接続判定方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、情報処理装置等に関する。

【背景技術】

【0002】

ＳＭＴＰ（Simple Mail Transfer Protocol）／ＰＯＰ（Post Office Protocol）認証の設定に関し、設定画面を介してユーザが入力したプロバイダ情報やアカウント等の接続情報を用いて実際にサービスプロバイダに接続が可能か否かを検証する接続テスト機能を備える情報処理装置が知られている（例えば、特許文献１参照）。

【0003】

ところで、ＳＭＴＰ／ＰＯＰ認証に係る認証方法として、昨今では、ユーザＩＤとパスワードとを用いた従来の認証方式よりもよりセキュアな認証方式であるＯＡｕｔｈ認証方式が主流となりつつある。ＯＡｕｔｈ認証を使用するためには、予めプロバイダに対して認可リクエストを行い、認可された状態となっている必要がある。したがって、ＯＡｕｔｈ認証では、従来のＳＭＴＰ／ＰＯＰ認証の際と同様に、接続テスト画面を介してユーザが想定した接続情報を入力するだけでは接続テストを実施することができない。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００４－１０２４２０号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

本開示は、事前に認可が必要な認証方式であっても、ユーザが想定した接続情報を用い、サービス提供装置に対する接続の可否を判定することが可能な情報処理装置等を提供することを目的とする。

【課題を解決するための手段】

【0006】

上記課題を解決するために、本開示に係る情報処理装置は、接続情報の入力を受付ける入力部と、受付けた前記接続情報に基づきサービス提供装置に対する接続を制御する制御部とを備え、前記制御部は、前記サービス提供装置における認証方式が事前に認可を要する認証方式である場合、認可に伴う認証情報の取得状況に応じて、受付けた前記接続情報に基づく接続が可能か否かを判定することを特徴としている。

【0007】

また、本開示に係る接続判定方法は、接続情報の入力を受付け、受付けた前記接続情報に基づきサービス提供装置に対する接続が可能か否かを判定する接続判定方法であって、前記サービス提供装置における認証方式が事前に認可を要する認証方式である場合、認可に伴う認証情報の取得状況に応じて、受付けた前記接続情報に基づく接続が可能か否かを判定することを特徴としている。

【発明の効果】

【0008】

本開示によれば、事前に認可が必要な認証方式であっても、ユーザが想定した接続情報を用い、サービス提供装置に対する接続の可否を判定することが可能な情報処理装置等を提供することができる。

【図面の簡単な説明】

【0009】

【図1】複合機とクラウドとの接続形態を説明する図である。

【図2】複合機の機能構成図である。

【図3】接続情報管理テーブルを説明する図である。

【図4】第１実施形態に係る処理の流れを説明するフローチャートである。

【図5】第１実施形態に係る処理の流れを説明するフローチャートである。

【図6】第１実施形態に係る動作例を説明する図である。

【図7】第１実施形態に係る動作例を説明する図である。

【図8】第１実施形態に係る動作例を説明する図である。

【図9】第１実施形態に係る動作例を説明する図である。

【図10】第１実施形態に係る動作例を説明する図である。

【図11】第１実施形態に係る動作例を説明する図である。

【図12】第１実施形態に係る動作例を説明する図である。

【図13】第２実施形態に係る動作例を説明する図である。

【図14】第２実施形態に係る動作例を説明する図である。

【図15】第２実施形態に係る動作例を説明する図である。

【図16】第２実施形態に係る動作例を説明する図である。

【図17】変形例を説明する図である。

【発明を実施するための形態】

【0010】

以下、本開示の実施形態について図面を参照して説明する。なお、以下の実施形態は、本開示を説明するための一例であり、特許請求の範囲に記載した説明の技術的内容は、以下の記載に限定されるものではない。

【0011】

ＳＭＴＰ／ＰＯＰ認証の設定の際、ユーザがテスト画面に入力した接続情報を用いてサービスプロバイダに実際に接続可能か否かをテストする機能（接続テスト）が知られている。ユーザは、接続テストの結果が成功であることを確認した上で、テスト画面に入力した接続情報を登録することができる。この目的から、接続テストは実施時にテスト画面に表示されている接続情報（ユーザが想定した設定値）で行うことが想定されていた。

【0012】

一方、ＯＡｕｔｈ認証では、予めサービスプロバイダに対して認可リクエストを行い、認可された状態となっている必要がある。したがって、ＯＡｕｔｈ認証では、従来のＳＭＴＰ／ＰＯＰ認証の際と同様に、接続テスト画面を介してユーザが想定した接続情報を入力するだけでは接続テストを実施することができない。ここで、ＯＡｕｔｈ認証において事前に認可済であれば、トークンを取得し、サービスプロバイダが提供するサービスが利用可能か否かを確認することができる。このとき、例えば、テスト画面で入力された接続情報が認可時に利用された接続情報と異なっていた場合でも、タイミングによっては、接続テスト自体が成功する場合がある。このような場合、ユーザがテスト画面で入力した接続情報を登録すると、接続テストに成功した接続情報と接続テスト後に登録した接続情報（テスト画面で入力した接続情報）との間で齟齬が生じるため、サービスプロバイダとの通信接続が失敗した場合に、ユーザが混乱することがあった。

【0013】

本開示では、ＯＡｕｔｈ認証といった事前に認可を要する認証方式においても、ユーザが想定した接続情報を用い、サービス提供装置に対する接続の可否を判定することが可能な情報処理装置等を以下の実施形態で実現する。

【0014】

［１ 第１実施形態］
［１．１ 全体構成］
図１は、第１実施形態に係る情報処理装置としての複合機１０と、サービス提供装置としてのクラウド３０との接続形態の一例を説明する図である。

【0015】

第１実施形態に係る複合機１０は、プリント、コピー、ファクス（インターネットＦＡＸ）、メール送信等を一つの筐体で実現可能な情報処理装置である。なお、第１実施形態では、情報処理装置の一形態として複合機１０について説明するが、ＯＡｕｔｈ認証に対応したアカウントを用いての認証処理の実行が可能な構成であれば特に制限は無く、コピー機、プリンタ、ファクス等の情報処理装置であってもかまわない。

【0016】

複合機１０は、ネットワークＮＷを介してクラウド３０に接続されている。複合機１０は、例えば、ＩＰ（Internet Protocol）、ＴＣＰ（Transmission Control Protocol）、ＨＴＴＰ（Hypertext Transfer Protocol）、ＳＭＴＰ等の通信プロトコルに基づき、クラウド３０との通信が可能となるように構成されている。なお、ネットワークＮＷは、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット等のネットワーク回線を表している。なお、ネットワークＮＷに接続される複合機１０の数は、図１の例示に限定されず、複数台数の複合機１０がネットワークＮＷに接続されてもよい。

【0017】

クラウド３０は、例えば、ＯＡｕｔｈ２．０認証方式に基づく認可コードフローを実行することでメール配信に係る利用認可を行う認可サーバ（不図示）を含むサービス提供装置である。クラウド３０は、認可処理・認証処理に応じて認可コード、認証情報としてのアクセストークン、リフレッシュトークン等を生成する構成であれば、装置構成に制限は無く、例えば、認可コードフローを処理する認可サーバと、メール配信サーバとを別体で構成してもよく、認可機能・認証機能とメール配信機能とを併せ持つ単体の装置で構成することも可能である。クラウド３０は、ＳＭＴＰプロトコルやＰＯＰプロトコルに準拠してメール配信を行うサービスプロバイダとして機能することができる。

【0018】

［１．２ 機能構成］
［１．２．１ 複合機１０について］
次に、第１実施形態に係る複合機１０の機能構成について図２を用いて説明する。複合機１０は、制御部１１と、入力部１３と、通信部１５と、画像処理部１７と、画像入力部１９と、記憶部２１とを備える。

【0019】

制御部１１は、複合機１０全体を制御する。制御部１１は、例えば、１又は複数の演算装置（ＣＰＵ（Central processing unit）等）により構成される。制御部１１は、記憶部２１に記憶された各種プログラムを読み出して実行することにより、その機能を実現する。

【0020】

入力部１３は、後述するテスト画面を介したユーザによる接続情報の入力を含む、ユーザ等により様々な情報の入力を受付ける入力部である。入力部１３は、表示部１３１と操作部１３２とを含めることができる。

【0021】

表示部１３１は、各種情報をユーザ等に対して表示する表示装置である。表示部１３１は、例えば、ＬＣＤ（Liquid crystal display）や有機ＥＬ（Electro-luminescence）ディスプレイ等により構成することができる。表示部１３１は、制御部１１による制御に基づき、後述するブラウザプログラム２１４によって生成された閲覧用の画面情報に基づく画面を表示する。

【0022】

操作部１３２は、ユーザ等による情報の入力を受付ける。操作部１３２は、例えば、ハードキーやソフトウェアキーといった操作キー、ボタン等の各種入力装置により構成することができる。

【0023】

なお、入力部１３は、表示部１３１と操作部１３２との機能を併せ持つタッチパネルとして構成することができる。この場合、タッチパネルは、表示するＷｅｂブラウザ画面やアプリケーション画面を介したＵＩ（User Interface）として機能することができる。なお、タッチパネルの入力方式としては、例えば、抵抗膜方式、赤外線方式、電磁誘導方式、静電容量方式といった一般的な方式を採用することができる。

【0024】

通信部１５は、例えば、ＬＡＮ、ＷＡＮ、インターネット、電話回線、ファクス回線等のネットワーク（ＮＷ）を介して他の装置（クラウド３０）と通信を行うための有線／無線の何れか又はその両方のインタフェースを備える。また、通信部１５は、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣ（Near field communication）、Ｗｉ－Ｆｉ（登録商標）、ＺｉｇＢｅｅ（登録商標）、Ｉｒｄａ、ワイヤレスＵＳＢ等の（近距離）無線通信技術に関するインタフェースを備えてもよい。

【0025】

画像処理部１７は、画像データに基づく画像を記録媒体としての用紙等に形成する画像形成部を含む。画像形成部は、不図示の給紙トレイから用紙を給紙し、用紙上に画像データに基づく画像を形成した後、不図示の排紙部に排紙する。画像形成部は、例えば、電子写真方式を利用したレーザプリンタ等により構成することができる。この場合、画像形成部は、トナー色（例えば、シアン、マゼンタ、イエロー、ブラック）に対応した不図示のトナーカートリッジから供給されるトナーを用いて画像形成を行う。また、画像処理部１７は、画像入力部１９から入力された画像データに対して、例えば、シェーディング補正や、濃度補正等を施して、メール添付用の出力用画像データを生成する形態を含めてもよい。

【0026】

画像入力部１９は、原稿を走査することにより、画像データを生成する。画像入力部１９は、例えば、ＣＣＤ（Charge coupled device）、ＣＩＤ（Contact image sensor）等のイメージセンサを備え、自動原稿送り装置（ＡＤＦ：Automatic document feeder）や、原稿を載置して読取るためのフラットベット等を有するスキャナ装置として構成することができる。画像入力部１９は、原稿画像からの反射光像をイメージセンサで読取ることで画像データを生成することが可能な構成であれば、その構成に特に制限はない。なお、画像入力部１９は、例えば、ＵＳＢ（Universal serial bus）メモリ等の可搬性記憶媒体に記憶された画像データや、不図示の外部端末装置等から送信された画像データを取得可能なインタフェースとして構成することも可能である。

【0027】

記憶部２１は、複合機１０の動作に必要な各種プログラムや、各種データを記憶する。記憶部２１は、例えば、ＲＡＭ（Random access memory）、ＨＤＤ（Hard disk drive）、ＳＳＤ（Solid state drive）、ＲＯＭ（Read only memory）等の記憶装置により構成することができる。

【0028】

第１実施形態において、記憶部２１は、制御プログラム２１１と、認可・認証プログラム２１２と、アプリケーションプログラム２１３と、ブラウザプログラム２１４と、接続情報管理プログラム２１５とを記憶し、接続情報記憶領域２１６を確保する。

【0029】

制御プログラム２１１は、複合機１０を統括的に制御する際に制御部１１が読み出すプログラムである。制御プログラム２１１を読み出した制御部１１は、ＯＳとして機能し、入力部１３（表示部１３１、操作部１３２）、通信部１５、画像処理部１７、画像入力部１９等の駆動を制御することでプリント、コピー、ファクス、メール送信等の各ジョブの設定、実行、後処理等を行う。

【0030】

認可・認証プログラム２１２は、クラウド３０との間で認可処理・認証処理を行う際に制御部１１が読み出すプログラムである。認可・認証プログラム２１２を読み出した制御部１１は、クラウド３０に対する認可処理・認証処理をＷｅｂブラウザを介して行う。なお、認可・認証プログラム２１２を読み出した制御部１１は、ＯＡｕｔｈ認証といった事前の認可が必要な認証方式に加え、例えば、ユーザ名（ユーザＩＤ）とパスワードとの組み合わせで認証する従来の認証処理（例えば、ＳＭＴＰ認証処理、ＰＯＰ認証処理）や、複合機１０に対するログイン認証も行うことができる。

【0031】

アプリケーションプログラム２１３は、制御部１１が読み出すことにより、プリント、コピー、ファクス、メール送信等の機能を実現することが可能なアプリケーションである。アプリケーションプログラム２１３としては、複合機１０の設定、管理等を司る統合管理アプリケーションであってもよいし、当該統合管理アプリケーションをプラットホームとする個別のアプリケーション（例えば、スキャン送信アプリケーション等）であってもかまわない。なお、アプリケーションプログラム２１３を読み出した制御部１１は、ＡＰＩ（Application Programming Interface）を介し、認可・認証プログラム２１２等の他のプログラムが奏する機能を利用することができる。アプリケーションプログラム２１３と、認可・認証プログラム２１２とは協働することで、クラウド３０との間で認可コードやトークンの取得／更新／受け渡し等を行うことができる。ここでの説明では、アプリケーションプログラム２１３と認可・認証プログラム２１２とを別構成として説明したが、認可・認証プログラム２１２の機能をアプリケーションプログラム２１３に設けることも可能である。

【0032】

ブラウザプログラム２１４は、入力を受けたコンテンツをレンダリングすることにより、閲覧用の画面情報を生成する際に制御部１１が読み出すプログラムである。ブラウザプログラム２１４を読み出した制御部１１は、Ｗｅｂブラウザとして機能し、表示するＷｅｂブラウザ画面を介してユーザによる入力の受付けや、アプリケーションからの通知をユーザに対して表示することができる。

【0033】

接続情報管理プログラム２１５は、クラウド３０に応じて設定されたプロバイダ情報やアカウントを接続情報として管理する際に制御部１１が読み出すプログラムである。また、接続情報管理プログラム２１５を読み出した制御部１１は、後述する接続テストに係るテスト画面を介して、ユーザにより入力・選択された接続情報に基づき接続テストの実行可否を判定する。なお、本開示では、サービスプロバイダとしてのクラウド３０に対し、接続（通信）の確立が可能か否かを試みる行為を接続テストと称する。そして、制御部１１は、接続テストの実行が可能であると判定した場合には、テスト画面を介して入力・選択された接続情報を用いた接続テストを実施する。なお、接続テストが成功した場合、制御部１１は、接続情報の登録指示を受付け、当該接続情報を接続情報記憶領域２１６に記憶する。

【0034】

接続情報記憶領域２１６は、クラウド３０に対する接続情報を記憶する記憶領域である。接続情報記憶領域２１６は、接続情報管理プログラム２１５を読み出した制御部１１による制御に基づき、登録指示を受けた接続情報を記憶する。なお、接続情報記憶領域２１６は、複合機１０以外のネットワークＮＷに接続された不図示の外部記憶装置等に設けることも可能である。

【0035】

ところで、接続テストに成功した接続情報は、図３で例示する接続情報管理テーブル２１６１として管理することも可能である。ここで、接続情報管理テーブル２１６１のデータ構成について図３を用いて説明する。なお、図３で例示する接続情報管理テーブル２１６１のデータ構成例は、あくまでも一例であり、接続情報の管理が図３の例示に限定されるものではない。例えば、接続情報管理テーブル２１６１は、図３で例示する管理項目以外の項目を含んでも良く、管理形式もテーブル形式に限定されず、データベースであってもかまわない。

【0036】

図３で例示する接続情報管理テーブル２１６１は、ＩＤと、ユーザ名と、プロバイダと、使用アカウントと、認証方式と、認可状態と、トークン取得状態とを含む。

【0037】

ＩＤは、管理する接続情報を一意に識別するための識別子である。ユーザ名は、接続情報に係るアカウントの所有者の名称を表す。プロバイダは、認可・認証先のサービスプロバイダの名称を表すプロバイダ情報である。使用アカウントは、認可処理・認証処理に用いるアカウントを表す。認証方式は、当該アカウントに対応した認証方式を表す。認可状態は、認証方式が“ＯＡｕｔｈ”認証である場合における認可状態を表す。トークン取得状態は、認証情報としてのトークンの取得状態を表す。なお、接続情報管理テーブル２１６１は、これらの管理項目以外にも、例えば、使用アカウントに対応付けたパスワード、トークン（自体）、認可コード、アカウント所有者の連絡先（例えば、メールアドレス）等を管理項目に含めてもよい。

【0038】

例えば、ＩＤ“０１”に係る接続情報は、ユーザ名“ａｄｍｉｎ”を所有者とするアカウントを表している。ＩＤ“０１”に係るアカウントは、サービスプロバイダ “ａａｂｂｃｃ”（クラウド３０に相当）を認可・認証先とし、このときの接続に用いられた使用アカウントが“[e-mail]”であることを表している。そして、ＩＤ“０１”に係る接続情報は、認証方式が“ＯＡｕｔｈ”認証方式であって、認可状態が“認可済”、トークンが“取得済”であることを表している。

【0039】

また、ＩＤ“０２”に係る接続情報は、ユーザ名“ｕｓｅｒ０１”を所有者とするアカウントを表している。ＩＤ“０２”に係るアカウントは、サービスプロバイダ“ｄｄｅｅｆｆ”を認証先とし、このときの接続に用いられた使用アカウントが“[e-mail]”であることを表している。そして、ＩＤ“０２”に係る接続情報は、認証方式が“ＳＭＴＰ”認証方式であることを表している。

【0040】

図３での例示の様に、接続テストに成功した接続情報は、接続情報、認証方式、ログインユーザ（管理者権限の有無）、接続テストの実施タイミング等の種々のパラメータに応じて一元的に管理することも可能である。

【0041】

［１．２．２ クラウド３０について］
第１実施形態に係るクラウド３０は、ＯＡｕｔｈ認証方式に基づく認可コードフローを実施することでメール配信の利用認可を行う認可サーバを含む構成であれば、既知の構成を用いることができる。したがって、クラウド３０の機能構成に関する説明は省略する。

【0042】

［１．３ 処理の流れ］
次に、第１実施形態に係る処理の流れについて、図４及び図５のフローチャートを用いて説明する。なお、図４及び図５で説明する処理は、制御部１１が制御プログラム２１１、認可・認証プログラム２１２、アプリケーションプログラム２１３、ブラウザプログラム２１４、接続情報管理プログラム２１５等を読み出すことで実行する処理である。また、図４及び図５では、後述するテスト画面にユーザが想定した接続情報が入力されていることを前提に説明する。さらに、図４及び図５では、ＯＡｕｔｈ認証以外の認証方式としてＳＭＴＰ認証について例示しているが、ＰＯＰ認証の場合も基本的には同様の処理の流れとなる。

【0043】

まず、制御部１１は、接続テストの実行指示を受付ける実行ボタンの選択を受付ける（ステップＳ１０）。

【0044】

制御部１１は、テスト画面において入力された接続情報を確認する（ステップＳ１２）。そして、制御部１１は、入力された接続情報に問題がないか否かを判定する（ステップＳ１４）。入力された接続情報に問題なし、すなわち、接続テストの成否に関わらず、例えば、接続情報に加え、通信に利用するポート番号等が入力され、接続テストの実行に障害が無ければ、制御部１１は接続情報に問題なしと判定する。接続情報に問題なしと判定した場合、制御部１１は、認証方式の登録状態がＯＡｕｔｈ認証以外であるか、ＯＡｕｔｈ認証に係るステータスが未認可であるかを判定する（ステップＳ１４；Ｙｅｓ→ステップＳ１６）。

【0045】

ここで、認証方式がＯＡｕｔｈ認証以外とは、例えば、ＳＭＴＰ認証、ＰＯＰ認証、プレーンテキスト認証、認証なし等のＯＡｕｔｈ認証以外の認証方式を意図しており、事前に認可を要しない認証方式であれば特に制限はない。また、ＯＡｕｔｈ認証に係るステータスが未認可とは、テスト画面を介した接続情報の入力以前にＯＡｕｔｈ認証方式による認可フローが実施された経験がなく、ＯＡｕｔｈ認証を利用する設定とはなっていない状況であるか、又はＯＡｕｔｈ認証による認可フローが実施された経験はあるが、認可が失敗したり、ＯＡｕｔｈ認証を利用する際の設定が削除される等の理由により、認可状況が未認可である状況を意図している。なお、認証方式の登録状態は、複合機１０の装置設定として適用される認証方式の登録状態であってもよいし、接続情報記憶領域２１６に記憶した接続情報に基づく認証方式の登録状態であってもかまわない。

【0046】

認証方式がＯＡｕｔｈ認証以外ではなく、ＯＡｕｔｈ認証に係るステータスが未認可ではないと判定した場合、制御部１１は、認証方式がＯＡｕｔｈ認証方式であって、ＯＡｕｔｈ認証での認可に伴う認証情報が取得済であるか否かを判定する（ステップＳ１６；Ｎｏ→ステップＳ１８）。

【0047】

認証方式がＯＡｕｔｈ認証方式であって、ＯＡｕｔｈ認証での認可に伴う認証情報が取得済であると判定した場合、制御部１１は、接続情報記憶領域２１６から登録済の接続情報（プロバイダ情報及びアカウント）を読み出す（ステップＳ１８；Ｙｅｓ→ステップＳ２０）。

【0048】

次いで、制御部１１は、登録済の接続情報とテスト画面に入力した接続情報とが一致するか否かを判定する。登録済の接続情報とテスト画面に入力した接続情報とが一致すると判定した場合、制御部１１は、ＳＭＴＰサーバへの接続確認を行う（ステップＳ２２；Ｙｅｓ→ステップＳ３０）。ＳＭＴＰサーバへの接続が成功したと判定した場合、制御部１１は、認証方式がＯＡｕｔｈ認証であるか否かを判定する（ステップＳ３２；Ｙｅｓ→ステップＳ３４）。

【0049】

認証方式がＯＡｕｔｈ認証であると判定した場合、制御部１１はトークンを取得する（ステップＳ３４；Ｙｅｓ→ステップＳ３６）。トークンを取得すると、制御部１１は、ＯＡｕｔｈ認証を実施する（ステップＳ３８）。そして、制御部１１は、ＯＡｕｔｈ認証が成功したか否かを判定する（ステップＳ４０）。なお、登録済の接続情報に基づくトークンの取得から時間が経過しておらず、同一のトークンが利用可能（有効期限内）である場合は、ステップＳ３６に係る処理を省略してもよい。この場合、登録済の接続情報に基づくトークンを取得してからの経過時間を計測しておき、所定の経過時間が経過した場合に、トークンを取得する構成とすることも可能である。

【0050】

ＯＡｕｔｈ認証方式による認証が成功したと判定した場合、制御部１１は接続テストが成功したと判定し、処理を終了する（ステップＳ４０；Ｙｅｓ→ステップＳ４２）。

【0051】

なお、ステップＳ１６において、認証方式がＯＡｕｔｈ認証以外、ＯＡｕｔｈ認証に係るステータスが未認可であると判定した場合、制御部１１は、ＰＯＰ ｂｅｆｏｒｅ ＳＭＴＰが有効であるか否かを判定する（ステップＳ１６；Ｙｅｓ→ステップＳ２４）。

【0052】

ＰＯＰ ｂｅｆｏｒｅ ＳＭＴＰが有効であると判定した場合、制御部１１は、テスト画面に入力した接続情報を用いてＰＯＰサーバへの接続確認を行う（ステップＳ２４；Ｙｅｓ→ステップＳ２６）。ＰＯＰサーバへの接続が成功したと判定した場合、制御部１１は、ＳＭＴＰサーバへの接続確認を行う（ステップＳ２８；Ｙｅｓ→ステップＳ３０）。なお、ＰＯＰ ｂｅｆｏｒｅ ＳＭＴＰが有効ではないと判定した場合、制御部１１は、ステップＳ２６及びステップＳ２８の処理を省略し、ＳＭＴＰサーバへの接続確認を行う（ステップＳ２４；Ｎｏ→ステップＳ３０）。なお、ステップＳ３０以降の処理についての説明は、上述のとおりであるため、ここでは省略する。

【0053】

ところで、ステップＳ３４において、認証方式がＯＡｕｔｈ認証ではないと判定した場合、制御部１１は、認証方式がＳＭＴＰ認証であるか否かを判定する（ステップＳ３４；Ｎｏ→ステップＳ４４）。認証方式がＳＭＴＰ認証であると判定した場合、制御部１１は、ＳＭＴＰ認証を行う（ステップＳ４４；Ｙｅｓ→ステップＳ４６）。そして、制御部１１は、ＳＭＴＰ認証が成功したか否かを判定する（ステップＳ４０）。

【0054】

ＳＭＴＰ認証方式による認証が成功したと判定した場合、制御部１１は接続テストが成功したと判定し、処理を終了する（ステップＳ４０；Ｙｅｓ→ステップＳ４２）。

【0055】

一方、認証方式がＳＭＴＰ認証方式ではないと判定した場合、制御部１１は認証無しで接続テストは成功したと判定し、処理を終了する（ステップＳ４４；Ｎｏ→ステップＳ４２）。

【0056】

なお、テスト画面に入力された接続情報に問題がある場合（ステップＳ１４；Ｎｏ）、認証方式がＯＡｕｔｈ認証方式であって、ＯＡｕｔｈ認証での認可に伴う認証情報が取得済でないと判定した場合（ステップＳ１８；Ｎｏ）、登録済の接続情報とテスト画面に入力した接続情報とが一致しないと判定した場合（ステップＳ２２；Ｎｏ）、ＰＯＰサーバへの接続が失敗したと判定した場合（ステップＳ２８；Ｎｏ）、ＳＭＴＰサーバへの接続が失敗したと判定した場合（ステップＳ３２；Ｎｏ）、又はＯＡｕｔｈ認証方式による認証が失敗したと判定した場合（ステップＳ４０；Ｎｏ）、制御部１１は、接続テストは失敗であるとして処理を終了する。

【0057】

［１．４ 動作例］
次に、第１実施形態に係る動作例について説明する。図６は、テスト画面Ｗ１００の表示構成例を説明する図である。図６で例示するテスト画面Ｗ１００は、認証方式選択プルダウンメニューＰ１０を介し、認証方式としてＯＡｕｔｈ認証が選択された場合に制御部１１が表示するテスト画面Ｗ１００の表示構成例である。

【0058】

テスト画面Ｗ１００は、接続情報入力領域Ｒ１０と、接続テスト実行領域Ｒ２０とを含む。接続情報入力領域Ｒ１０は、接続情報の入力を受付ける領域である。接続情報入力領域Ｒ１０は、認証方式選択プルダウンメニューＰ１０を介して選択された認証方式に応じて異なる項目を表示することができる。図６で例示するテスト画面Ｗ１００では、ＯＡｕｔｈ認証の選択に伴い、接続情報の入力項目として、プロバイダ入力ボックスＢｘ１０、アカウント名入力ボックスＢｘ１２、及び表示項目としてトークン取得状況表示領域Ｒ１２を表示する。

【0059】

プロバイダ入力ボックスＢｘ１０は、認可処理・認証処理の対象となるサービスプロバイダを特定するためのプロバイダ情報の入力を受付ける入力ボックスである。プロバイダ入力ボックスＢｘ１０には、例えば、サービスプロバイダとしてのクラウド３０の名称、ドメイン名、ＵＲＬ（Uniform Resource Locator）等のネットワークＮＷ上でクラウド３０を特定するための情報を入力することができる。

【0060】

アカウント名入力ボックスＢｘ１２は、プロバイダ入力ボックスＢｘ１０で入力したサービスプロバイダに対するアカウントの入力を受付ける入力ボックスである。

【0061】

トークン取得状況表示領域Ｒ１２は、ＯＡｕｔｈ認証での認可に伴いサービスプロバイダから発行されたトークンの取得状況を表示する領域である。トークン取得状況表示領域Ｒ１２には、例えば、“未取得”、“取得済”、“取得処理中”、“無効”、“－（未確認）”等をトークンの取得状況に応じて表示することができる。なお、トークン取得状況表示領域Ｒ１２には、ＯＡｕｔｈ認証を実行するための条件を図６での例示の様に表示してもよい。ユーザは、ＯＡｕｔｈ認証を実行するための条件として表示された表示内容（ＯＡｕｔｈ２．０認証を有効にするためには、トークンを取得する必要があります。本体操作パネルのシステム設定によりトークンを取得してください。）を確認することによりＯＡｕｔｈ認証を実行するための条件を容易に把握することができる。

【0062】

接続テスト実行領域Ｒ２０は、接続テストの実行指示を受付ける実行ボタンＢ１０と、実行結果等表示領域Ｒ２２と、登録ボタンＢ１２とを含む。実行ボタンＢ１０は、接続テストの実行指示を受付けるボタンである。制御部１１は、ユーザにより実行ボタンＢ１０の選択を受付けると、接続テストを実行する。実行結果等表示領域Ｒ２２は、接続テストの実行結果や、ユーザに対して通知する情報を表示する領域である。登録ボタンＢ１２は、接続テストが成功した場合に、接続情報入力領域Ｒ１０を介して入力された接続情報の登録指示を受付けるボタンである。なお、登録ボタンＢ１２は、実行した接続テストが成功したタイミングで表示されてもよい。制御部１１は、登録ボタンＢ１２の選択を受付けると、接続情報入力領域Ｒ１０を介して入力された接続情報を接続に成功した第１の接続情報として接続情報記憶領域２１６に記憶する。

【0063】

図７は、ユーザが、テスト画面Ｗ１００の接続情報入力領域Ｒ１０を介して接続情報を入力する様子を説明する図である。図７は、認証方式選択プルダウンメニューＰ１０を介して認証方式としてＯＡｕｔｈ認証が選択され、プロバイダ入力ボックスＢｘ１０に認可処理・認証処理の対象とするサービスプロバイダとしてのクラウド３０の名称“ａａｂｂｃｃ”の入力後、接続に使用するアカウントとして“[e-mail]”が入力途中（ａｄｍｉｎ＠．．．）である様子を表している。

【0064】

図８は、接続テストが成功した場合のテスト画面Ｗ１００の表示構成例を説明する図である。図８で例示する動作例は、図５のステップＳ４２に係る処理に相当する動作例である。

【0065】

図８は、実行ボタンＢ１０の選択指示を受付けて実行した接続テストが成功した旨（接続テストが成功しました。入力した接続情報を登録する場合は、［登録ボタン（Ｕ）］を選択してください。）を実行結果等表示領域Ｒ２２に表示した例示である。このとき、トークン取得状況表示領域Ｒ１２には、トークンが取得済であることを表す“取得済”が表示される。制御部１１は、ユーザによる登録ボタンＢ１２の選択を受付けると、接続情報入力領域Ｒ１０を介して入力された接続情報を、接続に成功した第１の接続情報として接続情報記憶領域２１６に記憶する。

【0066】

図９は、接続テストが失敗した場合のテスト画面Ｗ１００の表示構成例を説明する図である。図９で説明する動作例は、制御部１１が、図４のステップＳ２２において、登録済の接続情報とテスト画面Ｗ１００に入力した接続情報とが一致しないと判定した場合（ステップＳ２２；Ｎｏ）の処理に相当する。

【0067】

登録済の接続情報とテスト画面Ｗ１００（プロバイダ入力ボックスＢｘ１０、アカウント名入力ボックスＢｘ１２）に入力した接続情報とが一致しない場合、制御部１１は、接続情報が一致しないため、接続テストを継続できない旨を主旨とする内容（接続情報が一致しないため、接続テストを継続できません。接続情報を確認してください）をエラー表示として実行結果等表示領域Ｒ２２に表示する。

【0068】

ユーザは、実行結果等表示領域Ｒ２２に表示された内容を確認することにより、想定した接続情報が正しくないために接続テストを継続できないことを把握することができる。

【0069】

図９と同様に図１０は、接続テストが失敗した場合のテスト画面Ｗ１００の他の表示構成例を説明する図である。図１０で説明する動作例は、制御部１１が、図４のステップＳ１８において、ＯＡｕｔｈ認証での認可に伴う認証情報としてのトークンが取得済ではないと判定した場合（ステップＳ１８；Ｎｏ）の処理に相当する。

【0070】

ＯＡｕｔｈ認証での認可に伴うトークンが取得済でない場合、制御部１１は、トークンが取得済でないため、接続テストを継続できない旨を主旨とする内容（トークンが未取得です。接続テストを継続できませんので処理を終了します）をエラー表示として実行結果等表示領域Ｒ２２に表示する。

【0071】

ユーザは、実行結果等表示領域Ｒ２２に表示された内容を確認することにより、トークンが取得済でないために接続テストを継続できないことを把握することができる。

【0072】

このように、接続テストが失敗した場合に、接続テストの失敗に係る原因（未完了項目、不備等）をエラー表示することで、ユーザは、具体的にどの項目を入力（又は修正）すればよいか容易に認識することができる。

【0073】

なお、テスト画面Ｗ１００の接続情報入力領域Ｒ１０を介しての接続情報の入力中は、入力が完了しておらず、接続テストも成功していない状態であるため、実行（Ｊ）ボタン、登録ボタン（Ｕ）をグレーアウト表示し、ユーザが当該ボタンを選択できないように表示制御することも可能である。この場合、必要な接続情報の入力が完了した時点で、実行（Ｊ）ボタンをアクティブとし（選択可能な状態）とし、接続テストが成功した場合に、登録（Ｕ）ボタンをアクティブとすることで、ユーザが誤ったタイミングで実行（Ｊ）ボタン、登録（Ｕ）ボタンを選択することを未然に防止することができる。また、接続テストが失敗した場合にも、テスト画面Ｗ１００の実行（Ｊ）ボタン、登録ボタン（Ｕ）をグレーアウト表示し、ユーザによる当該ボタンの選択を制限することも可能である。

【0074】

図１１は、認証方式選択プルダウンメニューＰ１０を介し、認証方式としてＳＭＴＰ認証、ＰＯＰ認証等のＯＡｕｔｈ認証以外の認証方式が選択された場合に制御部１１が表示するテスト画面Ｗ１１０の表示構成例である。なお、図１１では、ＳＭＴＰ認証に係る接続情報の入力について説明するものとし、図６で例示したテスト画面Ｗ１００と同一構成とすることができる箇所については、同一の符号を付してその説明を省略することがある。

【0075】

テスト画面Ｗ１１０は、接続情報入力領域Ｒ１４と、接続テスト実行領域Ｒ２０とを含む。図１１で例示する接続情報入力領域Ｒ１４は、プロバイダ入力ボックスＢｘ１０と、ユーザ名入力ボックスＢｘ１４と、パスワード入力ボックスＢｘ１６と、パスワード変更チェックボックスＴ１０とを含む。

【0076】

プロバイダ入力ボックスＢｘ１０は、認証処理の対象となるサービスプロバイダを特定するためのプロバイダ情報の入力を受付ける入力ボックスである。プロバイダ入力ボックスＢｘ１０には、例えば、サービスプロバイダとしてのクラウド３０の名称、ドメイン名、ＵＲＬ等のネットワークＮＷ上でクラウド３０を特定するための情報を入力することができる。

【0077】

ユーザ名入力ボックスＢｘ１４は、プロバイダ入力ボックスＢｘ１０で入力したサービスプロバイダに対するユーザ名の入力を受付ける入力ボックスである。パスワード入力ボックスＢｘ１６は、ユーザ名入力ボックスＢｘ１４で入力したユーザ名に対応して設定されたパスワードの入力を受付ける入力ボックスである。ユーザ名入力ボックスＢｘ１４で入力されたユーザ名と、パスワード入力ボックスＢｘ１６で入力されたパスワードとは互いに関連付けられ、サービスプロバイダに対する接続情報として用いられる。パスワード変更チェックボックスＴ１０は、パスワードの変更指示を受付けるチェックボックスである。パスワード変更チェックボックスＴ１０にチェックが付されると、制御部１１はパスワードの変更を受け付ける。

【0078】

第１実施形態では、認証方式選択プルダウンメニューＰ１０を介して認証方式としてＳＭＴＰ認証、ＰＯＰ認証等のＯＡｕｔｈ認証以外の認証方式が選択された場合、制御部１１は接続情報入力領域Ｒ１４に入力された接続情報に基づき接続テストを実行する（図４のステップＳ１６；Ｙｅｓ以降の処理に相当）。

【0079】

実行ボタンＢ１０の選択指示を受付けて実行した接続テストが成功した場合、制御部１１は接続テストが成功した旨（接続テストが成功しました。入力した接続情報を登録する場合は、［登録ボタン（Ｕ）］を選択してください。）を実行結果等表示領域Ｒ２２に表示することができる。制御部１１は、ユーザによる登録ボタンＢ１２の選択を受付けると、接続情報入力領域Ｒ１０を介して入力された接続情報を、接続に成功した接続情報として接続情報管理テーブル２１６１に記憶する。

【0080】

図１２は、第１実施形態に係る接続テストの実行に関し、接続テストボタン（実行ボタンＢ１０）の選択時におけるテスト画面Ｗ１００上の状態と、認証方式の登録状態との対応関係を説明する図である。

【0081】

第１実施形態において、制御部１１は、以下の（１）、（２）で示す条件下において接続テストを実行すると判定する。
（１）テスト画面Ｗ１００を介して入力・選択された接続情報が、ＯＡｕｔｈ認証以外の認証方式（ＳＭＴＰ：認証なし／ＳＭＴＰ認証、ＰＯＰ３：プレーンテキスト認証／ＰＯＰ認証）である場合、認証方式の登録状態がＯＡｕｔｈ認証であってもＯＡｕｔｈ認証に係るステータスが未認可（トークンが未取得）である場合や、認証方式の登録状態がＯＡｕｔｈ認証以外の認証方式に係る接続情報である場合、制御部１１は、テスト画面Ｗ１００を介して受付けた接続情報を用いて接続テストを実行する（図中点線枠内）。
（２）認証方式の登録状態がＯＡｕｔｈ認証であって、認可に伴う認証情報としてのトークンが取得済であり、テスト画面Ｗ１００を介して入力・選択された接続情報がＯＡｕｔｈ認証に係る接続情報である場合に限り、制御部１１は、テスト画面Ｗ１００を介して入力・選択された接続情報と登録された接続情報とを比較する。そして、制御部１１は、テスト画面Ｗ１００を介して入力・選択された接続情報と登録された接続情報とが同一である場合に接続テストを実行する（図中太枠線内）。

【0082】

上記（１）、（２）で示す条件以外の場合、制御部１１は接続テストをエラーとして判定する。この場合、制御部１１は、例えば、テスト画面Ｗ１００における接続情報入力領域を、接続情報入力領域Ｒ１４（ＳＭＴＰ認証等に係る接続情報の入力領域）から接続情報入力領域Ｒ１０（ＯＡｕｔｈ認証に係る接続情報の入力領域）に画面更新し、接続テストの継続を促すように構成するのが好ましい。

【0083】

以上のように、第１実施形態によれば、認証方式の登録状態がＯＡｕｔｈ認証であって、認可に伴う認証情報としてのトークンが取得済であり、テスト画面を介して入力・選択された接続情報がＯＡｕｔｈ認証に係る接続情報である場合に限り、テスト画面を介して入力・選択された接続情報と登録された接続情報とを比較し、当該接続情報が一致した場合に、接続テストの実行が可能と判定する構成であるため、接続テストに成功した接続情報とテスト画面で入力した接続情報との間で齟齬が発生することを防止することができる。そして、認証方式がＯＡｕｔｈ認証以外の事前の認可を要しない認証方式である場合は、テスト画面で入力した接続情報に基づき接続テストを実行することができるため、従来の認証方式に対応した接続テストの利便性が低下する恐れもない。

【0084】

［２ 第２実施形態］
第２実施形態は、第１実施形態において、認証情報としてのトークンの取得状況（未取得、取得処理中、無効）に基づき接続テストがエラーと判定された場合に、ユーザに対してエラー内容を通知する形態である。

【0085】

第２実施形態では、例えば、図１３から図１５で例示するメッセージ画面を構成するコンテンツを記憶部２１に記憶し、制御部１１は、接続テストがエラーと判定した場合に、当該メッセージ画面をトークンの取得状況（未取得、取得処理中、無効）に応じてテスト画面に表示する。その他の構成や処理の流れについては、第１実施形態と略同様であるため、ここでの説明は省略する。

【0086】

［２．１ 動作例］
図１３は、認証情報としてのトークンの未取得を理由として、接続テストをエラーと判定した場合に、制御部１１が表示するメッセージ画面Ｍ１０の表示構成例を説明する図である。なお、図１３で例示するテスト画面Ｗ１２０は、図１０で例示したテスト画面Ｗ１００にメッセージ画面Ｍ１０を重畳して表示した例示である。

【0087】

メッセージ画面Ｍ１０は、認証情報としてのトークンが未取得である旨と、トークンを取得するためのシステム設定画面等への画面移動を促す内容を表示した例示である。この場合、システム設定画面（トークン取得画面）への画面移動の選択を受付ける移動するボタンＢ１４や、画面移動を行わず処理の終了を受け付ける終了するボタンＢ１６等を設けることで、ユーザによるトークンの取得等の操作を容易にすることができる。なお、システム設定画面（トークン取得画面）への画面移動を行わず、トークンを取得するための手段（例えば、トークン取得ボタン等）を設け、トークン取得に係る処理がメッセージ画面Ｍ１０上で完結するように構成しても良い。

【0088】

図１４は、認証情報としてのトークンの取得処理中を理由として、接続テストをエラーと判定した場合に、制御部１１が表示するメッセージ画面Ｍ１２の表示構成例を説明する図である。なお、図１４で例示するテスト画面Ｗ１３０は、図１０で例示したテスト画面Ｗ１００にメッセージ画面Ｍ１２を重畳して表示した例示である。

【0089】

メッセージ画面Ｍ１２は、認証情報としてのトークンが未取得（取得処理中）である旨と、トークン取得が完了するまでユーザに待機を促す内容を表示した例示である。メッセージ画面Ｍ１２には、接続テストのエラーがトークンの未取得（取得処理中）に起因する旨が表示されるため、ユーザは、接続テストのエラーの原因を容易に把握することができる。なお、メッセージ画面Ｍ１２には、トークンの取得状況を確認するための画面への画面移動の選択を受付けるためのボタンを表示してもよい。

【0090】

図１５は、認証情報としてのトークンの無効（例えば、有効期限切れ）を理由として、接続テストをエラーと判定した場合に、制御部１１が表示するメッセージ画面Ｍ１４の表示構成例を説明する図である。なお、図１５で例示するテスト画面Ｗ１４０は、図１０で例示したテスト画面Ｗ１００にメッセージ画面Ｍ１４を重畳して表示した例示である。

【0091】

メッセージ画面Ｍ１４は、認証情報としてのトークンが無効である旨と、トークンを再取得するための認可画面等への画面移動を促す内容を表示した例示である。この場合、認可画面への画面移動の選択を受付ける移動するボタンＢ１８や、画面移動を行わず処理の終了を受け付ける終了するボタンＢ２０等を設けることで、ユーザによる認可処理、トークンの再取得等の操作を容易にすることができる。なお、認可画面（トークン取得画面）への画面移動を行わず、認可、トークンを再取得するための手段（例えば、再取得ボタン等）を設け、トークン再取得に係る処理がメッセージ画面Ｍ１４上で完結するように構成しても良い。

【0092】

なお、認証情報としてのトークンの無効（例えば、有効期限切れ）を理由として、接続テストをエラーと判定した場合、接続情報の入力を制限することも可能である。

【0093】

図１６は、認証情報としてのトークンの無効（例えば、有効期限切れ）を理由として、接続テストをエラーと判定した場合に、制御部１１が表示するメッセージ画面Ｍ１６の表示構成例を説明する図である。なお、図１６で例示するテスト画面Ｗ１５０は、図１０で例示したテスト画面Ｗ１００にメッセージ画面Ｍ１６を重畳して表示した例示であり、プロバイダ入力ボックスＢｘ１０及びアカウント名入力ボックスＢｘ１２に対する接続情報の入力を制限したものである。

【0094】

メッセージ画面Ｍ１６は、認証情報としてのトークンが無効である旨と、接続情報の入力を受付ける各項目（プロバイダ入力ボックスＢｘ１０及びアカウント名入力ボックスＢｘ１２）への入力を制限する旨を表示した例示である。このように、トークンが無効である場合に、接続情報の入力を制限することで、ユーザが誤った接続情報を入力することを防止することができる。なお、テスト画面Ｗ１５０には、トークンの削除指示を受付ける削除ボタンＢ１４を設けても良い。ユーザは、削除Ｂ１４を選択することで無効のトークンを削除することができる。

【0095】

以上のように、第２実施形態によれば、認証情報としてのトークンの取得状況（未取得、取得処理中、無効）に基づき接続テストがエラーと判定された場合に、ユーザに対してエラー内容が通知されるため、ユーザはエラーの理由を容易に把握することができる。また、第２実施形態によれば、エラーの解消を図るための手段やヒントも併せて提供することができるため、ユーザはエラー内容を把握した上で、エラーの解消を図ることができる。

【0096】

［３ 変形例］
テスト画面を介した接続情報の入力・選択に関し、認証方式の登録状態がＯＡｕｔｈ認証であって、認可に伴うトークンが取得済である場合には、テスト画面を介した接続情報の入力・選択を制限することも可能である。

【0097】

例えば、図１７は、認証方式の登録状態がＯＡｕｔｈ認証であって、認可に伴うトークンが取得済である場合に、テスト画面を介した接続情報の入力・選択を制限するテスト画面Ｗ１６０の表示構成例を説明する図である。図１７は、テスト画面Ｗ１６０を介した接続情報の入力が不可である旨をユーザに対して明示するため、プロバイダ入力ボックスＢｘ１０及びアカウント名入力ボックスＢｘ１２を暗転表示することで、接続情報の入力を制限した例示である。この他にも、現在設定されているプロバイダとアカウント名とをグレーアウト表示することで、接続情報の入力を制限してもよい。なお、［削除（Ｏ）ボタン］Ｂ２２は、現在の接続情報の削除指示を受付けるためのボタンである。このように、認証方式の登録状態がＯＡｕｔｈ認証であって、認可に伴うトークンが取得済である場合に、接続情報の入力を制限することで、ユーザが誤った接続情報を入力することを未然に防止することができる。

【0098】

本開示は、認証方式として、ＯＡｕｔｈ認証以外にも、ＧＮＡＰ（Grant Negotiation and Authorization Protocol）等のトークンベースの認証方式に適用可能である。そして、本開示は上述した各実施の形態に限定されるものではなく、種々の変更が可能である。すなわち、本開示の要旨を逸脱しない範囲内において適宜変更した技術的手段を組み合わせて得られる実施の形態についても本開示の技術的範囲に含まれる。

【0099】

また、上述した実施形態は、説明の都合上、それぞれ別に説明している部分があるが、技術的に可能な範囲で組み合わせて実行してもよいことは勿論である。

【0100】

また、実施形態において各装置で動作するプログラムは、上述した実施形態の機能を実現するように、ＣＰＵ等を制御するプログラム（コンピュータを機能させるプログラム）である。そして、これら装置で取り扱われる情報は、その処理時に一時的に一時記憶装置（例えば、ＲＡＭ）に蓄積され、その後、各種ＲＯＭ（Read Only Memory）やＨＤＤ等の記憶装置に格納され、必要に応じてＣＰＵによって読み出し、修正・書き込みが行なわれる。

【0101】

ここで、プログラムを格納する記録媒体としては、半導体媒体（例えば、ＲＯＭや、不揮発性のメモリカード等）、光記録媒体・光磁気記録媒体（例えば、ＤＶＤ（Digital Versatile Disc）、ＭＯ（Magneto Optical Disc）、ＭＤ（Mini Disc）、ＣＤ（Compact Disc）、ＢＤ （Blu-ray（登録商標）Disc等））、磁気記録媒体（例えば、磁気テープ、フレキシブルディスク等）等の何れであってもよい。また、ロードしたプログラムを実行することにより、上述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、オペレーティングシステムあるいは他のアプリケーションプログラム等と共同して処理することにより、本開示の機能が実現される場合もある。

【0102】

また、市場に流通させる場合には、可搬型の記録媒体にプログラムを格納して流通させたり、インターネット等のネットワークを介して接続されたサーバコンピュータに転送したりすることができる。この場合、サーバコンピュータの記憶装置も本開示に含まれるのは勿論である。

【0103】

また、上述した実施形態に用いた装置の各機能ブロック、又は諸特徴は、電気回路、例えば、集積回路あるいは複数の集積回路で実装、実行することも可能である。本明細書で述べた機能を実現するように設計された電気回路は、汎用用途プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又はその他のプログラマブル論理デバイス、ディスクリートゲート又はトロンジスタロジック、ディスクリートハードウェア部品、又はこれらを組み合わせたものを含んでもよい。汎用用途プロセッサは、マイクロプロセッサでもよいし、従来型のプロセッサ、コントローラ、マイクロコントローラ、又はステートマシンであってもよい。前述した電気回路は、デジタル回路で構成されていてもよいし、アナログ回路で構成されていてもよい。また、半導体技術の進歩により現在の集積回路に代替する集積回路化の技術が出現した場合、本開示の一以上の態様は当該技術による新たな集積回路を用いることも可能である。

【符号の説明】

【0104】

１０ 複合機
１１ 制御部
１３ 入力部
１３１ 表示部
１３２ 操作部
１５ 通信部
１７ 画像処理部
１９ 画像入力部
２１ 記憶部
２１１ 制御プログラム
２１２ 認可・認証プログラム
２１３ アプリケーションプログラム
２１４ ブラウザプログラム
２１５ 接続情報管理プログラム
２１６ 接続情報記憶領域
３０ クラウド

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】