JP2021196908A - サーバ装置、システム、制御方法及びプログラム - Google Patents

Abstract

【課題】サービス提供期間が制限されているデバイスの使用後に、サービス提供用の認可情報を適切に破棄する。【解決手段】サーバ装置は、サービス提供用の認可情報を取得する認可情報取得部と、デバイスからデバイス情報を受信して管理するデバイス管理部と、デバイスを使用するユーザに関するユーザ情報、認可情報、デバイス情報を関連付けて管理するユーザ情報管理部と、デバイスがサービスのサービス提供期間が制限されている制限付きデバイスであるか否かを判定するデバイス判別部と、を有する。ユーザ情報管理部は、デバイスが制限付きデバイスであり且つ制限付きデバイスへのサービス提供期間の開始から一定期間が経過した場合に、デバイス情報に関連する前記認可情報の無効化及び削除を行う。【選択図】図９

Description

本発明は、サービス提供サーバから通信装置へのサービスの提供を仲介するサーバ装置、システム、制御方法及びプログラムに関する。

ＯＡｕｔｈ２．０で定められている権限委譲のフローにおいて、クライアントは、リソースオーナーが認可に同意したことを証明する認可コードを受け取る。これにより、クライアントは、Ｗｅｂサービスを提供するサービス提供サーバに対して、アクセストークンの発行を要求することができる。特許文献１に開示される技術では、サービス提供サーバから取得したアクセストークンが、クラウド上のクライアント（仲介サーバ）で管理される。そして、リソースオーナーが使用する通信装置が、仲介サーバからアクセストークンを取得する。これにより、複数の通信装置が、同一のアクセストークンを共用し、サービス提供サーバからサービスの提供を受けることが可能となる。

特開２０１７−１８４１１８

ところで、通信装置を提供する企業がユーザに対し一時的に通信装置を試用機として貸与し、一定期間試用させた後に、試用機を回収するというビジネスモデルが存在する。ユーザは、通信装置の試用により購入を検討し、試用機を返却した後に改めて通信装置の購入に至る。ここで、試用機は企業への返却後別のユーザに貸与されるため、試用機と購入通信装置は別の端末となる。

試用機でサービス提供サーバのアクセストークンを取得した場合、仲介サーバにアクセストークンが保存される。サービス提供サーバへの認可の解除を行わずに試用機を返却した場合、仲介サーバにアクセストークンが残り続けてしまう。不要なアクセストークンを所持し続けると、万が一仲介サーバからアクセストークンが漏洩した場合に第三者がユーザの権限でサービス提供サーバにアクセスできてしまう。このため、不要になったアクセストークンは破棄しておきたい。また、サービス提供サーバ上には仲介サーバとの認可情報が残ったままになり、ユーザは通信装置を既に使用していないのに仲介サーバがサービス提供サーバに対してユーザの権限でアクセスしているように見えてしまう。従って、仲介サーバがユーザのあずかり知らぬところでサービス提供サーバへとアクセスしていないことを誇示するために、不要な認可情報は解除しておく必要がある。

本発明は、前述の課題を鑑みてなされたもので、サービス提供期間が制限されているデバイスの使用後に、サービス提供用の認可情報を適切に破棄することを目的とする。

上記の目的を達成するために、本発明におけるサーバ装置は、デバイスに対するサービスの提供を仲介するサーバ装置であって、前記サービスの提供用の認可情報を取得する認可情報取得部と、前記デバイスからデバイス情報を受信して管理するデバイス管理部と、前記デバイスを使用するユーザに関するユーザ情報と、前記認可情報と、前記デバイス情報とを関連付けて管理するユーザ情報管理部と、前記デバイスが、前記サービスのサービス提供期間が制限されている制限付きデバイスであるか否かを判定するデバイス判別部と、を有し、前記ユーザ情報管理部は、前記デバイスが前記制限付きデバイスであり且つ前記制限付きデバイスへの前記サービス提供期間の開始から一定期間が経過した場合に、前記デバイス情報に関連する前記認可情報の無効化及び削除を行うことを特徴とする。

本発明によれば、サービス提供期間が制限されているデバイスの使用後に、サービス提供用の認可情報を適切に破棄することができる。

ネットワーク構成を示す図。 第１実施形態に係る、仲介サーバの構成を示す図。 第１実施形態に係る、モジュール構成を示す図。 第１実施形態に係る、通信装置登録フローを示す図。 第１実施形態に係る、サービス登録フローを示す図。 第１実施形態に係る、認可フローを示す図。 第１実施形態に係る、サービス登録画面を示す図。 第１実施形態に係る、サービス利用フローを示す図。 第１実施形態に係る、認可情報自動削除フローを示す図。 第２実施形態に係る、通信装置登録フローを示す図。 第３実施形態に係る、認可情報削除フローを示す図。

［第１実施形態］
以下、本発明の第１実施形態について図面を用いて説明する。第１実施形態に係るシステムは、図１に示すような構成のネットワーク上に実現される。図１は、ネットワーク構成を示す図である。ＷＡＮ１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋの略語である。本実施形態のＷＡＮ１００では、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築される。ＬＡＮ１１０、ＬＡＮ１２０、ＬＡＮ１３０は、各構成要素に対して接続される。ＬＡＮは、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋの略語である。ＬＡＮ１１０は、ＷＡＮ１００と仲介サーバ１１１（サーバ装置）とを接続する。ＬＡＮ１２０は、ＷＡＮ１００と通信装置１２１及び通信装置１２２（デバイス）とを接続する。ＬＡＮ１３０は、ＷＡＮ１００とサービス提供サーバ１３１及びサービス提供サーバ１３２とを接続する。

仲介サーバ１１１は、サービス提供サーバ１３１、１３２から、アクセストークン（認可情報）を取得するクライアントであり、取得したアクセストークンを通信装置１２１、１２２へと送信する。仲介サーバ１１１がアクセストークンを取得するためには、ユーザからの権限委譲が必要である。本実施形態では、ユーザは、通信装置１２１、１２２のいずれかを介してサービス提供サーバに対して権限委譲への同意を行う。しかしながら、これに限るものではなく、ユーザが所有するパーソナルコンピュータ（不図示）やスマートフォン（不図示）などから行うようにしてもよい。

サービス提供サーバ１３１、１３２は、ユーザにＷｅｂサービスの提供をするとともに、ユーザが所有者となるリソースを管理する。前記Ｗｅｂサービスは、前記リソース、もしくは前記リソースを利用した機能群を提供する。サービス提供サーバ１３１、１３２は、ユーザが第三者（クライアント）に対してユーザが所有するリソースへのアクセスを許可する手続きを行い、許可の証拠となるアクセストークンを発行する認可サーバとしての役割も有する。なお、サービス提供サーバ１３１、１３２は、それぞれ個別のＬＡＮ上に構成されていてもよいし、同一のＬＡＮ上に構成されていてもよい。また、本実施形態では通信装置およびサービス提供サーバを２台ずつ例示しているが、それぞれ３台以上の構成でもよい。

第１実施形態に係る仲介サーバ１１１は、図２に示すような構成のＰＣから成るシステム上に実現される。図２は、第１実施形態に係る、仲介サーバ１１１の構成を示す図である。なお、仲介サーバ１１１の構成は、通信装置１２１、１２２、サービス提供サーバ１３１，１３２の構成と同様である。また、図２に示されるハードウェアブロック図は、一般的な情報処理装置のハードウェアブロック図に相当する。このため、本実施形態のサーバコンピュータ及び端末には、一般的な情報処理装置のハードウェア構成を適用することができる。

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、又はハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここで、ＯＳとは、コンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。

後述する各フローチャートの処理は、プログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ディスプレイコントローラ（ＤＰＣ）２０６は、外部ディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

なお、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１やＲＯＭ２０３にインストールされたＯＳやアプリケーション等のプログラムである。ソフトウェア上の主体は、ＣＰＵ２０１がそれらプログラムを実行することで実現する。

図３は、第１実施形態に係る、モジュール構成を示す図であり、仲介サーバ１１１、通信装置１２１、１２２、サービス提供サーバ１３１、１３２のモジュール構成を示す。図３（Ａ）は、仲介サーバ１１１のモジュール構成を示す。図３（Ｂ）は、通信装置１２１、１２２のモジュール構成を示す。図３（Ｃ）は、サービス提供サーバ１３１、１３２のモジュール構成を示す。

仲介サーバ１１１は、通信装置情報判別モジュール３１１、通信装置情報管理モジュール３１２、サービス登録モジュール３１３、ユーザ情報管理モジュール３１４、アクセストークン管理モジュール３１５を持つ。通信装置１２１、１２２は、サービス連携モジュール３２１、サービス管理モジュール３２２、アップロード機能モジュール３２３を持つ。サービス提供サーバ１３１および１３２は、認可処理モジュール３３１、アクセストークン発行モジュール３３２、サービス提供モジュール３３３を持つ。

仲介サーバ１１１の通信装置情報判別モジュール３１１は、通信装置が保持する機種情報を受け取り、通信装置１２１、１２２が、「レンタル機」であるか「販売機」であるかを判別する。ここで、レンタル機とは、試用機として利用され、サービス提供期間が制限されている制限付きデバイスであり、特に、ユーザに対して所定の期間だけ貸与した後返却されることが想定される貸与デバイスを示す。一方、販売機とは、一般の小売店等で販売し、ユーザへの販売後にはユーザが所有し続けることが想定される通信機器を示す。本実施形態においては、通信装置がレンタル機であるか否かの情報は、通信装置が持つメタ情報に含まれているとする。これ以外に、ユーザに何らかの特定の文字列を通信装置にインプットしてもらうことで判別する方法や、特定のアプリケーションが通信装置にインストールされているか否かをもとに判別するなどの方法で実現してもよい。

仲介サーバ１１１の通信装置情報管理モジュール３１２は、仲介サーバ１１１上に登録された通信装置情報を管理する。また、通信装置情報管理モジュール３１２は、通信装置１２１、１２２からの要求に従って、通信装置１２１、１２２の登録処理を行う。このように、通信装置情報管理モジュール３１２は、通信装置からデバイス情報を受信して管理するデバイス管理部として機能する。

表１は、通信装置１２１、１２２の情報を記憶する場合の、通信装置管理テーブルの例である。各通信装置は、通信装置を一意に識別するためのデバイスＩＤで管理される。表１の例では、通信装置１２１が、“ｄｅｖｉｃｅＡ”のデバイスＩＤを保持し、通信装置１２２が、”ｄｅｖｉｃｅＢ”というデバイスＩＤを保持しているとする。なお、表１では、２台の通信装置を管理していることを示すが、３台以上管理していてもよい。

表１において、通信装置１２１は、デバイスＩＤが“ｄｅｖｉｃｅＡ”として管理され、機種がレンタル機であり、使用開始時刻が“２０２０／５／２３ １７：０４”であり、自動削除判定が“オン”であることが特定できる。同様に、通信装置１２２は、デバイスＩＤが“ｄｅｖｉｃｅＢ”として管理され、機種が販売機であり、使用開始時刻が“２０２０／８／１ １５：００”であり、自動削除判定が“オフ”であることが特定できる。

図４は、第１実施形態に係る、通信装置登録フローを示す図であり、通信装置１２１が仲介サーバ１１１に対し通信装置登録リクエストを行うフローである。本フローは、通信装置情報管理モジュール３１２が、通信装置１２１、１２２のいずれかから通信装置登録リクエストを受け付けることで開始される。以下の説明では、前記リクエストを送信したのは通信装置１２１であるとして説明する。

ステップＳ４０１で、通信装置情報管理モジュール３１２は、通信装置１２１から通信装置登録リクエストを受け取る。通信装置登録リクエストには、通信装置１２１のデバイスＩＤや、機種情報などのメタ情報が含まれる。通信装置情報管理モジュール３１２は、受け取った情報からデバイスＩＤである”ｄｅｖｉｃｅＡ”を取得し、通信装置管理テーブルへデバイスＩＤを登録する。

ステップＳ４０２で、通信装置情報管理モジュール３１２は、ステップＳ４０１で受信した通信装置１２１の機種情報を通信装置情報判別モジュール３１１に送信し、通信装置１２１の機種を特定する。通信装置情報判別モジュール３１１への問い合わせの結果、通信装置１２１がレンタル機であると判別された場合は、ステップＳ４０３へ遷移し、販売機であると判別された場合は、ステップＳ４０６へ遷移する。このように、通信装置情報判別モジュール３１１は、通信装置１２１が、レンタル機か否かを判定するデバイス判別部として機能する。

ステップＳ４０３で、通信装置情報管理モジュール３１２は、通信装置管理テーブルに登録されている”ｄｅｖｉｃｅＡ”のレコードに対し、機種が“レンタル機”である情報を書き込む。

ステップＳ４０４で、通信装置情報管理モジュール３１２は、通信装置管理テーブルに登録されている”ｄｅｖｉｃｅＡ”のレコードに対し、自動削除判定が“オン”である情報を書き込む。

ステップＳ４０５で、通信装置情報管理モジュール３１２は、通信装置管理テーブルに登録されている”ｄｅｖｉｃｅＡ”のレコードに対し、使用開始時刻に現在の日時を記録し、フローが終了する。

ステップＳ４０６で、通信装置情報管理モジュール３１２は、通信装置管理テーブルに登録されている”ｄｅｖｉｃｅＡ”のレコードに対し、機種が“販売機”である情報を書き込む。

ステップＳ４０７で、通信装置情報管理モジュール３１２は、通信装置管理テーブルに登録されている”ｄｅｖｉｃｅＡ”のレコードに対し、自動削除判定が“オフ”である情報を書き込み、ステップＳ４０５へ遷移する。ステップＳ４０５の処理を実行した後、フローが終了する。

仲介サーバ１１１のサービス登録モジュール３１３は、通信装置１２１、１２２からのサービス登録要求を受け付ける。そして、サービス登録モジュール３１３は、サービス提供サーバ１３１、１３２が提供する認可エンドポイントと認可リクエストを通信装置１２１、１２２に対して返却する。また、サービス登録モジュール３１３は、認可処理を終えた通信装置１２１、１２２から認可レスポンスを取得し、サービス提供サーバ１３１、１３２に対してアクセストークンの発行を要求する。取得したアクセストークンをアクセストークン管理モジュール３１５へ送信し、ユーザ情報及びサービス情報と紐付けて保存する。このように、サービス登録モジュール３１３は、サービス提供サーバ１３１からサービスの提供用の認可情報を取得する認可情報取得部として機能する。

表２は、サービス識別子と、サービスが提供するエンドポイントを記憶するためのサービス情報テーブルである。

表２から、サービス識別子”ｓｅｒｖｉｃｅＡ”に対応するサービスは、認可エンドポイントとして、“ｈｔｔｐｓ：／／ａａａ／ａｕｔｈｚ”を持つことが特定できる。また、サービス識別子”ｓｅｒｖｉｃｅＡ”に対応するサービスは、トークンエンドポイントとして、“ｈｔｔｐｓ：／／ａａａ／ｔｏｋｅｎ”を持つことが特定できる。

仲介サーバ１１１のユーザ情報管理モジュール３１４は、仲介サーバ１１１上に登録されたユーザ情報を管理し、通信装置１２１、１２２からの要求に従ってユーザ情報を登録する。ユーザ情報管理モジュール３１４は、アクセストークン管理モジュール３１５とともに、通信装置を使用するユーザに関するユーザ情報と、認可情報と、デバイス情報とを関連付けて管理するユーザ情報管理部として機能する。

表３は、ユーザとユーザが使用している通信装置の情報を記憶するユーザ情報管理テーブルの例である。各ユーザは、ユーザを一意に識別するためのユーザＩＤで管理される。表３では、３人のユーザを管理していることを示すが、３人以上管理していてもよい。

表３から、例えば、ユーザＩＤ“ｕｓｅｒＡ”に対応するユーザは、“ｄｅｖｉｃｅＡ”で表される通信装置で使用されているユーザであることが特定できる。パスワードは、ユーザが自身の情報を仲介サーバ１１１上に登録する際に保存した秘匿情報である。パスワードをユーザＩＤと合致させることで、ユーザ認証を行うことができる。

仲介サーバ１１１のアクセストークン管理モジュール３１５は、サービス提供サーバ１３１、１３２から取得したアクセストークン及びリフレッシュトークンを登録する。また、アクセストークン及びリフレッシュトークンを登録する際、アクセストークン及びリフレッシュトークンは、ユーザ情報管理テーブルに記録されているユーザ情報と紐付けて登録される。また、アクセストークン管理モジュール３１５は、後述するトークン自動削除処理を行う。

表４は、ユーザが使用しているサービスと、前記サービスに対応するサービス提供サーバが発行するアクセストークンとリフレッシュトークンを管理するアクセストークン管理テーブルの例である。ユーザが使用する各サービスは、サービスを一意に識別するためのサービス識別子で管理される。表４の例では、サービス提供サーバ１３１が提供するサービスに対して“ｓｅｒｖｉｃｅＡ”が割り当てられられる。また、サービス提供サーバ１３２が提供するサービスに対して、“ｓｅｒｖｉｃｅＢ”というサービス識別子が割り当てられる。

表４から、ユーザＩＤ“ｕｓｅｒＡ”に対応するサービス識別子は、”ｓｅｒｖｉｃｅＡ”と”ｓｅｒｖｉｃｅＢ”であることが特定できる。また、ユーザＩＤが“ｕｓｅｒＡ”であり且つサービス識別子が”ｓｅｒｖｉｃｅＡ”である場合のアクセストークンは、”ａａａａ”であり、リフレッシュトークンは、“ＡＡＡＡ”であることが特定できる。また、また、ユーザＩＤが“ｕｓｅｒＡ”であり且つサービス識別子が”ｓｅｒｖｉｃｅＢ”である場合のアクセストークンは、”ｂｂｂｂ”であり、リフレッシュトークンは、“ＢＢＢＢ”であることが特定できる。

通信装置１２１、１２２のサービス連携モジュール３２１は、仲介サーバ１１１に対し、サービス提供サーバ１３１、１３２が提供するサービスの登録要求を行う。また、サービス連携モジュール３２１は、サービス提供サーバ１３１、１３２との間で認可処理による権限委譲のやりとりを行う。サービス連携モジュール３２１は、認可処理に必要なＷｅｂブラウザ機能を備える。Ｗｅｂブラウザ機能により、仲介サーバ１１１及びサービス提供サーバ１３１、１３２から取得した静的なコンテンツ（ＨＴＭＬページ）は、通信装置１２１、１２２のディスプレイに表示される。

通信装置１２１、１２２のサービス管理モジュール３２２は、仲介サーバ１１１に登録されているユーザ情報と、ユーザが使用しているサービスおよびサービスが発行しているアクセストークンを取得し、管理する。

表５は、ユーザ情報とサービス情報を紐付けて保存するサービス管理テーブルの一例である。

表５では、ユーザＩＤ“ｕｓｅｒＡ”に対応するサービス識別子は”ｓｅｒｖｉｃｅＡ”と”ｓｅｒｖｉｃｅＢ”であることが特定できる。また、ユーザＩＤが“ｕｓｅｒＡ”であり且つサービス識別子が”ｓｅｒｖｉｃｅＡ”である場合のアクセストークンは、”ａａａａ”であることが特定できる。また、ユーザＩＤが“ｕｓｅｒＡ”であり且つサービス識別子が”ｓｅｒｖｉｃｅＢ”である場合のアクセストークンは、”ｂｂｂｂ”であることが特定できる。サービス管理テーブルに保存される情報は、仲介サーバ１１１のアクセストークン管理テーブルに記録されている情報を取得して保存される。

通信装置１２１、１２２のアップロード機能モジュール３２３は、通信装置１２１、１２２の内部ストレージに保存されたデータを、外部ストレージにアップロードする。本実施形態においては、サービス提供サーバ１３１のストレージ機能を使用するものとする。

サービス提供サーバ１３１、１３２の認可処理モジュール３３１は、認可のためのエンドポイントを提供し、通信装置１２１、１２２からの認可リクエストを受けて、仲介サーバ１１１への権限委譲の処理を行う。

サービス提供サーバ１３１、１３２のアクセストークン発行モジュール３３２は、アクセストークン取得のためのエンドポイントを提供する。また、アクセストークン発行モジュール３３２は、仲介サーバ１１１からのトークンリクエストを受けて、アクセストークン及びリフレッシュトークンを発行する。アクセストークン発行モジュール３３２は、トークンリクエストに対して、ユーザからの権限委譲を受けたことの証左となる認可コードを含めることで、アクセストークンを発行する。また、リフレッシュトークンとサービス提供サーバ１３１、１３２が予め仲介サーバ１１１に対して発行しているクライアントクレデンシャルをトークンリクエストに含めることで、アクセストークンを発行する。

サービス提供サーバ１３１、１３２のサービス提供モジュール３３３は、各サービス提供サーバが提供するリソースやＡＰＩを利用するためのエンドポイントを提供している。ここで、ＡＰＩとは、Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅの略語である。アクセストークンを所有している通信装置１２１、１２２又は仲介サーバ１１１が、前記エンドポイントに対してアクセストークンを含めてリクエストを送る。これにより、サービス提供サーバ１３１、１３２が提供する機能を利用することができる。本実施形態において、サービス提供サーバ１３１は、外部からのリクエストを受けて、サービス提供サーバ１３１の内部ストレージにデータを格納するストレージ機能を提供していることとする。

図５は、第１実施形態に係る、サービス登録フローを示す図であり、通信装置１２１が仲介サーバ１１１に対し、サービス提供サーバ１３１が提供するサービスの登録リクエストを行うフローである。なお、通信装置１２１とサービス提供サーバ１３１をそれぞれ通信装置１２２、サービス提供サーバ１３２に置き換えた場合も同様のフローとなる。

ステップＳ５０１で、サービス連携モジュール３２１が提供するユーザインタフェースをユーザが操作することにより、本フローは、開始する。図７は、第１実施形態に係る、サービス登録画面を示す図であり、図７（Ａ）は、サービス連携モジュール３２１が提供する画面７０１の一例である。ユーザは、画面７０１に表示されているサービス登録ボタンを押下することで、サービス登録のフローを開始することができる。

ステップＳ５０２で、サービス連携モジュール３２１は、サービス登録モジュール３１３が提供するサービス登録エンドポイントへサービス登録開始リクエストを送信する。

ステップＳ５０３で、サービス登録モジュール３１３は、通信装置１２１に対し、ユーザログインのためのログイン画面７０２のＨＴＭＬページを送信する。図７（Ｂ）は、サービス登録モジュール３１３が提供するログイン画面７０２の一例である。ここで、ユーザが既に仲介サーバ１１１に対してユーザ登録を行っている場合は、ステップＳ５０４へ遷移し、ユーザ未登録であれば、ステップＳ５０７へ遷移する。

ステップＳ５０４〜ステップＳ５０６は、ユーザが既に仲介サーバ１１１に対してユーザ登録を行っている場合のログインフローである。

ステップＳ５０４で、ユーザは、自身のユーザＩＤとパスワードをログイン画面７０２に入力する。そして、ユーザは、ログイン画面７０２のログインボタンを押下する。

ステップＳ５０５で、ユーザからの入力を受けたサービス登録モジュール３１３は、仲介サーバ１１１に対して、入力されたユーザＩＤとパスワードを送信する。

ステップＳ５０６で、ユーザＩＤとパスワードを受け取ったサービス登録モジュール３１３は、ユーザ情報管理モジュール３１４へと問合せ、ユーザの認証を行う。ユーザ情報管理モジュール３１４は、ユーザ情報管理テーブルに登録されているユーザＩＤとパスワードを受け取った情報と照合する。そして、ユーザ情報管理モジュール３１４は、一致するユーザが存在すれば、サービス登録モジュール３１３に対して認証成功のレスポンスを返す。なお、一致するユーザが存在しない場合は、ユーザ情報管理モジュール３１４は、認証失敗のレスポンスを返す。この場合、サービス登録モジュール３１３は、通信装置１２１に対し、ログイン失敗のエラー画面（不図示）を送信する。

ステップＳ５０７〜ステップＳ５１２は、ユーザが仲介サーバ１１１に対してユーザ登録を行っていない場合のログインフローである。ステップＳ５０７で、ユーザは、ログイン画面７０２のユーザ登録ボタンを押下する。

ステップＳ５０８で、ユーザからの入力を受けたサービス連携モジュール３２１は、仲介サーバ１１１に対してユーザ登録リクエストを送信する。

ステップＳ５０９で、ユーザ登録リクエストを受け取ったサービス連携モジュール３２１は、通信装置１２１に対してユーザ登録画面のＨＴＭＬページを返却する。図７（Ｃ）は、サービス連携モジュール３２１が提供するサービス登録モジュール３１３が提供するユーザ登録画面７０３の一例である。ユーザ登録画面７０３のＨＴＭＬページを受け取ったサービス連携モジュール３２１は、通信装置１２１のディスプレイにユーザ登録画面７０３を表示する。

ステップＳ５１０で、ユーザは表示されたユーザ登録画面に登録したいユーザＩＤとパスワードを入力し、登録ボタンを押下する。

ステップＳ５１１で、ユーザからの入力を受けたサービス連携モジュール３２１は、入力されたユーザＩＤとパスワード、デバイスＩＤを仲介サーバ１１１へ送信する。

ステップＳ５１２で、ユーザＩＤとパスワードを受信したサービス登録モジュール３１３は、ユーザ情報管理モジュール３１４へユーザＩＤとパスワードを送信する。ユーザＩＤとパスワードを受け取ったユーザ情報管理モジュール３１４は、ユーザ情報管理テーブルにユーザＩＤ、パスワード、デバイスＩＤを登録する。

ステップＳ５１３で、サービス登録モジュール３１３は、通信装置１２１に対してユーザの認証、もしくは登録が成功した旨とサービス登録画面のＨＴＭＬページを送信する。図７（Ｄ）は、サービス登録モジュール３１３が提供するサービス登録画面７０４の一例である。サービス登録画面７０４のＨＴＭＬページを受け取ったサービス連携モジュール３２１は、サービス登録画面を通信装置１２１の画面に表示する。

ステップＳ５１６で、ユーザは、表示されたサービス登録画面７０４から登録したいサービスを選択する。本フローでは、サービス提供サーバ１３１が提供するサービスを選択したものとする。

ステップＳ５１７で、ユーザからの入力を受けたサービス連携モジュール３２１は、仲介サーバ１１１に対して選択されたサービスの登録リクエストを開始する。サービス登録モジュール３１３がサービス登録リクエストを受信したことで、サービス提供サーバ１３１に対する認可処理が行われる。

認可処理に関しては図６を用いて後述する。図６の認可処理では、ユーザとサービス提供サーバ１３１の間で仲介サーバ１１１に対する権限委譲の対話が行われる。この対話の結果により、サービス提供サーバ１３１から仲介サーバ１１１に対してユーザが権限委譲を行った証左となる認可コードが送信される。

ステップＳ５１８で、サービス登録モジュール３１３は、受け取った認可コードとともにアクセストークンを発行するためのトークンリクエストを送信する。ここで、トークンリクエストは、アクセストークン発行モジュール３３２が提供するトークンエンドポイントに送信される。

ステップＳ５１９で、トークンリクエストを受信したアクセストークン発行モジュール３３２は、受信した認可コードが正しいか否かの検証を行う。検証に成功した場合、認可コードに紐付くリソースのアクセスを許可するアクセストークンと、アクセストークンを更新するためのリフレッシュトークンを発行し、仲介サーバ１１１に返却する。

ステップＳ５２０で、サービス登録モジュール３１３は、アクセストークン管理モジュール３１５に対し、受信したトークン等の情報を送信する。この情報は、受信したアクセストークンとリフレッシュトークン、アクセストークンのリソース所有者であるユーザのＩＤ、サービス提供サーバ１３１のサービスＩＤである。アクセストークン管理モジュール３１５は、受信した情報をアクセストークン管理テーブルに保存する。

ステップＳ５２１で、サービス登録モジュール３１３は、通信装置１２１に対し、ユーザ登録完了画面のＨＴＭＬページを送信する。図７（Ｅ）は、サービス登録モジュール３１３が提供するサービス登録完了画面７０５の一例である。サービス連携モジュール３２１は、受信したページ、を通信装置１２１の画面に表示し、フローが終了する。

図６は、第１実施形態に係る、認可フローを示す図であり、ユーザ、通信装置１２１、仲介サーバ１１１、サービス提供サーバ１３１の間で行われる権限委譲処理を表したフローである。本フローは、ステップＳ５１７で、サービス連携モジュール３２１が仲介サーバ１１１に対してサービス登録リクエストを送信したことで開始される。

ステップＳ６０１で、まず、サービス登録モジュール３１３は、サービス登録リクエストを受信する。サービス登録モジュール３１３は、サービス登録リクエストに含まれるサービス識別子を用いて、サービス情報テーブルに登録されているサービスから、サービス提供サーバ１３１の認可エンドポイントを取得する。次に、サービス登録モジュール３１３は、認可リクエストのフォーマットに従って認可リクエストを生成する。認可リクエストには、仲介サーバ１１１の情報、後述するリダイレクト先のＵＲＬ、権限委譲してほしいリソースの情報などを含める。サービス登録モジュール３１３は、サービス提供サーバ１３１の認可エンドポイントのＵＲＬと前記認可リクエストを連結したパラメータ付ＵＲＬを、通信装置１２１に対して返却する。こうして、サービス登録モジュール３１３は、通信装置１２１に対し、前記パラメータ付ＵＲＬに対しリダイレクトするよう指示する。

ステップＳ６０２で、サービス連携モジュール３２１は、受信したパラメータ付ＵＲＬに接続する。

ステップＳ６０３で、認可処理モジュール３３１は、通信装置１２１から受信した認可リクエストを受けて、通信装置１２１に対してユーザ認証画面のＨＴＭＬページを送信する。図７（Ｆ）は、認可処理モジュール３３１が提供するユーザ認証画面７０６の一例である。ユーザ認証画面７０６を受信したサービス連携モジュール３２１は、通信装置１２１の画面にユーザ認証画面を表示する。

ステップＳ６０４で、ユーザは、ユーザ認証画面にユーザ認証に必要なＩＤとパスワードを入力する。ここで、必要なユーザＩＤとパスワードは、ユーザ情報管理モジュール３１４の登録されているユーザ情報とは異なり、ユーザがサービス提供サーバ１３１に対して予め登録していたアカウントユーザＩＤとパスワードとなる。

ステップＳ６０５で、サービス連携モジュール３２１は、ユーザが入力したユーザＩＤとパスワードをサービス提供サーバ１３１に送信する。

ステップＳ６０６で、認可処理モジュール３３１は、受信したユーザＩＤとパスワードが、サービス提供サーバ１３１に登録されているユーザ情報と一致するか否かの認証を行う。

ステップＳ６０７で、認可処理モジュール３３１は、通信装置１２１に対して、同意画面のＨＴＭＬページを送信する。図７（Ｇ）は、認可処理モジュール３３１が提供する同意画面７０７の一例である。同意画面７０７を受信したサービス連携モジュール３２１は、通信装置１２１の画面に、同意画面を表示する。同意画面７０７には、認可リクエストに含まれる仲介サーバ１１１の情報と、仲介サーバ１１１がアクセスしたいリソースの情報が含まれる。ユーザは、仲介サーバ１１１に対して前記リソースのアクセスを許可する場合は、同意画面７０７の同意ボタン（許可ボタン）を押下し、拒否する場合には、拒否ボタンを押下する。

ステップＳ６０８で、ユーザは、仲介サーバ１１１に対して、リソースにアクセスすることを許可するために、同意画面７０７の同意ボタンを押下する。

ステップＳ６０９で、通信装置１２１の画面に表示された同意画面から、サービス提供サーバ１３１に対して認可の同意情報が送信される。

ステップＳ６１０で、同意情報を取得した認可処理モジュール３３１は、ユーザが仲介サーバ１１１からのリソースへのアクセス許可に同意したことを示す認可コードを発行する。ステップＳ６０１で認可リクエストに含まれたリダイレクト先のＵＲＬと認可コードを連結し、通信装置１２１へ返却する。この時、通信装置１２１に対して即座に返却したＵＲＬへ接続するよう指示する。

ステップＳ６１１で、サービス連携モジュール３２１は、認可処理モジュール３３１から受け取ったＵＲＬへとアクセスする。前記ＵＲＬは、サービス登録モジュール３１３が発行したＵＲＬである。サービス登録モジュール３１３は、ＵＲＬに連結された認可コードを受け取ることができる。サービス登録モジュール３１３は、受け取った認可コードを、ＲＯＭ２０３のデータＲＯＭに保存し、本フローが終了する。

図８は、第１実施形態に係る、サービス利用フローを示す図であり、通信装置１２１が、仲介サーバ１１１に保存されているアクセストークンを用いて、サービス提供サーバ１３１が提供するサービスを、利用するフローである。本フローは、ユーザが通信装置１２１の画面に表示されるユーザインタフェースを操作することで開始される。本フローでは、画面７０１上の「アップロード」機能ボタンを押下することで、通信装置１２１内のアップロード機能モジュール３２３が、サービス提供サーバ１３１のサービスを利用する例を説明する。

ステップＳ８０１で、ユーザは、通信装置１２１の画面７０１に表示されているアップロードボタンを押下する。

ステップＳ８０２で、アップロード機能モジュール３２３は、サービス提供サーバ１３１のアクセストークンを要求する。これは、アップロード機能モジュール３２３が、通信装置１２１の内部ストレージに保存されたデータを、サービス提供サーバ１３１にアップロードするために行われる。

ステップＳ５０３〜ステップＳ５０６で、仲介サーバ１１１上に保存されているユーザ情報に対して認証処理を行う。詳細は前述のステップＳ５０３からステップＳ５０６の説明と同様なので割愛する。

ステップＳ５０６で、認証処理を終え、認証成功のレスポンスを受け取ったアップロード機能モジュール３２３は、ステップＳ８０３で、アクセストークンを取得する。具体的には、アップロード機能モジュール３２３は、仲介サーバ１１１上のアクセストークン管理テーブルに保存されている、前記ログインユーザに紐付けられている”ｓｅｒｖｉｃｅＡ”のアクセストークンを取得する。

ステップＳ８０４で、アップロード機能モジュール３２３は、取得したアクセストークンを用いて、サービス提供モジュール３３３に対して画像アップロードＵＲＬを要求する。

ステップＳ８０５で、サービス提供モジュール３３３は、受け取ったアクセストークンを検証し、検証に成功するとアップロードＵＲＬを返却する。

ステップＳ８０６で、アップロード機能モジュール３２３は、受け取ったアップロードＵＲＬに対し、通信装置１２１の内部ストレージからデータを送信し、フローが終了する。

このように、仲介サーバ１１１が取得、管理しているアクセストークンを通信装置１２１へと渡すことで、通信装置１２１は、サービス提供サーバ１３１の機能を使用することが可能となる。

図９は、第１実施形態に係る、認可情報自動削除フローを示す図であり、アクセストークン管理モジュール３１５が、アクセストークン管理テーブルに保存されているアクセストークンを自動削除処理をするフローである。この処理は、ある一定の間隔で定期的に実行される。このため、本フローは、スケジューリングされたイベントを受けて、開始される。

ステップＳ９０１で、アクセストークン管理モジュール３１５は、通信装置情報管理モジュール３１２に対して、通信装置管理テーブルに保存されている通信装置情報を取得するよう要求する。取得した通信装置情報の中で、自動削除設定がオンになっている通信装置が存在するか確認する。１つでも存在する場合はステップＳ９０２へ、１つも存在しない場合は、本フローが終了する。

ステップＳ９０２で、アクセストークン管理モジュール３１５は、ステップＳ９０１で取得した自動削除対象通信装置が、使用開始時刻から現在時刻の間までに一定期間経過しているか否かを判定する。ここで一定期間とは、レンタル機の貸与期間より少し多めの時刻を設定する。例えば、貸与期間が２週間であれば、貸与期間よりも長く設定された１月程度の期間を一定期間であると想定する。使用開始から一定期間経過している自動削除対象通信装置が１つでも存在する場合は、ステップＳ９０３へ、１つも存在しない場合は、本フローが終了する。なお、使用開始の基準となるタイミングは、必ずしも開始時刻ではなく、開始日等、他のタイミングでもよい。

ステップＳ９０３で、アクセストークン管理モジュール３１５は、前ステップまでに取得した通信装置情報から削除対象のアクセストークンの特定を行う。アクセストークン管理モジュール３１５は、ユーザ情報管理モジュール３１４に対して、前記自動削除対象通信装置と紐付けられたユーザ一覧を取得するよう要求する。アクセストークン管理テーブルに保存されているアクセストークン情報の中で、取得したユーザと紐付けられているアクセストークン情報を削除対象として決定する。以下、ステップＳ９０４、ステップＳ９０５を全ての削除対象アクセストークンに対して繰り返し行う。

ステップＳ９０４で、アクセストークン管理モジュール３１５は、削除対象のアクセストークンを用いて、認可処理モジュール３３１が提供する認可無効化エンドポイントに無効化リクエストを送信する。無効化リクエストを受けた認可処理モジュール３３１は、アクセストークンに紐付けられたユーザが仲介サーバ１１１に対して権限委譲の情報を削除し、新規にアクセストークンが発行できないように無効化する。

ステップＳ９０５で、アクセストークン管理モジュール３１５は、削除対象のアクセストークンに係る情報をアクセストークン管理テーブルから削除する。

ステップＳ９０６で、全ての削除対象アクセストークンに対してステップＳ９０４、ステップＳ９０５が終了したことをもって、本フローが終了する。

第１実施形態によれば、レンタル機として登録され、予め一定期間でユーザが使用を中止するとわかっている通信装置に対して、使用開始からの期限を確認し、係る認可情報を自動的に無効化及び削除できるようにする。これにより、通信装置を使用するユーザが認可情報を無効化及び削除せずに通信装置を手放した場合にも、認可情報を適切に無効化及び削除することが可能となる。

［第２実施形態］
以下、本発明の第２実施形態について図面を用いて説明する。上記第１実施形態において、レンタル機として仲介サーバ１１１に登録された通信装置に関する認可情報は、一定期間経過した後に全て自動的に削除していた。第２実施形態では、レンタル機を使用していたユーザが、販売機に買い替えることで、通信装置の置き換えを行った場合、ユーザが使用していたレンタル機で登録された認可情報を自動削除しないようにする実施形態を説明する。

図１０は、第２実施形態に係る、通信装置登録フローを示す図であり、通信装置１２１が、仲介サーバ１１１に対し通信装置登録リクエストを行うフローである。本フローは、通信装置情報管理モジュール３１２が、通信装置情報管理テーブルに未登録の通信装置から通信装置登録リクエストを受け付けることで開始される。なお、既に説明済みのステップＳ４０１からステップＳ４０５に関しては説明を省略もしくは簡略化する。

ステップＳ４０１〜ステップ４０２までは図４での説明と同様の遷移となる。ステップＳ４０２で、登録リクエストを送信した通信装置がレンタル機であると判断された場合は、ステップＳ４０３へ遷移し、レンタル機ではないと判断された場合は、ステップＳ１００１へ遷移する。

ステップＳ１００１で、通信装置情報管理モジュール３１２は、通信装置登録リクエストを送信した通信装置が、通信装置情報管理テーブルに登録済みのレンタル機からの置き換え機（置換デバイス）であるか否かを判定する。置き換えか否かの判定は、通信装置登録リクエストに含まれるデバイスＩＤが、通信装置情報管理テーブルに登録されており、且つ、当該デバイスＩＤがレンタル機のものである場合に、置き換えであると判断する。置き換えであると判断された場合は、ステップＳ１００２へ遷移し、置き換えではないと判断された場合は、ステップＳ１００３へ遷移する。

ステップＳ１００２で、通信装置情報管理モジュール３１２は、通信装置情報管理テーブルに登録されている置き換え対象通信装置の機種情報を「販売機」へ変更し、自動削除設定を「オフ」へと変更する。その後、ステップＳ４０５へ遷移する。

ステップＳ１００３で、通信装置情報管理モジュール３１２は、通信装置登録リクエストを送信した通信装置を、通信装置情報管理テーブルに新規に登録する。この時、機種情報は「販売機」となる。

ステップＳ１００４で、通信装置情報管理モジュール３１２は、ステップＳ１００３で登録した通信装置情報の自動削除設定をオフに設定し、ステップＳ４０５へ遷移する。

第２実施形態によれば、仲介サーバ１１１に対して登録される通信装置が通信装置情報管理テーブルに登録済みのレンタル機であった場合に、テーブルのレコードを更新し、自動削除設定をオフにする。これにより、元は自動削除対象の通信装置であっても、利用を継続しているユーザに対しては、認可情報を削除せずに、使用し続けることが可能となる。

［第３実施形態］
以下、本発明の第３実施形態について図面を用いて説明する。第１実施形態では、通信装置１２１、１２２からサービス提供サーバ１３１の提供するサービスを利用するために、通信装置内にアクセストークンを保持する構成となっている。ユーザからの通信装置の操作により、通信装置内のアクセストークンを削除するケースが考えられる。第３実施形態では、通信装置内に登録されたアクセストークンを削除すると同時に、仲介サーバ１１１上に登録されたアクセストークンを削除する実施形態について説明する。

図１１は、第３実施形態に係る、認可情報削除フローを示す図である。具体的には、アクセストークン管理モジュール３１５及びサービス管理モジュール３２２が、それぞれアクセストークン管理テーブルとサービス管理テーブルに登録されているアクセストークンを削除するフローである。

ステップＳ１１０１で、通信装置が提供するユーザインタフェースを操作することで、ユーザが保持するアクセストークンの削除要求を開始する。前記ユーザインタフェースは、サービス管理モジュール３２２が提供しても良いし、アップロード機能モジュール３２３やその他不図示の機能モジュールが提供していてもよい。サービス管理モジュール３２２以外のモジュールがユーザインタフェースを提供する場合、要求を受けたモジュールは、サービス管理モジュール３２２に対して削除開始リクエストを送信する。

ステップＳ１１０２で、トークン削除開始リクエストを受けたサービス管理モジュール３２２は、仲介サーバ１１１に対してユーザ認証のリクエストを送信する。以下、ステップＳ５０３〜ステップＳ５０６まで、ユーザ認証に係る処理を実行する。

ステップＳ１１０３で、ユーザ認証に成功した場合サービス管理モジュール３２２は、サービス管理テーブルに保存されている削除対象のアクセストークンを削除する。

ステップＳ１１０４で、サービス管理モジュール３２２は、仲介サーバ１１１に対して、ステップＳ１１０３で削除したアクセストークンと同一のアクセストークンを削除するよう、リクエストを送信する。リクエストを受けたアクセストークン管理モジュール３１５は、該当するアクセストークンが存在しない場合は、エラーレスポンスを返しフローを終了する。該当するアクセストークンが存在する場合は、ステップＳ９０４の認可情報の無効化処理を行った後に、ステップＳ９０５のアクセストークン削除処理を行い、成功レスポンスを返す。

第３実施形態によれば、ユーザからのアクセストークン削除リクエストを受けて、通信装置１２１と仲介サーバ１１１上に存在する同一のアクセストークンを合わせて削除することが可能となる。第１実施形態で記載したトークンの自動削除処理と合わせて、任意のタイミングでトークンを削除する機能を提供することで、より安全なシステムとなる。

以上、本発明をその好適な実施形態に基づいて詳述したが、本発明はこれら特定の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。また、上述の実施形態の一部を適宜組み合わせてもよい。

上述の実施形態では、通信装置の種類について、サービス提供期間が制限されている制限付きデバイスがレンタル機であるとして説明したが、これに限るものではなく、制限付きデバイスは、必ずしも貸与を伴うものでなくともよい。また、上述の実施形態では、サービス提供期間が制限されていないデバイスを販売機として説明したが、これに限るものではなく、必ずしもデバイスの販売を伴うものでなくともよい。また、置換デバイスを販売機であるとして説明したが、置換デバイスは、必ずしも販売を伴って利用可能となったものに限られない。

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

１１１…仲介サーバ
１２１…通信装置
１３１…サービス提供サーバ
３１１…通信装置情報判別モジュール
３１２…通信装置情報管理モジュール
３１３…サービス登録モジュール
３２１…サービス連携モジュール

Claims (7)

1. デバイスに対するサービスの提供を仲介するサーバ装置であって、
   前記サービスの提供用の認可情報を取得する認可情報取得部と、
   前記デバイスからデバイス情報を受信して管理するデバイス管理部と、
   前記デバイスを使用するユーザに関するユーザ情報と、前記認可情報と、前記デバイス情報とを関連付けて管理するユーザ情報管理部と、
   前記デバイスが、前記サービスのサービス提供期間が制限されている制限付きデバイスであるか否かを判定するデバイス判別部と、を有し、
   前記ユーザ情報管理部は、前記デバイスが前記制限付きデバイスであり且つ前記制限付きデバイスへの前記サービス提供期間の開始から一定期間が経過した場合に、前記デバイス情報に関連する前記認可情報の無効化及び削除を行う
   ことを特徴とするサーバ装置。
2. 前記デバイス判別部は、前記デバイスが前記制限付きデバイスから置き換わった置換デバイスであるかを判定し、
   前記ユーザ情報管理部は、前記デバイスが前記置換デバイスであった場合に、前記デバイス情報に関連する前記認可情報の前記無効化及び前記削除を行うことを中止する
   ことを特徴とする請求項１に記載のサーバ装置。
3. 前記ユーザ情報管理部は、前記デバイスから前記認可情報の前記無効化及び前記削除の要求を受けた場合、前記デバイス情報に関連する前記認可情報の前記無効化及び前記削除を行う
   ことを特徴とする請求項１又は２に記載のサーバ装置。
4. 前記制限付きデバイスは、貸与期間の間だけ前記ユーザへの貸与がなされる貸与デバイスであり、
   前記一定期間は、前記貸与期間よりも長く設定されている
   ことを特徴とする請求項１乃至３のいずれか１項に記載のサーバ装置。
5. デバイスと、前記デバイスに対してサービスの提供をさせるためのサーバ装置とを有するシステムであって、
   前記サーバ装置は、
   前記サービスの提供用の認可情報を取得する認可情報取得部と、
   前記デバイスからデバイス情報を受信して管理するデバイス管理部と、
   前記デバイスを使用するユーザに関するユーザ情報と、前記認可情報と、前記デバイス情報とを関連付けて管理するユーザ情報管理部と、
   前記デバイスが、前記サービスのサービス提供期間が制限されている制限付きデバイスであるか否かを判定するデバイス判別部と、を有し、
   前記ユーザ情報管理部は、前記デバイスが前記制限付きデバイスであり且つ前記制限付きデバイスへの前記サービス提供期間の開始から一定期間が経過した場合に、前記デバイス情報に関連する前記認可情報の無効化及び削除を行う
   ことを特徴とするシステム。
6. デバイスに対してサービスの提供をさせるためのサーバ装置の制御方法であって、
   前記サービスの提供用の認可情報を取得する工程と、
   前記デバイスからデバイス情報を受信して管理する工程と、
   前記デバイスを使用するユーザに関するユーザ情報と、前記認可情報と、前記デバイス情報とを関連付けて管理する工程と、
   前記デバイスが、前記サービスのサービス提供期間が制限されている制限付きデバイスであるか否かを判定する工程と、
   前記デバイスが前記制限付きデバイスであり且つ前記制限付きデバイスへの前記サービス提供期間の開始から一定期間が経過した場合に、前記デバイス情報に関連する前記認可情報の無効化及び削除を行う工程と、を有する
   ことを特徴とする制御方法。
7. コンピュータに請求項６に記載の制御方法を実行させることを特徴とするプログラム。
   
   

Images