情報処理装置及びプログラム
【課題】ＷＳＤＬファイルの流出が生じた場合に、その流出元を特定可能な情報処理技術を提供する。
【解決手段】各種ＡＰＩを提供する情報処理装置は、アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬファイルをアプリケーションプログラム毎に記憶し、アプリケーションプログラムの開発者を特定する開発者情報を記憶し、アプリケーションプログラムに対して、当該アプリケーションプログラムに対応するＷＳＤＬファイルを公開し、Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信し、第１のアプリケーションプログラムに対応する第１のＷＳＤＬファイルに第１のＡＰＩの前記定義情報が示されるか否かを判定し、開発者情報を用いて、第１のＷＳＤＬファイルの流出の有無を判定する。
【解決手段】各種ＡＰＩを提供する情報処理装置は、アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬファイルをアプリケーションプログラム毎に記憶し、アプリケーションプログラムの開発者を特定する開発者情報を記憶し、アプリケーションプログラムに対して、当該アプリケーションプログラムに対応するＷＳＤＬファイルを公開し、Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信し、第１のアプリケーションプログラムに対応する第１のＷＳＤＬファイルに第１のＡＰＩの前記定義情報が示されるか否かを判定し、開発者情報を用いて、第１のＷＳＤＬファイルの流出の有無を判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
同系統のアプリケーションプログラムを複数開発したり運用したりするために、アプリケーションプログラムの開発や運用をサポートするためのプラットフォームを用意する環境を想定する。プラットフォームは、１つの情報処理システムであり、複数の情報処理装置が連携することで、アプリケーションプログラムの開発や運用をサポートするための機能をアプリケーションプログラムに提供する。例えば、アプリケーションプログラムとして、携帯端末で実行されるゲームプログラム（単にゲームという）の開発や運用をサポートするプラットフォームがある。各ゲームにおいて、ゲームを利用するユーザ情報を管理することは重要な機能である。この場合、ユーザ情報を管理する機能（ユーザ情報管理機能という）をプラットフォームが提供することで、ゲーム開発者は、同様の機能を実現するためのプログラムを開発する必要がなくなる。また、データベースにアクセスする機能（データベース機能という）をプラットフォームがゲームに提供することで、ゲームに必要なデータをプラットフォームに格納できるようになり、ゲーム開発者はゲーム運用コストを削減することができる。
【０００３】
ゲーム開発者は多数存在するため、また、ゲーム開発者とプラットフォーム開発者とは必ずしも一致しないため、プラットフォームと各ゲームとは物理的に別の情報処理装置上で運用されることを想定するべきである。従って、上述のユーザ情報管理機能やデータベース機能は、ネットワークを介して利用できる必要がある。ネットワークを介して機能を利用する方法として、Ｗｅｂサービスがある。プラットフォームは、Ｗｅｂサービスを介してユーザ管理機能やデータベース機能を利用するためのＡＰＩ（Application Programming Interface）であるＷｅｂサービスＡＰＩを定義し、公開する。各ゲームは公開されたＷｅｂサービスＡＰＩを利用することで、ネットワークを介して機能利用することができる。ＷｅｂサービスＡＰＩの定義情報（ＡＰＩの名称、引数、返り値）やサービス公開アドレスは、ＷＳＤＬ（Web Service Description Language）ファイルに記述される。ＷＳＤＬは、ＡＰＩの定義情報やサービス公開アドレスを明確且つ厳密に定義できるため、開発効率や相互接続性を高めることができる。例えば、ＷＳＤＬファイルがあれば、ＷｅｂサービスＡＰＩを利用するためのメッセージの送受信を行うプログラムを自動的に作成することができる。
【０００４】
プラットフォームは、ユーザ管理機能やデータベース機能等の基本的な機能を利用するためのＷｅｂサービスＡＰＩ（基本ＡＰＩという）とは別に、特別なＷｅｂサービスＡＰＩ（特別ＡＰＩという）を用意することで収入を得ることができる。例えば、高速なデータベースアクセスが可能なＡＰＩや、プラットフォーム側で蓄積したユーザのゲーム利用実績に関する統計データにアクセス可能なＡＰＩ等を特別ＡＰＩとして用意し、その利用に対して課金することができる。ゲームの品質向上や、統計データを利用したゲーム開発を目指すゲーム開発者は、特別ＡＰＩの利用に関してプラットフォーム開発者と契約を交わし、使用料を支払って、特別ＡＰＩを利用する。このとき、プラットフォームとしては、契約を交わしたゲーム開発者にのみ、特別ＡＰＩの定義情報を公開したい。なぜなら、契約を交わしていないゲーム開発者に対して、特別ＡＰＩの定義情報を公開することで、２つの不利益が生じるためである。１つは、契約を交わしていないゲーム開発者が開発したゲームにより、特別ＡＰＩに対するアクセスが生じると、プラットフォームに余分な処理負荷が生じることである。１つは、ＡＰＩの定義情報から、プラットフォーム側がどのようなデータを蓄積しているかを知られてしまうことである。例えば、プラットフォームが統計データを蓄積していることや、統計データとして全ユーザのゲーム使用時間合計等の情報があることを知られてしまう恐れがある。つまり、ＷＳＤＬの明確さや厳密さが仇となってしまう恐れがある。
【０００５】
この不利益を回避するために、ゲーム毎に、そのゲームに対して利用が許可されたＡＰＩのみの定義情報を記述したＷＳＤＬファイルを作成する技術がある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−９２４０７号公報
【特許文献２】特開２００５−７８３３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ゲーム毎にＷＳＤＬファイルを作成して限定公開する場合、各ゲーム開発者が、ＷＳＤＬファイルを二次公開することや、ＷＳＤＬファイルを流出することを許してはならない。それを許せば、上述の不利益を回避できない恐れがあるからである。従って、プラットフォームには、ＷＳＤＬファイルの二次公開や流出が生じた場合に、その流出元を特定できる仕組みが望まれている。流出元を特定できる仕組みは、ＷＳＤＬの流出に対する抑止力となるからである。また、流出元に対して責任を問うこともできるからである。しかしながら、従来の技術では、ＷＳＤＬファイルの流出が生じる状況を想定されておらず、ＷＳＤＬファイルの流出が生じた場合に、その流出元を特定することが困難であった。
【０００８】
本発明は、上記に鑑みてなされたものであって、ＷＳＤＬファイルの流出が生じた場合に、その流出元を特定可能な情報処理装置及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
実施形態の情報処理装置は、アプリケーションプログラムによって各種機能を実現させるために利用される各種ＡＰＩ（Application Programming Interface）を提供する情報処理装置であって、アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に記憶する第１記憶部と、前記アプリケーションプログラムの開発者を特定する開発者情報を記憶する第２記憶部と、前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開する公開部と、Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信する受信部と、前記第１記憶部に記憶された前記ＷＳＤＬファイルのうち、前記第１のアプリケーションプログラムに対応する第１のＷＳＤＬファイルに前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する第１判定部と、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合、前記第２記憶部に記憶された前記開発者情報を用いて、前記第１のＷＳＤＬファイルの流出の有無を判定する第２判定部とを備える。
【図面の簡単な説明】
【００１０】
【図１】第１の実施の形態の情報処理システムの構成を例示する図。
【図２】ＡＰＩ公開装置２０の機能的構成を例示する図。
【図３】契約時の業務フローを示す図。
【図４】ＷＳＤＬファイルを公開する処理の手順を示すフローチャート。
【図５】ゲーム認証処理の手順を示すフローチャート。
【図６】ＡＰＩ公開装置２０が起動時に行う初期化処理を示すフローチャート。
【図７】ＡＰＩ利用要求リクエストに対する処理の手順を示すフローチャート。
【図８】第２の実施の形態のＡＰＩ公開装置２０の機能的構成を例示する図。
【図９】契約時の業務フローを示す図。
【図１０】ＷＳＤＬファイルを公開する処理の手順を示すフローチャート。
【図１１】ＡＰＩ公開装置２０が起動時に行う初期化処理を示すフローチャート。
【図１２】ＡＰＩ利用要求リクエストに対する処理の手順を示すフローチャート。
【発明を実施するための形態】
【００１１】
［第１の実施形態］
図１は、本実施の形態に係る情報処理システムの構成を例示する図である。本実施の形態では、１つのプラットフォーム１０を有する情報処理システムに、アプリケーションプログラムとして各々ゲームＡ，Ｂ，Ｃを各々開発する各情報処理装置（ゲーム開発装置という）がネットワークＮＴ１を介して接続される。ネットワークＮＴ１とは、例えば、インターネット等である。情報処理システムは、プラットフォーム１０を構成するものとして、ゲーム開発装置とは各々異なる情報処理装置であるＡＰＩ公開装置２０及びデータベース装置３０を有する。これらはネットワークＮＴ２を介して接続される。ネットワークＮＴ２は、ネットワークＮＴ１と同様にインターネットであっても良いし、ＬＡＮ（Local Area Network）、イントラネット、イーサネット（登録商標）であっても良い。ＡＰＩ公開装置２０は、Ｗｅｂサービスを介してゲームが各種機能を呼び出すための各種のＡＰＩであるＷｅｂサービスＡＰＩを提供するものであり、各種ＡＰＩの定義情報（ＡＰＩ定義情報という）と、これらの各種機能を各々実現するためのプログラムとを記憶している。データベース装置３０は、各ゲーム固有のデータを記憶するゲームデータベース３１と、ユーザのゲームの利用に履歴等に関する統計データを記憶する統計データベース３２とを有する。具体的に例えば、ゲーム固有のデータは、例えば、ユーザがゲームによって獲得したスコアを示すスコア情報や、ゲーム画面に表示するための画像ファイル等である。統計データは、ゲームごとの利用回数合計やゲームごとの利用時間合計等を示すデータである。各ゲーム開発装置は、ＡＰＩ公開装置２０の提供するＷｅｂサービスＡＰＩを利用することにより、ネットワークＮＴ１を介してプラットフォーム１０の提供する各種機能を実現させる。
【００１２】
ここで、本実施の形態に係るＡＰＩ公開装置２０によって提供されるＷｅｂサービスＡＰＩについて説明する。当該ＷｅｂサービスＡＰＩは、ＤＢ ＡＰＩ、高速ＤＢ ＡＰＩ及び統計データＡＰＩの３つのＡＰＩであるとする。ＤＢ ＡＰＩによって実現される機能はデータベース機能であり、高速ＤＢ ＡＰＩによって実現される機能は高速データベース機能であり、統計データＡＰＩによって実現される機能は統計データ管理機能であるとする。データベース機能は、ゲーム固有のデータにアクセスする機能であり、当該データを、ゲームデータベース３１に記憶させたり、ゲームデータベース３１から読み込んだりする機能である。高速データベース機能は、データベース機能よりも高速に、ゲーム固有のデータにアクセスする機能である。統計データ管理機能は、統計データにアクセスする機能であり、統計データを、統計データベース３２に記憶させたり統計データベース３２から読み出したりする機能である。これらのＡＰＩのうち、ＤＢ ＡＰＩは、基本ＡＰＩであり、高速ＤＢ ＡＰＩ及び統計データＡＰＩは、特別ＡＰＩであるものとする。特別ＡＰＩとは、特別にその利用契約を交わしたゲームによってのみ利用が許諾されるＡＰＩである。図１では、ゲームＣに対してのみ特別ＡＰＩの利用契約が交わされており、ゲームＣが基本ＡＰＩ及び特別ＡＰＩの全てのＡＰＩを利用できることが表されている。また、ゲームＡ及びゲームＢに対して特別ＡＰＩの利用契約が交わされていないため、ゲームＡ及びゲームＢは基本ＡＰＩしか利用できないことが表されている。
【００１３】
ここで、ゲーム開発装置、ＡＰＩ公開装置２０及びデータベース装置３０となる情報処理装置のハードウェア構成について説明する。情報処理装置は、装置全体を制御するＣＰＵ（Central Processing Unit）等の制御部と、各種データや各種プログラムを記憶するＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等の主記憶部と、各種データや各種プログラムを記憶するＨＤＤ（Hard Disk Drive）やＣＤ（Compact Disk）ドライブ装置等の補助記憶部と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、情報処理装置には、情報を表示する表示部と、ユーザの指示入力を受け付けるキーボードやマウス等の操作入力部と、外部装置の通信を制御する通信Ｉ／Ｆ（Interface）とが有線又は無線により各々接続される。
【００１４】
次に、このようなハードウェア構成において、ＡＰＩ公開装置２０の機能的構成について図２を用いて説明する。ＡＰＩ公開装置２０は、ＷＳＤＬ（Web Service Description Language）公開部２１と、ゲーム認証部２２と、リクエスト受信部２３と、流出判定部２４と、ゲーム開発者ＤＢ２５と、ゲーム定義情報ＤＢ２６と、ＷＳＤＬＤＢ２７とを有する。ＷＳＤＬ公開部２１と、リクエスト受信部２３とは、ＡＰＩ公開装置２０のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することと、通信Ｉ／Ｆとにより実現される。ゲーム認証部２２と、流出判定部２４とは各々、ＡＰＩ公開装置２０のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される。ゲーム開発者ＤＢ２５と、ゲーム定義情報ＤＢ２６と、ＷＳＤＬＤＢ２７とは各々、ＨＤＤ等の補助記憶部に記憶されるものである。
【００１５】
ＷＳＤＬＤＢ２７は、ＷＳＤＬ情報をゲーム毎に記憶する。ＷＳＤＬ情報は、ＷＳＤＬＩＤと、ＷＳＤＬファイルとを含む。ＷＳＤＬＩＤは、ＷＳＤＬファイルを識別するためにＷＳＤＬファイル及び当該ＷＳＤＬファイルを含むＷＳＤＬ情報に割り当てられるＩＤである。ＷＳＤＬファイルとは、ゲームに対して利用が許可されたＡＰＩの定義情報(ＡＰＩ定義情報)と、ゲームに対して割り当てられたサービス公開アドレスとを示す。ＡＰＩ定義情報とは、ＡＰＩの名前や引数、返り値を示す。サービス公開アドレスとは、Ｗｅｂサービスを公開するアドレスの情報であり、例えば、ＥＰＲ（End Point Reference）と呼ばれるＵＲＬ形式の文字列で表現される。サービス公開アドレスは、ゲーム毎に異なる。このようなＷＳＤＬファイルを利用することで、Ｗｅｂサービスを利用するゲームの開発効率を向上することができる。
【００１６】
ゲーム定義情報ＤＢ２６は、ゲームに関するゲーム定義情報をゲーム毎に記憶する。ゲーム定義情報は、ゲームＩＤと、ゲーム名と、認証情報と、ＷＳＤＬＩＤとを含む。ゲームＩＤは、ゲームを一意に識別するためにゲームに割り当てられる識別情報である。ゲーム名は、ゲームの名称である。認証情報とは、ゲームを認証するための情報である。例えば、認証情報は、パスワードの文字列やクライアント証明書を示す。ＷＳＤＬＩＤは、当該ゲームに対して公開が許可されたＷＳＤＬファイルに割り当てられたＷＳＤＬＩＤを示す。
【００１７】
ゲーム開発者ＤＢ２５は、ゲームの開発者を特定するゲーム開発者情報を各々記憶する。ゲーム開発者情報は、ゲーム開発者ＩＤと、ゲーム開発者名と、ゲームＩＤリストとを含む。ゲーム開発者ＩＤは、ゲーム開発者を識別するためにゲーム開発者に割当られるＩＤである。ゲーム開発者名は、ゲーム開発者名称である。ゲームＩＤリストは、当該ゲーム開発者が開発しているゲームのゲームＩＤを全て示す。
【００１８】
ＷＳＤＬ公開部２１は、ＡＰＩの定義情報をＷＳＤＬファイルとして公開する。本実施の形態においてはＷＳＤＬファイルの公開は、利便性を考慮して、インターネット等のＮＴ１を介して実現するものとする。即ち、ゲーム開発者が操作するゲーム開発装置が、ＡＰＩ公開装置２０からネットワークＮＴ１を介してＷＳＤＬファイルを受信することにより取得する。これを可能にするため、プラットフォーム１０は、ＷＳＤＬ公開部２１をネットワークＮＴ１に公開し、ゲーム開発装置からのＨＴＴＰリクエストを受け付ける構成とする。この場合、ゲーム開発装置は、例えば、ＨＴＴＰクライアントとして機能する。ＨＴＴＰクライアントには、Ｗｅｂブラウザ等がある。このような構成において、ゲーム開発装置は、ＷＳＤＬファイルを要求するリクエストであって、ゲームに割り当てられたゲームＩＤ及び認証情報が付加されたリクエストをＡＰＩ公開装置２０に送信する。このリクエストをＷＳＤＬ公開部２１が受信すると、当該リクエストに付加されたゲームＩＤ及び認証情報を後述のゲーム認証部２２に渡してゲーム認証処理の実行を要求する。ゲーム認証処理の結果、ＷＳＤＬ公開部２１は、ゲーム認証部２２からゲーム定義情報を受け取ると、当該ゲーム定義情報を用いて、当該リクエストに応じたＷＳＤＬファイルをＷＳＤＬＤＢ２７から取得してこれをゲーム開発装置に送信する。
【００１９】
リクエスト受信部２３は、ゲームを開発するゲーム開発装置がプラットフォーム１０に対して送信した、ＡＰＩの利用を要求するリクエストであって、ゲームＩＤ及び認証情報と、当該ＡＰＩのＡＰＩ定義情報及びサービス公開アドレスが付加されたリクエストを受信するものである。このリクエストの受信に先立って、ＡＰＩ公開装置２０の起動時に、リクエスト受信部２３は、ゲームに対してどのようなＡＰＩをどのサービス公開アドレスで公開しているかを予め把握するための初期化処理を行う。初期化処理では、リクエスト受信部２３は、ＷＳＤＬＤＢ２７を参照して、当該ＡＰＩ公開装置２０で公開し得るＡＰＩのＡＰＩ定義情報及びサービス公開アドレスを取得して、ＡＰＩの利用を要求するリクエストの待ち受けを開始する。その後、リクエスト受信部２３は、ＡＰＩの利用を要求するリクエストを受信すると、当該リクエストに付加されたＡＰＩ定義情報及びサービス公開アドレスを用いて、当該ＡＰＩ公開装置２０が公開し得るＡＰＩであるか否かを判定する。当該判定の結果に応じて、リクエスト受信部２３は、当該リクエストに付加されたゲームＩＤ及び認証情報を後述のゲーム認証部２２に渡してゲーム認証処理の実行を要求する。ゲーム認証処理の結果、リクエスト受信部２３は、ゲーム認証部２２からゲーム定義情報を取得すると、当該ゲーム定義情報及び当該リクエストを後述の流出判定部２４に渡す。流出判定部２４の判定の結果、リクエスト受信部２３は、流出判定部２４からエラーを受け取ると、当該リクエストを送信したゲーム開発装置にエラーを送信する。
【００２０】
ゲーム認証部２２は、ＷＳＤＬ公開部２１やリクエスト受信部２３の要求に応じて、ゲームＩＤ及び認証情報を用いて、ゲーム定義情報ＤＢ２６を参照して、当該ゲームを認証するゲーム認証処理を行う。当該ゲームの認証に成功した場合、ゲーム認証部２２は、ゲーム定義情報ＤＢ２６から該当のゲーム定義情報を得て、これをゲーム認証処理の実行の要求元であるＷＳＤＬ公開部２１やリクエスト受信部２３に返す。一方、ゲームの認証に失敗した場合、ゲーム認証部２２は、ゲーム認証処理の実行の要求元であるＷＳＤＬ公開部２１やリクエスト受信部２３にエラーを返す。
【００２１】
流出判定部２４は、リクエスト受信部２３から渡されたゲーム定義情報及びリクエストを用いて、ゲーム開発者ＤＢ２５、ゲーム定義情報ＤＢ２６及びＷＳＤＬＤＢ２７を参照して、ＷＳＤＬファイルの流出の有無を判定する。当該判定の結果、ＷＳＤＬファイルが流出したと判定した場合、流出判定部２４は、リクエスト受信部２３にエラーを返す。一方、当該判定の結果、ＷＳＤＬファイルが流出していないと判定した場合、流出判定部２４は、当該ゲーム定義情報及びリクエストを、当該リクエストによって利用が要求されたＡＰＩに渡す。本実施の形態において利用され得るＡＰＩは、上述したように、ＤＢ ＡＰＩ、高速ＤＢ ＡＰＩ及び統計データＡＰＩである。ここで、これらのＡＰＩの概要について簡単に説明する。
【００２２】
ＤＢ ＡＰＩとしては、例えば、ｐｕｔ（キー、データ）や、ｇｅｔ（キー）というＡＰＩがある。ｐｕｔ（キー、データ）とは、データを、キーと関連付けてゲームデータベース３１に保存するＡＰＩである。ｇｅｔ（キー）とは、キーに一致するデータを、ゲームデータベース３１から取得するＡＰＩである。その他、ＤＢ ＡＰＩとして、複数のデータを一度にゲームデータベース３１に保存するＡＰＩがあっても良い。
【００２３】
高速ＤＢ ＡＰＩとしては、例えば、ｆａｓｔＰｕｔ（キー、データ）や、ｆａｓｔＧｅｔ（キー）がある。ｆａｓｔＰｕｔ（キー、データ）とは、データを、キーと関連付けてゲームデータベース３１に高速に保存するＡＰＩである。ｆａｓｔＧｅｔ（キー）は、キーに一致するデータを、データベース装置３０から高速に取得するＡＰＩである。高速ＤＢ ＡＰＩによってデータに高速にアクセスすることにより、例えば、リクエストやレスポンスのメッセージを圧縮することによる通信時間の削減や、リクエスト処理プロセスの優先度付け、キャッシュの利用等が実現できる。
【００２４】
統計データＡＰＩとしては、例えば、ｇｅｔＵｓｅＣｏｕｎｔ（ゲームＩＤ）や、ｇｅｔＵｓｅＴｉｍｅ（ゲームＩＤ）がある。ｇｅｔＵｓｅＣｏｕｎｔ（ゲームＩＤ）は、統計データによって示される利用回数合計を取得するＡＰＩである。ｇｅｔＵｓｅＴｉｍｅ（ゲームＩＤ）は、統計データによって示される利用時間合計を取得するＡＰＩである。
【００２５】
次に、本実施の形態に係るゲーム開発者とプラットフォーム開発者との業務フローについて説明する。ゲーム開発者は、ゲームの開発にあたり、プラットフォーム開発者と基本契約又は特別契約を交わす必要がある。これらの契約によって、ゲーム開発者が開発するゲームの利用できる機能及びＡＰＩが決まる。図３は、契約時の業務フローを示す図である。プラットフォーム開発者は、ゲーム開発者名を把握する（業務ステップＧ１）。プラットフォーム開発者は、ゲーム開発者に固有のゲーム開発者ＩＤを割り当てる（業務ステップＧ２）。プラットフォーム開発者は、ゲーム名と、ゲームが利用するＡＰＩを把握する（業務ステップＧ３）。プラットフォーム開発者は、ゲームに対して固有に割り当てるゲームＩＤ、サービス公開アドレス及び認証情報を決定し、これらをゲーム開発者に教える（業務ステップＧ４）。後述するように、契約を交わしたゲームのゲーム開発者により操作されるゲーム開発装置では、Ｗｅｂサービスを介して当該ゲームからのＡＰＩの利用を要求するリクエストを送信する際に、当該リクエストに当該ゲームＩＤ及び認証情報を付加することで、ＡＰＩ公開装置２０において当該ゲームの認証に成功させることが可能になる。
【００２６】
プラットフォーム開発者は、ＡＰＩ公開装置２０の有する操作入力部を介して、ゲームが利用するＡＰＩのＡＰＩ定義情報と、業務ステップＧ４で決定したサービス公開アドレスとを記述したＷＳＤＬファイルを作成する操作入力を行う（業務ステップＧ５）。当該操作入力を受け付けたＡＰＩ公開装置２０では、ＷＳＤＬファイルが作成される。ここで、ゲーム毎、即ち、ＷＳＤＬファイル毎に異なるサービス公開アドレスが記述されたＷＳＤＬファイルが作成されることで、当該ＷＳＤＬファイルが流出した場合にその流出元を特定することが可能になる。プラットフォーム開発者は、ＷＳＤＬファイルに固有のＷＳＤＬＩＤを割り当て、当該ＷＳＤＬファイル及びＷＳＤＬＩＤを含むＷＳＤＬ情報をＷＳＤＬＤＢ２７に登録する操作入力を行う（業務ステップＧ６）。当該操作入力を受け付けたＡＰＩ公開装置２０では、ＷＳＤＬファイルがＷＳＤＬＤＢ２７に記憶される。プラットフォーム開発者は、業務ステップＧ４で決定したゲーム名、ゲームＩＤ、認証情報及び業務ステップＧ６で割り当てたＷＳＤＬＩＤを含むゲーム定義情報を作成する操作入力を行い、当該ゲーム定義情報をゲーム定義情報ＤＢ２６に登録する操作入力を行う（業務ステップＧ７）。当該操作入力を受け付けたＡＰＩ公開装置２０では、ゲーム定義情報が作成されてこれがゲーム定義情報ＤＢ２６に記憶される。プラットフォーム開発者は、ゲーム開発者ＩＤ、開発者名、業務ステップＧ４で割り当てたゲームＩＤを含むゲーム開発者情報を作成する操作入力を行い、当該ゲーム開発者情報をゲーム開発者ＤＢ２５に登録する操作入力を行う（業務ステップＧ８）。当該操作入力を受け付けたＡＰＩ公開装置２０では、ゲーム開発者情報が作成されてこれがゲーム開発者ＤＢに記憶される。
【００２７】
次に、ＡＰＩ公開装置２０が行う処理の手順について説明する。まず、ＡＰＩ公開装置２０がゲーム開発装置からの要求に応じてＷＳＤＬファイルを公開する処理の手順について図４を用いて説明する。ゲーム開発者は、プラットフォーム１０がＷｅｂサービスを介して提供するＡＰＩを利用してゲームを開発するため、当該ＡＰＩのＡＰＩ定義情報が示されるＷＳＤＬファイルをプラットフォーム１０から取得する必要がある。このため、ゲーム開発者が、ゲーム開発装置の操作入力部を介してＷＳＤＬファイルを取得するための操作入力を行うと、ゲーム開発装置は、当該操作入力を受け付け、ＡＰＩ公開装置２０にＷＳＤＬファイルを要求するリクエストであり、ゲームに割り当てられたゲームＩＤ及び認証情報を付加したリクエストを送信する。当該リクエストに認証情報を付加することは、例えば、認証情報がパスワードの文字列を示すものである場合、以下のようにして実現される。ＡＰＩ公開装置２０のＷＳＤＬ公開部２１が、ゲーム開発装置のＷｅｂブラウザ上にゲームＩＤ及びパスワードの文字列を入力するためのダイアログを表示させ、ゲーム開発者にゲームＩＤとパスワードの文字列を入力させる。そして、ゲーム開発装置のＷｅｂブラウザが、入力されたゲームＩＤとパスワードの文字列をリクエストに付加し、ＡＰＩ公開装置２０のＷＳＤＬ公開部２１に送信することで、ＨＴＴＰダイジェスト認証を行うことができる。
【００２８】
ＡＰＩ公開装置２０のＷＳＤＬ公開部２１は、当該リクエストを受信すると（ステップＳ１）、ゲーム認証部２２に当該リクエストを渡してゲーム認証処理の実行を要求する（ステップＳ２）。ゲーム認証処理の詳細については後述する。その後、ＷＳＤＬ公開部２１は、ゲーム認証処理の結果をゲーム認証部２２から受け取り、ゲーム定義情報が得られたか否かを判定する（ステップＳ３）。ゲーム定義情報が得られなかった場合は(ステップＳ３：ＮＯ)、ゲームの認証は失敗である。この場合、ＷＳＤＬ公開部２１は、ゲームの認証が失敗した旨を示すエラーメッセージをゲーム開発装置に送信する（ステップＳ４）。ゲーム定義情報が得られた場合は（ステップＳ３：ＹＥＳ）、ゲームの認証は成功である。この場合、ＷＳＤＬ公開部２１は、ＷＳＤＬＤＢ２７にアクセスして、ゲーム定義情報に含まれるＷＳＤＬＩＤと同一のＷＳＤＬＩＤを含むＷＳＤＬ情報を取得する（ステップＳ５）。そして、ＷＳＤＬ公開部２１は、取得したＷＳＤＬ情報に含まれるＷＳＤＬファイルをゲーム開発装置に送信する（ステップＳ６）。
【００２９】
次に、ステップＳ２でゲーム認証部２２が行うゲーム認証処理の手順について図５を用いて説明する。ゲーム認証部２２は、ＷＳＤＬ公開部２１からリクエストを受け取ると、当該リクエストに付加されているゲームＩＤ及び認証情報を取得する（ステップＳ１０）。当該リクエストにゲームＩＤ及び認証情報が付加されていなければ、ゲーム認証部２２は、ゲームの認証が失敗した旨を示すエラーをＷＳＤＬ公開部２１に返す。
【００３０】
ゲーム認証部２２は、ゲーム定義情報ＤＢ２６にアクセスして（ステップＳ１１）、ステップＳ１０で取得したゲームＩＤと同一のゲームＩＤ及びステップＳ１０で取得した認証情報と同一の認証情報を含むゲーム定義情報が存在するか否かを判定する（ステップＳ１２）。該当するゲーム定義情報が存在する場合（ステップＳ１２：ＹＥＳ）、ゲームの認証は成功となる。この場合、ゲーム認証部２２は、該当のゲーム定義情報をＷＳＤＬ公開部２１に返す（ステップＳ１３）。該当のゲーム定義情報が存在しない場合（ステップＳ１２：ＮＯ）、ゲームの認証は失敗となる。この場合、ゲーム認証部２２は、ＷＳＤＬ公開部２１に何も返さず（ステップＳ１４）、当該ゲーム認証処理を終了する。
【００３１】
以上のように、契約時に決定された認証情報を利用することで、ＡＰＩ公開装置２０は、未契約のゲームを開発するゲーム開発装置から送信されたリクエストを破棄することができる。
【００３２】
次に、ＡＰＩの利用を要求するリクエストに対する処理の手順について説明する。ここで、まず、ＡＰＩ公開装置２０が起動時に行う初期化処理について図６を用いて説明する。ＡＰＩ公開装置２０が起動すると、リクエスト受信部２３は、ＷＳＤＬＤＢ２７に記憶されている全てのＷＳＤＬ情報に含まれるＷＳＤＬファイルを参照して（ステップＳ２０）、当該ＷＳＤＬファイルによって示されるＡＰＩ定義情報及びサービス公開アドレスを用いて、どのようなＡＰＩをどのサービス公開アドレスで公開するべきかを判定する（ステップＳ２１）。即ち、リクエスト受信部２３は、当該ＡＰＩ公開装置２０が公開し得るＡＰＩのＡＰＩ定義情報及びサービス公開アドレスを取得して、ＡＰＩの利用を要求するリクエストの待ち受けを開始する。
【００３３】
次に、ＡＰＩの利用を要求するリクエストをＡＰＩ公開装置２０がゲーム開発装置から受信した場合の処理の手順について図７を用いて説明する。ゲーム開発装置は、ＡＰＩの利用を要求するリクエストであり、当該ＡＰＩを利用するゲームのゲームＩＤ及び認証情報と、当該ＡＰＩのＡＰＩ定義情報及びサービス公開アドレスとを各々付加したリクエストを送信する。以下、このゲームのことをゲームＧ、このリクエストのことをリクエストＲと呼ぶ。ここでは、リクエストはＳＯＡＰリクエストを想定する。ＡＰＩ公開装置２０のリクエスト受信部２３は、当該リクエストＲを受信すると、これをゲーム認証部２２に渡してゲーム認証処理の実行を要求する（ステップＳ３０）。当該ゲーム認証処理の手順は上述の図５と略同様であるため、その詳細な説明は省略する。但し、ステップＳ１０でゲーム認証部２２がリクエストを受け取るのはリクエスト受信部２３からであり、当該リクエストにゲームＩＤ及び認証情報が付加されていない場合にゲーム認証部２２がエラーを返す先はリクエスト受信部２３であり、ステップＳ１３でゲーム認証部２２がゲーム定義情報を返す先はリクエスト受信部２３である。
【００３４】
リクエスト受信部２３は、ゲーム認証処理の結果、ゲーム認証部２２からゲーム定義情報が得られたかを否かを判定する（ステップＳ３１）。ゲーム定義情報が得られなかった場合（ステップＳ３１：ＮＯ）、ゲームＧの認証は失敗である。この場合、ステップＳ３３に進む。一方、ゲーム定義情報が得られた場合（ステップＳ３１：ＹＥＳ）、ゲームＧの認証は成功である。この場合、リクエスト受信部２３は、リクエストＲに付加されたＡＰＩ定義情報及びサービス公開アドレスを参照して、当該ＡＰＩ公開装置２０が公開し得るＡＰＩであるか否かを判定する（ステップＳ３２）。具体的には、リクエスト受信部２３は、上述の初期化処理で取得したＡＰＩ定義情報及びサービス公開アドレスに基づいて、リクエストＲに付加されたＡＰＩ定義情報及びサービス公開アドレスに該当するＡＰＩ（ＡＰＩαとする）が存在するか否かを判定する。該当のＡＰＩαが存在しない場合（ステップＳ３２：ＮＯ）、ステップＳ３３に進む。一方、該当のＡＰＩαが存在する場合（ステップＳ３２：ＹＥＳ）、リクエスト受信部２３は、リクエストＲと、ゲームＧのゲーム定義情報とを、流出判定部２４に渡す（ステップＳ３４）。
【００３５】
流出判定部２４は、リクエストＲ及びゲーム定義情報を受け取ると、ゲーム定義情報に含まれるＷＳＤＬＩＤと同一のＷＳＤＬＩＤを含むＷＳＤＬ情報を特定し、当該ＷＳＤＬ情報に含まれるＷＳＤＬファイルをＷＳＤＬＤＢ２７から取得する（ステップＳ３５）。次いで、流出判定部２４は、リクエストＲによって要求されたＡＰＩαの利用に対する正当性を確認する（ステップＳ３６）。つまり、流出判定部２４は、ゲームＧが、ＡＰＩαの利用が許可されたゲームであるか否かを判定する。以下の２つの条件(a),(b)を満たす場合、リクエストＲによって要求されたＡＰＩαの利用は正当であると流出判定部２４は判定する。
(a)ステップＳ３５で取得したＷＳＤＬファイルに、ＡＰＩαのＡＰＩ定義情報が示されている
(b)ステップＳ３５で取得したＷＳＤＬファイルによって示されているサービス公開アドレスが、リクエストＲに付加されたサービス公開アドレスと同一である
【００３６】
リクエストＲによって要求されたＡＰＩαの利用は正当であると判定した場合（ステップＳ３６：ＹＥＳ）、流出判定部２４は、リクエストＲとゲームＧのゲーム定義情報とをＡＰＩαへ渡す（ステップＳ３７）。ＡＰＩαは、上述したＤＢ ＡＰＩ、高速ＤＢ ＡＰＩ及び統計データＡＰＩのうち少なくとも１つである。
【００３７】
一方、リクエストＲによって要求されたＡＰＩαの利用は正当でないと判定した場合（ステップＳ３６：ＮＯ）、この時点では、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルが流出したとはまだ判定できない。なぜなら、ゲームＧと、ＡＰＩαの利用が許可されたゲームとのゲーム開発者が同一である可能性が残っているためである。このため、流出判定部２４は、ゲーム開発者ＤＢ２５に記憶されている全てのゲーム開発者情報を参照して(ステップＳ３８)、ＡＰＩαの利用が許可されたゲームのゲーム開発者と、ゲームＧのゲーム開発者とが同一であるか否かを判定する（ステップＳ３９）。具体的な判定の方法は例えば以下の通りである。流出判定部２４は、ゲーム開発者ＤＢ２５に記憶されている全てのゲーム開発者情報に含まれるゲームＩＤリストによって示されるゲームＩＤを参照して、ゲームＧのゲームＩＤを示すゲームＩＤリストを含むゲーム開発者情報を取得する。流出判定部２４は、ゲーム定義情報ＤＢ２６を参照して、取得したゲーム開発者情報に含まれるゲームＩＤリストによって示されるゲームＩＤと同一のゲームＩＤを含むゲーム定義情報を取得する。流出判定部２４は、ＷＳＤＬＤＢ２７を参照して、取得したゲーム定義情報に含まれるＷＳＤＬＩＤと同一のＷＳＤＬＩＤを含むＷＳＤＬ情報を取得し、当該ＷＳＤＬ情報に含まれるＷＳＤＬファイルを取得する。流出判定部２４は、当該ＷＳＤＬファイルにＡＰＩαのＡＰＩ定義情報が含まれていれば、ＡＰＩαの利用が許可されたゲームのゲーム開発者と、ゲームＧのゲーム開発者とが同一であると判定し、当該ＷＳＤＬファイルにＡＰＩαのＡＰＩ定義情報が含まれていなければ、双方のゲーム開発者が同一ではないと判定する。
【００３８】
双方のゲーム開発者が同一である場合（ステップＳ３９：ＹＥＳ）、ゲームＧのゲーム開発者は、ＡＰＩαのＡＰＩ定義情報を知っていると考えられるため、リクエストＲの送信は、ゲーム開発上のミスだと判定できる。従って、この場合、流出判定部２４は、ＷＳＤＬファイルが流出した可能性として、流出の重要度を「低」と判定して（ステップＳ４０）、ステップＳ４２に進む。一方、双方のゲーム開発者が異なる場合（ステップＳ３９：ＮＯ）、ゲームＧの開発者は、ＡＰＩαのＡＰＩ定義情報を知らないはずである。従って、この場合、流出判定部２４は、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルが流出した可能性が高いと判定し、流出の重要度を「高」と判定して（ステップＳ４１）、ステップＳ４２に進む。尚、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルがどのゲーム開発者に公開されているかは、ゲーム開発者ＤＢ２５とゲーム定義情報ＤＢ２６及びＷＳＤＬＤＢ２７を参照することで確認することができる。具体的には、流出判定部２４は、ゲーム定義情報ＤＢ２６を参照して、ＷＳＤＬＤＢ２７に記憶されたＷＳＤＬ情報に当該ＷＳＤＬファイルと共に含まれるＷＳＤＬＩＤと同一のＷＳＤＬＩＤを含むゲーム定義情報を取得する。流出判定部２４は、ゲーム開発者ＤＢ２５を参照して、取得したゲーム定義情報に含まれるゲームＩＤと同一のゲームＩＤを示すゲームＩＤリストを含むゲーム開発者情報を取得することにより、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルの流出元のゲーム開発者を特定することができる。
【００３９】
ステップＳ４２では、流出判定部２４は、プラットフォーム開発者にＷＳＤＬファイルの流出の発生を通知する。通知方法には、電話や電子メール等を利用する方法がある。ＷＳＤＬファイルの流出の重要度が「高」の場合には電話を利用し、ＷＳＤＬファイルの流出の重要度が「低」の場合には電子メールを利用する等の使い分けが可能である。尚、電話を利用する場合には、プラットフォーム開発者の電話番号をＡＰＩ公開装置２０は予め記憶しておき、当該電話番号に発信することで、電話を掛けるようにしても良いし、ＡＰＩ公開装置２０に通信端末が別途接続されており、当該通信端末を介して予め記憶された電話番号に発信させることで、電話を掛けるようにしても良い。電子メールを利用する場合には、ＡＰＩ公開装置２０はプラットフォーム開発者の電子メールアドレスを予め記憶しておき、当該電子メールアドレスを含み、ＷＳＤＬファイルの流出が発生した旨を示す電子メールを作成してこれを送信するようにすれば良い。その後、流出判定部２４は、リクエスト受信部２３に権限エラーを返す（ステップＳ４４）。リクエスト受信部２３は、当該権限エラーを受け取ると、ステップＳ３３に進む。ステップＳ３３では、リクエスト受信部２３は、ゲームＧの認証に失敗した旨を示すエラーメッセージを、ゲームＧのゲーム開発装置に送信する。
【００４０】
以上のように、本実施の形態においては、ＡＰＩ公開装置２０は、ゲーム毎に個別のサービス公開アドレスを割り当て、個別のＷＳＤＬファイルを作成して公開する。これにより、ＷＳＤＬファイルが流出し、特別ＡＰＩのＡＰＩ定義情報を知らないはずのゲームによる特別ＡＰＩの利用を要求するリクエストを送信しても、ＡＰＩ公開装置２０は当該リクエストを破棄することができる。即ち、ＡＰＩ公開装置２０は、ＡＰＩの不正利用を検出してこれを排除することができる。また、ＡＰＩ公開装置２０は、ＷＳＤＬファイルの流出元を特定することができる。この結果、ＷＳＤＬファイルの流出の抑制や、ＷＳＤＬファイルの流出元に対して責任を問うことが可能となる。
【００４１】
[第２の実施形態]
次に、情報処理装置及びプログラムの第２の実施の形態について説明する。尚、上述の第１の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
【００４２】
第１の実施形態のように、プラットフォーム開発者が、ゲーム毎にＡＰＩ定義情報及びサービス公開アドレスを記述したＷＳＤＬファイルを作成する操作入力を行う場合、ＷＳＤＬファイルの内容に記述ミスが生じる可能性がある。ＷＳＤＬファイルの記述に誤りがあると、本来は公開したくないＡＰＩのＡＰＩ定義情報が公開されてしまう恐れがある。また、ＷＳＤＬファイルの読み手（ゲーム開発者等）が、ＡＰＩ定義情報を理解できない恐れがある。このような問題を回避するため、本実施の形態においては、ＡＰＩ公開装置２０が、ＷＳＤＬファイルを自動で作成する。
【００４３】
図８は、本実施の形態におけるＡＰＩ公開装置２０の機能的構成を例示する図である。本実施の形態に係るＡＰＩ公開装置２０は、上述のＷＳＤＬ公開部２１と、ゲーム認証部２２と、リクエスト受信部２３と、流出判定部２４と、ゲーム開発者ＤＢ２５と、ゲーム定義情報ＤＢ２６とに加え、ＷＳＤＬ作成部２８と、ＡＰＩＤＢ２９とを更に有し、ＷＳＤＬＤＢ２７を有さない。ＷＳＤＬ作成部２８は、ＡＰＩ公開装置２０のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される。ＡＰＩＤＢ２９は、ＨＤＤ等の補助記憶部に記憶されるものである。また、本実施の形態においては、ゲーム定義情報ＤＢ２６に記憶されるゲーム定義情報が上述の第１の実施の形態と異なる。ＷＳＤＬ公開部２１の機能の一部及びリクエスト受信部２３の機能の一部が上述の第１の実施の形態と異なる。
【００４４】
ＡＰＩＤＢ２９は、ＡＰＩ公開装置２０が提供するＡＰＩに関するＡＰＩ情報を記憶する。ＡＰＩ情報は、ＡＰＩＩＤと、ＡＰＩ定義情報とを含む。ＡＰＩＩＤは、ＡＰＩを識別するためにＡＰＩに割り当てられるＩＤである。プラットフォーム開発者は、ゲーム開発者と契約を交わす前に、ＡＰＩ公開装置２０において、ＡＰＩ公開装置２０が提供するＡＰＩに関するＡＰＩ情報をＡＰＩＤＢ２９に登録する操作入力を行って、当該ＡＰＩ情報をＡＰＩＤＢ２９に記憶させる。
【００４５】
本実施の形態に係るゲーム定義情報ＤＢ２６に記憶されるゲーム定義情報は、ゲームＩＤと、ゲーム名と、認証情報との他、ＡＰＩＩＤリストと、サービス公開アドレスとを含む。ＡＰＩＩＤリストは、当該ゲームに対して利用が許可されているＡＰＩのＡＰＩＩＤを全て示す。サービス公開アドレスは、上述と同様に各ゲームに固有に割り当てられるものである。
【００４６】
ＷＳＤＬ公開部２１は、ＷＳＤＬファイルを要求するリクエストを受信すると、第１の実施の形態と同様にしてゲーム認証部２２にゲーム認証処理の実行を要求するが、ゲーム認証部２２からゲーム定義情報を受け取ると、本実施の形態においては、当該ゲーム定義情報をＷＳＤＬ作成部２８に渡してＷＳＤＬファイルの作成を要求する。そして、ＷＳＤＬ公開部２１は、当該要求に応じて作成されたＷＳＤＬファイルをＷＳＤＬ作成部２８から受け取ると、これをゲーム開発装置に送信する。
【００４７】
リクエスト受信部２３は、第１の実施の形態で説明した初期化処理において、当該ＡＰＩ公開装置２０が公開し得るＷＳＤＬファイルの作成をＷＳＤＬ作成部２８に要求する。そして、リクエスト受信部２３は、当該要求に応じて作成されたＷＳＤＬファイルをＷＳＤＬ作成部２８から受け取ると、当該ＷＳＤＬファイルによって示されるＡＰＩ定義情報及びサービス公開アドレスを取得して、Ｗｅｂサービスの利用を要求するリクエストの待ち受けを開始する。
【００４８】
ＷＳＤＬ作成部２８は、ＷＳＤＬ公開部２１やリクエスト受信部２３の要求に応じて、ゲーム定義情報と、ＡＰＩ情報とを用いて、ＷＳＤＬファイルを作成する。具体的には、ＷＳＤＬ作成部２８は、ゲーム定義情報に含まれるＡＰＩＩＤリストによって示されるＡＰＩＩＤを各々含むＡＰＩ情報に各々含まれるＡＰＩ定義情報を取得し、ゲーム定義情報に含まれるサービス公開アドレスと合わせてＷＳＤＬファイルを作成する。そして、ＷＳＤＬ作成部２８は、作成したＷＳＤＬファイルを要求元のＷＳＤＬ公開部２１やリクエスト受信部２３に渡す。
【００４９】
次に、本実施の形態に係るゲーム開発者とプラットフォーム開発者との業務フローについて説明する。図９は、本実施の形態に係る契約時の業務フローを示す図である。業務ステップＧ１〜Ｇ４は第１の実施の形態と同様である。業務ステップＧ４の後は、プラットフォーム開発者は、ＷＳＤＬファイルを作成する操作入力及び当該ＷＳＤＬファイルを含むＷＳＤＬ情報をＷＳＤＬＤＢ２７に登録する操作入力を行うことなく、上述と同様の業務ステップＧ７〜Ｇ８を行う。
【００５０】
次に、ＡＰＩ公開装置２０が行う処理の手順について説明する。まず、ＡＰＩ公開装置２０がゲーム開発装置からの要求に応じてＷＳＤＬファイルを公開する処理の手順について図１０を用いて説明する。ステップＳ１〜Ｓ４は第１の実施の形態と同様である。ステップＳ３でゲーム定義情報を得られた場合（ステップＳ３：ＹＥＳ）、ＷＳＤＬ公開部２１は、得られたゲーム定義情報をＷＳＤＬ作成部２８に渡す（ステップＳ５０）。ＷＳＤＬ作成部２８は、ゲーム定義情報を受け取ると、ＡＰＩＤＢ２９を参照して、当該ゲーム定義情報に含まれるＡＰＩＩＤリストによって示されるＡＰＩＩＤを各々含むＡＰＩ情報に各々含まれるＡＰＩ定義情報を取得する（ステップＳ５１）。そして、ＷＳＤＬ作成部２８は、当該ＡＰＩ定義情報と、当該ゲーム定義情報に含まれるサービス公開アドレスとを示すＷＳＤＬファイルを作成して、これをＷＳＤＬ公開部２１に渡す（ステップＳ５２）。ＷＳＤＬ公開部２１は、ＷＳＤＬファイルを受け取ると、これをゲーム開発装置に送信する（ステップＳ５３）。
【００５１】
次に、ＡＰＩの利用を要求するリクエストに対する処理の手順について説明する。ここで、まず、ＡＰＩ公開装置２０が起動時に行う初期化処理について図１１を用いて説明する。ＡＰＩ公開装置２０が起動すると、リクエスト受信部２３は、ＡＰＩ公開装置２０が公開し得る全てのＷＳＤＬファイルの作成をＷＳＤＬ作成部２８に要求する（ステップＳ６０）。ＷＳＤＬ作成部２８は、ゲーム定義情報ＤＢ２６に記憶されている全てのゲーム定義情報を参照して、ゲーム定義情報に含まれるＡＰＩＩＤリスト及びサービス公開アドレスを取得する（ステップＳ６１）。次いで、ＷＳＤＬ作成部２８は、ＡＰＩＤＢ２９を参照して、ゲーム毎に、ＡＰＩＩＤリストによって示されるＡＰＩＩＤを各々含むＡＰＩ情報に各々含まれるＡＰＩ定義情報を取得し、当該ＡＰＩ定義情報と、当該ゲームのゲーム定義情報に含まれるサービス公開アドレスとを示すＷＳＤＬファイルを作成する（ステップＳ６２）。このようにしてＷＳＤＬ作成部２８はゲーム毎のＷＳＤＬファイルを作成して、これらをリクエスト受信部２３に渡す。リクエスト受信部２３は、当該ＷＳＤＬファイルを受け取ると、当該ＷＳＤＬファイルによって示されるＡＰＩ定義情報及びサービス公開アドレスを取得して、Ｗｅｂサービスの利用を要求するリクエストの待ち受けを開始する（ステップＳ６３）。
【００５２】
次に、ＡＰＩの利用を要求するリクエストをＡＰＩ公開装置２０がゲーム開発装置から受信した場合の処理の手順について図１２を用いて説明する。ゲーム開発装置が、第１の実施の形態と同様に、ＡＰＩの利用を要求するリクエストをＡＰＩ公開装置２０に送信する。以下、このゲームのことをゲームＧ、このリクエストのことをリクエストＲと呼ぶ。ステップＳ３０〜Ｓ３４は第１の実施の形態と同様である。ステップＳ３４の後、ステップＳ７０では、流出判定部２４は、リクエストＲ及びゲーム定義情報を受け取ると、ゲーム定義情報に含まれるＡＰＩＩＤリストによって示されるＡＰＩＩＤを含むＡＰＩ情報を取得する。次いで、流出判定部２４は、リクエストＲによって要求されたＡＰＩαの利用の正当性を確認する（ステップＳ７１）。以下の２つの条件(c),(d)を満たす場合、リクエストＲによって要求されたＡＰＩαの利用は正当であると流出判定部２４は判定する。
(c)ステップＳ７０で取得したＡＰＩ情報のうち、ＡＰＩαのＡＰＩ定義情報を含むＡＰＩ情報が存在する
(d)リクエストＲに付加されたサービス公開アドレスと、ゲーム定義情報に含まれるサービス公開アドレスとが同一である
【００５３】
リクエストＲによって要求されたＡＰＩαの利用は正当であると判定した場合（ステップＳ７１：ＹＥＳ）、上述と同様にステップＳ３７に進む。一方、リクエストＲによって要求されたＡＰＩαの利用は正当でないと判定した場合（ステップＳ７１：ＮＯ）、流出判定部２４は、第１の実施の形態と同様に、ゲーム開発者ＤＢ２５に記憶されている全てのゲーム開発者情報を参照して(ステップＳ３８)、ＡＰＩαの利用が許可されたゲームのゲーム開発者と、ゲームＧのゲーム開発者とが同一であるか否かを判定する（ステップＳ３９）。但し、本実施の形態においては、具体的な判定の方法が第１の実施の形態と異なる。流出判定部２４は、ゲーム開発者ＤＢ２５に記憶されている全てのゲーム開発者情報に含まれるゲームＩＤリストによって示されるゲームＩＤを参照して、ゲームＧのゲームＩＤを示すゲームＩＤリストを含むゲーム開発者情報を取得する。流出判定部２４は、ゲーム定義情報ＤＢ２６を参照して、取得したゲーム開発者情報に含まれるゲームＩＤリストによって示されるゲームＩＤと同一のゲームＩＤを含むゲーム定義情報を取得する。ここまでは、第１の実施の形態と同様である。その後、流出判定部２４は、ＡＰＩＤＢ２９を参照して、取得したゲーム定義情報に含まれるＡＰＩＩＤと同一のＡＰＩＬＩＤを含むＡＰＩ情報を取得する。そして、流出判定部２４は、ゲーム定義情報毎に、ＡＰＩ情報及びサービス公開アドレスを組み合わせて、その組み合わせのいずれかにＡＰＩαに関するＡＰＩ情報が含まれていれば、ＡＰＩαの利用が許可されたゲームのゲーム開発者と、ゲームＧのゲーム開発者とが同一であると判定し、その組み合わせのいずれかにＡＰＩαに関するＡＰＩ情報が含まれていなければ、双方のゲーム開発者が同一ではないと判定する。
【００５４】
ステップＳ３７，Ｓ３９〜Ｓ４４は第１の実施の形態と同様である。尚、ＷＳＤＬファイルが流出したと判定した場合、尚、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルが、どのゲーム開発者に公開されているかは、ゲーム開発者ＤＢ２５、ゲーム定義情報ＤＢ２６及びＡＰＩＤＢ２９を参照することで確認することができる。具体的には、流出判定部２４は、ゲーム定義情報ＤＢ２６を参照して、ＡＰＩＤＢ２９に記憶されたＡＰＩ情報に当該ＡＰＩ定義情報と共に含まれるＡＰＩＩＤと同一のＡＰＩＩＤを含むゲーム定義情報を取得する。流出判定部２４は、ゲーム開発者ＤＢ２５を参照して、取得したゲーム定義情報に含まれるゲームＩＤと同一のゲームＩＤを示すゲームＩＤリストを含むゲーム開発者情報を取得することにより、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルの流出元のゲーム開発者を特定することができる。
【００５５】
以上のように、本実施の形態においては、ＡＰＩ公開装置２０の提供するＡＰＩに関するＡＰＩ情報をＡＰＩＤＢ２９に予め記憶させておき、ゲーム開発者との契約時に、ゲームがその利用を許可されたＡＰＩのＡＰＩＩＤを示すＡＰＩＩＤリストをゲーム定義情報に含ませることで、ゲーム毎に個別のサービス公開アドレスを割り当てた個別のＷＳＤＬファイルの作成を機械的に行うことが可能になる。従って、プラットフォーム開発者がＷＳＤＬファイルを作成しなくて良くなる。このため、ＷＳＤＬファイルの記述ミスを避けることができると共に、ＷＳＤＬファイルの流出が生じた場合に、その流出元を特定することができる。
【００５６】
尚、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施形態に示される全構成要素からいくつかの構成要素を削除しても良い。さらに、異なる実施形態にわたる構成要素を適宜組み合わせても良い。
【００５７】
上述した各実施の形態において、ＡＰＩ公開装置２０で実行される各種プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供するように構成しても良い。
【００５８】
上述した各実施の形態において、ＡＰＩ公開装置２０が実現するＡＰＩは、上述の例に限らず、例えば、ユーザ情報管理機能等の機能であっても良い。また、データベース装置３０が有するデータベースは、上述の例に限らず、例えば、ユーザデータを記憶するユーザデータベースであっても良い。また、ゲームデータベース３１及び統計データベース３２を有するデータベース装置３０は１つであっても良いし、複数であっても良い。また、複数のデータベース装置３０でゲームデータベース３１及び統計データベース３２のうち少なくとも１つを複数のデータベース装置３０で分散して管理するようにしても良い。また、プラットフォーム１０がデータベース装置３０を有さず、ＡＰＩ公開装置２０がゲームデータベース３１及び統計データベース３２のうち少なくとも１つを有するようにしても良いし、ＷｅｂサービスＡＰＩによってアプリケーションプログラムからアクセスされるその他のデータベースを有するようにしても良い。
【００５９】
上述した各実施の形態において、ＡＰＩ公開装置２０が公開するＷｅｂサービスＡＰＩを利用するアプリケーションプログラムとしてゲームを例に挙げて説明したが、アプリケーションプログラムはこれに限らない。
【００６０】
上述した各実施の形態において、ＷＳＤＬファイルは、ＡＰＩ定義情報及びサービス公開アドレスの他、例えば、ＡＰＩ公開装置２０のＩＰアドレスや、リクエストを待ち受けるポート番号を示すようにしても良い。
【００６１】
上述した各実施の形態において、ゲーム開発者にＷＳＤＬファイルを渡す方法は、ＡＰＩ公開装置２０がネットワークＮＴ１を介してゲーム開発装置にＷＳＤＬファイルを送信する方法を例に挙げて説明したが、これに限らず、例えば、ＦＴＰを利用してゲーム開発装置にＷＳＤＬファイルを送信する方法や電子メールを利用してＷＳＤＬファイルを送信する方法、持ち運び可能なディスクを利用して、ＷＳＤＬファイルを記憶したディスクをゲーム開発者に渡す方法等であっても良い。
【００６２】
上述した第２の実施の形態において、ＡＰＩ公開装置２０のリクエスト受信部２３が、ＷＳＤＬファイルを要求するリクエストを受信する度に、ＷＳＤＬ作成部２８がＷＳＤＬファイルを繰り返し作成することを避けるために、ＷＳＤＬ作成部２８が一度作成したＷＳＤＬファイルを例えばＲＡＭ等の主記憶部にキャッシュするようにしても良い。そして、リクエスト受信部２３は、ＷＳＤＬファイルを要求するリクエストを受信した場合、当該リクエストに応じたＷＳＤＬファイルがキャッシュされているか否かを判定し、当該判定結果が肯定的である場合キャッシュされたＷＳＤＬファイルをゲーム開発装置に送信し、当該判定結果が否定的である場合、ＷＳＤＬファイルの作成をＷＳＤＬ作成部２８に要求するようにすれば良い。
【符号の説明】
【００６３】
１０ プラットフォーム
２０ ＡＰＩ公開装置
２１ ＷＳＤＬ公開部
２２ ゲーム認証部
２３ リクエスト受信部
２４ 流出判定部
２５ ゲーム開発者ＤＢ
２６ ゲーム定義情報ＤＢ
２７ ＷＳＤＬＤＢ
２８ ＷＳＤＬ作成部
２９ ＡＰＩＤＢ
３０ データベース装置
３１ ゲームデータベース
３２ 統計データベース
ＮＴ１，ＮＴ２ ネットワーク
【技術分野】
【０００１】
本発明の実施形態は、情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
同系統のアプリケーションプログラムを複数開発したり運用したりするために、アプリケーションプログラムの開発や運用をサポートするためのプラットフォームを用意する環境を想定する。プラットフォームは、１つの情報処理システムであり、複数の情報処理装置が連携することで、アプリケーションプログラムの開発や運用をサポートするための機能をアプリケーションプログラムに提供する。例えば、アプリケーションプログラムとして、携帯端末で実行されるゲームプログラム（単にゲームという）の開発や運用をサポートするプラットフォームがある。各ゲームにおいて、ゲームを利用するユーザ情報を管理することは重要な機能である。この場合、ユーザ情報を管理する機能（ユーザ情報管理機能という）をプラットフォームが提供することで、ゲーム開発者は、同様の機能を実現するためのプログラムを開発する必要がなくなる。また、データベースにアクセスする機能（データベース機能という）をプラットフォームがゲームに提供することで、ゲームに必要なデータをプラットフォームに格納できるようになり、ゲーム開発者はゲーム運用コストを削減することができる。
【０００３】
ゲーム開発者は多数存在するため、また、ゲーム開発者とプラットフォーム開発者とは必ずしも一致しないため、プラットフォームと各ゲームとは物理的に別の情報処理装置上で運用されることを想定するべきである。従って、上述のユーザ情報管理機能やデータベース機能は、ネットワークを介して利用できる必要がある。ネットワークを介して機能を利用する方法として、Ｗｅｂサービスがある。プラットフォームは、Ｗｅｂサービスを介してユーザ管理機能やデータベース機能を利用するためのＡＰＩ（Application Programming Interface）であるＷｅｂサービスＡＰＩを定義し、公開する。各ゲームは公開されたＷｅｂサービスＡＰＩを利用することで、ネットワークを介して機能利用することができる。ＷｅｂサービスＡＰＩの定義情報（ＡＰＩの名称、引数、返り値）やサービス公開アドレスは、ＷＳＤＬ（Web Service Description Language）ファイルに記述される。ＷＳＤＬは、ＡＰＩの定義情報やサービス公開アドレスを明確且つ厳密に定義できるため、開発効率や相互接続性を高めることができる。例えば、ＷＳＤＬファイルがあれば、ＷｅｂサービスＡＰＩを利用するためのメッセージの送受信を行うプログラムを自動的に作成することができる。
【０００４】
プラットフォームは、ユーザ管理機能やデータベース機能等の基本的な機能を利用するためのＷｅｂサービスＡＰＩ（基本ＡＰＩという）とは別に、特別なＷｅｂサービスＡＰＩ（特別ＡＰＩという）を用意することで収入を得ることができる。例えば、高速なデータベースアクセスが可能なＡＰＩや、プラットフォーム側で蓄積したユーザのゲーム利用実績に関する統計データにアクセス可能なＡＰＩ等を特別ＡＰＩとして用意し、その利用に対して課金することができる。ゲームの品質向上や、統計データを利用したゲーム開発を目指すゲーム開発者は、特別ＡＰＩの利用に関してプラットフォーム開発者と契約を交わし、使用料を支払って、特別ＡＰＩを利用する。このとき、プラットフォームとしては、契約を交わしたゲーム開発者にのみ、特別ＡＰＩの定義情報を公開したい。なぜなら、契約を交わしていないゲーム開発者に対して、特別ＡＰＩの定義情報を公開することで、２つの不利益が生じるためである。１つは、契約を交わしていないゲーム開発者が開発したゲームにより、特別ＡＰＩに対するアクセスが生じると、プラットフォームに余分な処理負荷が生じることである。１つは、ＡＰＩの定義情報から、プラットフォーム側がどのようなデータを蓄積しているかを知られてしまうことである。例えば、プラットフォームが統計データを蓄積していることや、統計データとして全ユーザのゲーム使用時間合計等の情報があることを知られてしまう恐れがある。つまり、ＷＳＤＬの明確さや厳密さが仇となってしまう恐れがある。
【０００５】
この不利益を回避するために、ゲーム毎に、そのゲームに対して利用が許可されたＡＰＩのみの定義情報を記述したＷＳＤＬファイルを作成する技術がある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−９２４０７号公報
【特許文献２】特開２００５−７８３３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ゲーム毎にＷＳＤＬファイルを作成して限定公開する場合、各ゲーム開発者が、ＷＳＤＬファイルを二次公開することや、ＷＳＤＬファイルを流出することを許してはならない。それを許せば、上述の不利益を回避できない恐れがあるからである。従って、プラットフォームには、ＷＳＤＬファイルの二次公開や流出が生じた場合に、その流出元を特定できる仕組みが望まれている。流出元を特定できる仕組みは、ＷＳＤＬの流出に対する抑止力となるからである。また、流出元に対して責任を問うこともできるからである。しかしながら、従来の技術では、ＷＳＤＬファイルの流出が生じる状況を想定されておらず、ＷＳＤＬファイルの流出が生じた場合に、その流出元を特定することが困難であった。
【０００８】
本発明は、上記に鑑みてなされたものであって、ＷＳＤＬファイルの流出が生じた場合に、その流出元を特定可能な情報処理装置及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
実施形態の情報処理装置は、アプリケーションプログラムによって各種機能を実現させるために利用される各種ＡＰＩ（Application Programming Interface）を提供する情報処理装置であって、アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に記憶する第１記憶部と、前記アプリケーションプログラムの開発者を特定する開発者情報を記憶する第２記憶部と、前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開する公開部と、Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信する受信部と、前記第１記憶部に記憶された前記ＷＳＤＬファイルのうち、前記第１のアプリケーションプログラムに対応する第１のＷＳＤＬファイルに前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する第１判定部と、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合、前記第２記憶部に記憶された前記開発者情報を用いて、前記第１のＷＳＤＬファイルの流出の有無を判定する第２判定部とを備える。
【図面の簡単な説明】
【００１０】
【図１】第１の実施の形態の情報処理システムの構成を例示する図。
【図２】ＡＰＩ公開装置２０の機能的構成を例示する図。
【図３】契約時の業務フローを示す図。
【図４】ＷＳＤＬファイルを公開する処理の手順を示すフローチャート。
【図５】ゲーム認証処理の手順を示すフローチャート。
【図６】ＡＰＩ公開装置２０が起動時に行う初期化処理を示すフローチャート。
【図７】ＡＰＩ利用要求リクエストに対する処理の手順を示すフローチャート。
【図８】第２の実施の形態のＡＰＩ公開装置２０の機能的構成を例示する図。
【図９】契約時の業務フローを示す図。
【図１０】ＷＳＤＬファイルを公開する処理の手順を示すフローチャート。
【図１１】ＡＰＩ公開装置２０が起動時に行う初期化処理を示すフローチャート。
【図１２】ＡＰＩ利用要求リクエストに対する処理の手順を示すフローチャート。
【発明を実施するための形態】
【００１１】
［第１の実施形態］
図１は、本実施の形態に係る情報処理システムの構成を例示する図である。本実施の形態では、１つのプラットフォーム１０を有する情報処理システムに、アプリケーションプログラムとして各々ゲームＡ，Ｂ，Ｃを各々開発する各情報処理装置（ゲーム開発装置という）がネットワークＮＴ１を介して接続される。ネットワークＮＴ１とは、例えば、インターネット等である。情報処理システムは、プラットフォーム１０を構成するものとして、ゲーム開発装置とは各々異なる情報処理装置であるＡＰＩ公開装置２０及びデータベース装置３０を有する。これらはネットワークＮＴ２を介して接続される。ネットワークＮＴ２は、ネットワークＮＴ１と同様にインターネットであっても良いし、ＬＡＮ（Local Area Network）、イントラネット、イーサネット（登録商標）であっても良い。ＡＰＩ公開装置２０は、Ｗｅｂサービスを介してゲームが各種機能を呼び出すための各種のＡＰＩであるＷｅｂサービスＡＰＩを提供するものであり、各種ＡＰＩの定義情報（ＡＰＩ定義情報という）と、これらの各種機能を各々実現するためのプログラムとを記憶している。データベース装置３０は、各ゲーム固有のデータを記憶するゲームデータベース３１と、ユーザのゲームの利用に履歴等に関する統計データを記憶する統計データベース３２とを有する。具体的に例えば、ゲーム固有のデータは、例えば、ユーザがゲームによって獲得したスコアを示すスコア情報や、ゲーム画面に表示するための画像ファイル等である。統計データは、ゲームごとの利用回数合計やゲームごとの利用時間合計等を示すデータである。各ゲーム開発装置は、ＡＰＩ公開装置２０の提供するＷｅｂサービスＡＰＩを利用することにより、ネットワークＮＴ１を介してプラットフォーム１０の提供する各種機能を実現させる。
【００１２】
ここで、本実施の形態に係るＡＰＩ公開装置２０によって提供されるＷｅｂサービスＡＰＩについて説明する。当該ＷｅｂサービスＡＰＩは、ＤＢ ＡＰＩ、高速ＤＢ ＡＰＩ及び統計データＡＰＩの３つのＡＰＩであるとする。ＤＢ ＡＰＩによって実現される機能はデータベース機能であり、高速ＤＢ ＡＰＩによって実現される機能は高速データベース機能であり、統計データＡＰＩによって実現される機能は統計データ管理機能であるとする。データベース機能は、ゲーム固有のデータにアクセスする機能であり、当該データを、ゲームデータベース３１に記憶させたり、ゲームデータベース３１から読み込んだりする機能である。高速データベース機能は、データベース機能よりも高速に、ゲーム固有のデータにアクセスする機能である。統計データ管理機能は、統計データにアクセスする機能であり、統計データを、統計データベース３２に記憶させたり統計データベース３２から読み出したりする機能である。これらのＡＰＩのうち、ＤＢ ＡＰＩは、基本ＡＰＩであり、高速ＤＢ ＡＰＩ及び統計データＡＰＩは、特別ＡＰＩであるものとする。特別ＡＰＩとは、特別にその利用契約を交わしたゲームによってのみ利用が許諾されるＡＰＩである。図１では、ゲームＣに対してのみ特別ＡＰＩの利用契約が交わされており、ゲームＣが基本ＡＰＩ及び特別ＡＰＩの全てのＡＰＩを利用できることが表されている。また、ゲームＡ及びゲームＢに対して特別ＡＰＩの利用契約が交わされていないため、ゲームＡ及びゲームＢは基本ＡＰＩしか利用できないことが表されている。
【００１３】
ここで、ゲーム開発装置、ＡＰＩ公開装置２０及びデータベース装置３０となる情報処理装置のハードウェア構成について説明する。情報処理装置は、装置全体を制御するＣＰＵ（Central Processing Unit）等の制御部と、各種データや各種プログラムを記憶するＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等の主記憶部と、各種データや各種プログラムを記憶するＨＤＤ（Hard Disk Drive）やＣＤ（Compact Disk）ドライブ装置等の補助記憶部と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、情報処理装置には、情報を表示する表示部と、ユーザの指示入力を受け付けるキーボードやマウス等の操作入力部と、外部装置の通信を制御する通信Ｉ／Ｆ（Interface）とが有線又は無線により各々接続される。
【００１４】
次に、このようなハードウェア構成において、ＡＰＩ公開装置２０の機能的構成について図２を用いて説明する。ＡＰＩ公開装置２０は、ＷＳＤＬ（Web Service Description Language）公開部２１と、ゲーム認証部２２と、リクエスト受信部２３と、流出判定部２４と、ゲーム開発者ＤＢ２５と、ゲーム定義情報ＤＢ２６と、ＷＳＤＬＤＢ２７とを有する。ＷＳＤＬ公開部２１と、リクエスト受信部２３とは、ＡＰＩ公開装置２０のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することと、通信Ｉ／Ｆとにより実現される。ゲーム認証部２２と、流出判定部２４とは各々、ＡＰＩ公開装置２０のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される。ゲーム開発者ＤＢ２５と、ゲーム定義情報ＤＢ２６と、ＷＳＤＬＤＢ２７とは各々、ＨＤＤ等の補助記憶部に記憶されるものである。
【００１５】
ＷＳＤＬＤＢ２７は、ＷＳＤＬ情報をゲーム毎に記憶する。ＷＳＤＬ情報は、ＷＳＤＬＩＤと、ＷＳＤＬファイルとを含む。ＷＳＤＬＩＤは、ＷＳＤＬファイルを識別するためにＷＳＤＬファイル及び当該ＷＳＤＬファイルを含むＷＳＤＬ情報に割り当てられるＩＤである。ＷＳＤＬファイルとは、ゲームに対して利用が許可されたＡＰＩの定義情報(ＡＰＩ定義情報)と、ゲームに対して割り当てられたサービス公開アドレスとを示す。ＡＰＩ定義情報とは、ＡＰＩの名前や引数、返り値を示す。サービス公開アドレスとは、Ｗｅｂサービスを公開するアドレスの情報であり、例えば、ＥＰＲ（End Point Reference）と呼ばれるＵＲＬ形式の文字列で表現される。サービス公開アドレスは、ゲーム毎に異なる。このようなＷＳＤＬファイルを利用することで、Ｗｅｂサービスを利用するゲームの開発効率を向上することができる。
【００１６】
ゲーム定義情報ＤＢ２６は、ゲームに関するゲーム定義情報をゲーム毎に記憶する。ゲーム定義情報は、ゲームＩＤと、ゲーム名と、認証情報と、ＷＳＤＬＩＤとを含む。ゲームＩＤは、ゲームを一意に識別するためにゲームに割り当てられる識別情報である。ゲーム名は、ゲームの名称である。認証情報とは、ゲームを認証するための情報である。例えば、認証情報は、パスワードの文字列やクライアント証明書を示す。ＷＳＤＬＩＤは、当該ゲームに対して公開が許可されたＷＳＤＬファイルに割り当てられたＷＳＤＬＩＤを示す。
【００１７】
ゲーム開発者ＤＢ２５は、ゲームの開発者を特定するゲーム開発者情報を各々記憶する。ゲーム開発者情報は、ゲーム開発者ＩＤと、ゲーム開発者名と、ゲームＩＤリストとを含む。ゲーム開発者ＩＤは、ゲーム開発者を識別するためにゲーム開発者に割当られるＩＤである。ゲーム開発者名は、ゲーム開発者名称である。ゲームＩＤリストは、当該ゲーム開発者が開発しているゲームのゲームＩＤを全て示す。
【００１８】
ＷＳＤＬ公開部２１は、ＡＰＩの定義情報をＷＳＤＬファイルとして公開する。本実施の形態においてはＷＳＤＬファイルの公開は、利便性を考慮して、インターネット等のＮＴ１を介して実現するものとする。即ち、ゲーム開発者が操作するゲーム開発装置が、ＡＰＩ公開装置２０からネットワークＮＴ１を介してＷＳＤＬファイルを受信することにより取得する。これを可能にするため、プラットフォーム１０は、ＷＳＤＬ公開部２１をネットワークＮＴ１に公開し、ゲーム開発装置からのＨＴＴＰリクエストを受け付ける構成とする。この場合、ゲーム開発装置は、例えば、ＨＴＴＰクライアントとして機能する。ＨＴＴＰクライアントには、Ｗｅｂブラウザ等がある。このような構成において、ゲーム開発装置は、ＷＳＤＬファイルを要求するリクエストであって、ゲームに割り当てられたゲームＩＤ及び認証情報が付加されたリクエストをＡＰＩ公開装置２０に送信する。このリクエストをＷＳＤＬ公開部２１が受信すると、当該リクエストに付加されたゲームＩＤ及び認証情報を後述のゲーム認証部２２に渡してゲーム認証処理の実行を要求する。ゲーム認証処理の結果、ＷＳＤＬ公開部２１は、ゲーム認証部２２からゲーム定義情報を受け取ると、当該ゲーム定義情報を用いて、当該リクエストに応じたＷＳＤＬファイルをＷＳＤＬＤＢ２７から取得してこれをゲーム開発装置に送信する。
【００１９】
リクエスト受信部２３は、ゲームを開発するゲーム開発装置がプラットフォーム１０に対して送信した、ＡＰＩの利用を要求するリクエストであって、ゲームＩＤ及び認証情報と、当該ＡＰＩのＡＰＩ定義情報及びサービス公開アドレスが付加されたリクエストを受信するものである。このリクエストの受信に先立って、ＡＰＩ公開装置２０の起動時に、リクエスト受信部２３は、ゲームに対してどのようなＡＰＩをどのサービス公開アドレスで公開しているかを予め把握するための初期化処理を行う。初期化処理では、リクエスト受信部２３は、ＷＳＤＬＤＢ２７を参照して、当該ＡＰＩ公開装置２０で公開し得るＡＰＩのＡＰＩ定義情報及びサービス公開アドレスを取得して、ＡＰＩの利用を要求するリクエストの待ち受けを開始する。その後、リクエスト受信部２３は、ＡＰＩの利用を要求するリクエストを受信すると、当該リクエストに付加されたＡＰＩ定義情報及びサービス公開アドレスを用いて、当該ＡＰＩ公開装置２０が公開し得るＡＰＩであるか否かを判定する。当該判定の結果に応じて、リクエスト受信部２３は、当該リクエストに付加されたゲームＩＤ及び認証情報を後述のゲーム認証部２２に渡してゲーム認証処理の実行を要求する。ゲーム認証処理の結果、リクエスト受信部２３は、ゲーム認証部２２からゲーム定義情報を取得すると、当該ゲーム定義情報及び当該リクエストを後述の流出判定部２４に渡す。流出判定部２４の判定の結果、リクエスト受信部２３は、流出判定部２４からエラーを受け取ると、当該リクエストを送信したゲーム開発装置にエラーを送信する。
【００２０】
ゲーム認証部２２は、ＷＳＤＬ公開部２１やリクエスト受信部２３の要求に応じて、ゲームＩＤ及び認証情報を用いて、ゲーム定義情報ＤＢ２６を参照して、当該ゲームを認証するゲーム認証処理を行う。当該ゲームの認証に成功した場合、ゲーム認証部２２は、ゲーム定義情報ＤＢ２６から該当のゲーム定義情報を得て、これをゲーム認証処理の実行の要求元であるＷＳＤＬ公開部２１やリクエスト受信部２３に返す。一方、ゲームの認証に失敗した場合、ゲーム認証部２２は、ゲーム認証処理の実行の要求元であるＷＳＤＬ公開部２１やリクエスト受信部２３にエラーを返す。
【００２１】
流出判定部２４は、リクエスト受信部２３から渡されたゲーム定義情報及びリクエストを用いて、ゲーム開発者ＤＢ２５、ゲーム定義情報ＤＢ２６及びＷＳＤＬＤＢ２７を参照して、ＷＳＤＬファイルの流出の有無を判定する。当該判定の結果、ＷＳＤＬファイルが流出したと判定した場合、流出判定部２４は、リクエスト受信部２３にエラーを返す。一方、当該判定の結果、ＷＳＤＬファイルが流出していないと判定した場合、流出判定部２４は、当該ゲーム定義情報及びリクエストを、当該リクエストによって利用が要求されたＡＰＩに渡す。本実施の形態において利用され得るＡＰＩは、上述したように、ＤＢ ＡＰＩ、高速ＤＢ ＡＰＩ及び統計データＡＰＩである。ここで、これらのＡＰＩの概要について簡単に説明する。
【００２２】
ＤＢ ＡＰＩとしては、例えば、ｐｕｔ（キー、データ）や、ｇｅｔ（キー）というＡＰＩがある。ｐｕｔ（キー、データ）とは、データを、キーと関連付けてゲームデータベース３１に保存するＡＰＩである。ｇｅｔ（キー）とは、キーに一致するデータを、ゲームデータベース３１から取得するＡＰＩである。その他、ＤＢ ＡＰＩとして、複数のデータを一度にゲームデータベース３１に保存するＡＰＩがあっても良い。
【００２３】
高速ＤＢ ＡＰＩとしては、例えば、ｆａｓｔＰｕｔ（キー、データ）や、ｆａｓｔＧｅｔ（キー）がある。ｆａｓｔＰｕｔ（キー、データ）とは、データを、キーと関連付けてゲームデータベース３１に高速に保存するＡＰＩである。ｆａｓｔＧｅｔ（キー）は、キーに一致するデータを、データベース装置３０から高速に取得するＡＰＩである。高速ＤＢ ＡＰＩによってデータに高速にアクセスすることにより、例えば、リクエストやレスポンスのメッセージを圧縮することによる通信時間の削減や、リクエスト処理プロセスの優先度付け、キャッシュの利用等が実現できる。
【００２４】
統計データＡＰＩとしては、例えば、ｇｅｔＵｓｅＣｏｕｎｔ（ゲームＩＤ）や、ｇｅｔＵｓｅＴｉｍｅ（ゲームＩＤ）がある。ｇｅｔＵｓｅＣｏｕｎｔ（ゲームＩＤ）は、統計データによって示される利用回数合計を取得するＡＰＩである。ｇｅｔＵｓｅＴｉｍｅ（ゲームＩＤ）は、統計データによって示される利用時間合計を取得するＡＰＩである。
【００２５】
次に、本実施の形態に係るゲーム開発者とプラットフォーム開発者との業務フローについて説明する。ゲーム開発者は、ゲームの開発にあたり、プラットフォーム開発者と基本契約又は特別契約を交わす必要がある。これらの契約によって、ゲーム開発者が開発するゲームの利用できる機能及びＡＰＩが決まる。図３は、契約時の業務フローを示す図である。プラットフォーム開発者は、ゲーム開発者名を把握する（業務ステップＧ１）。プラットフォーム開発者は、ゲーム開発者に固有のゲーム開発者ＩＤを割り当てる（業務ステップＧ２）。プラットフォーム開発者は、ゲーム名と、ゲームが利用するＡＰＩを把握する（業務ステップＧ３）。プラットフォーム開発者は、ゲームに対して固有に割り当てるゲームＩＤ、サービス公開アドレス及び認証情報を決定し、これらをゲーム開発者に教える（業務ステップＧ４）。後述するように、契約を交わしたゲームのゲーム開発者により操作されるゲーム開発装置では、Ｗｅｂサービスを介して当該ゲームからのＡＰＩの利用を要求するリクエストを送信する際に、当該リクエストに当該ゲームＩＤ及び認証情報を付加することで、ＡＰＩ公開装置２０において当該ゲームの認証に成功させることが可能になる。
【００２６】
プラットフォーム開発者は、ＡＰＩ公開装置２０の有する操作入力部を介して、ゲームが利用するＡＰＩのＡＰＩ定義情報と、業務ステップＧ４で決定したサービス公開アドレスとを記述したＷＳＤＬファイルを作成する操作入力を行う（業務ステップＧ５）。当該操作入力を受け付けたＡＰＩ公開装置２０では、ＷＳＤＬファイルが作成される。ここで、ゲーム毎、即ち、ＷＳＤＬファイル毎に異なるサービス公開アドレスが記述されたＷＳＤＬファイルが作成されることで、当該ＷＳＤＬファイルが流出した場合にその流出元を特定することが可能になる。プラットフォーム開発者は、ＷＳＤＬファイルに固有のＷＳＤＬＩＤを割り当て、当該ＷＳＤＬファイル及びＷＳＤＬＩＤを含むＷＳＤＬ情報をＷＳＤＬＤＢ２７に登録する操作入力を行う（業務ステップＧ６）。当該操作入力を受け付けたＡＰＩ公開装置２０では、ＷＳＤＬファイルがＷＳＤＬＤＢ２７に記憶される。プラットフォーム開発者は、業務ステップＧ４で決定したゲーム名、ゲームＩＤ、認証情報及び業務ステップＧ６で割り当てたＷＳＤＬＩＤを含むゲーム定義情報を作成する操作入力を行い、当該ゲーム定義情報をゲーム定義情報ＤＢ２６に登録する操作入力を行う（業務ステップＧ７）。当該操作入力を受け付けたＡＰＩ公開装置２０では、ゲーム定義情報が作成されてこれがゲーム定義情報ＤＢ２６に記憶される。プラットフォーム開発者は、ゲーム開発者ＩＤ、開発者名、業務ステップＧ４で割り当てたゲームＩＤを含むゲーム開発者情報を作成する操作入力を行い、当該ゲーム開発者情報をゲーム開発者ＤＢ２５に登録する操作入力を行う（業務ステップＧ８）。当該操作入力を受け付けたＡＰＩ公開装置２０では、ゲーム開発者情報が作成されてこれがゲーム開発者ＤＢに記憶される。
【００２７】
次に、ＡＰＩ公開装置２０が行う処理の手順について説明する。まず、ＡＰＩ公開装置２０がゲーム開発装置からの要求に応じてＷＳＤＬファイルを公開する処理の手順について図４を用いて説明する。ゲーム開発者は、プラットフォーム１０がＷｅｂサービスを介して提供するＡＰＩを利用してゲームを開発するため、当該ＡＰＩのＡＰＩ定義情報が示されるＷＳＤＬファイルをプラットフォーム１０から取得する必要がある。このため、ゲーム開発者が、ゲーム開発装置の操作入力部を介してＷＳＤＬファイルを取得するための操作入力を行うと、ゲーム開発装置は、当該操作入力を受け付け、ＡＰＩ公開装置２０にＷＳＤＬファイルを要求するリクエストであり、ゲームに割り当てられたゲームＩＤ及び認証情報を付加したリクエストを送信する。当該リクエストに認証情報を付加することは、例えば、認証情報がパスワードの文字列を示すものである場合、以下のようにして実現される。ＡＰＩ公開装置２０のＷＳＤＬ公開部２１が、ゲーム開発装置のＷｅｂブラウザ上にゲームＩＤ及びパスワードの文字列を入力するためのダイアログを表示させ、ゲーム開発者にゲームＩＤとパスワードの文字列を入力させる。そして、ゲーム開発装置のＷｅｂブラウザが、入力されたゲームＩＤとパスワードの文字列をリクエストに付加し、ＡＰＩ公開装置２０のＷＳＤＬ公開部２１に送信することで、ＨＴＴＰダイジェスト認証を行うことができる。
【００２８】
ＡＰＩ公開装置２０のＷＳＤＬ公開部２１は、当該リクエストを受信すると（ステップＳ１）、ゲーム認証部２２に当該リクエストを渡してゲーム認証処理の実行を要求する（ステップＳ２）。ゲーム認証処理の詳細については後述する。その後、ＷＳＤＬ公開部２１は、ゲーム認証処理の結果をゲーム認証部２２から受け取り、ゲーム定義情報が得られたか否かを判定する（ステップＳ３）。ゲーム定義情報が得られなかった場合は(ステップＳ３：ＮＯ)、ゲームの認証は失敗である。この場合、ＷＳＤＬ公開部２１は、ゲームの認証が失敗した旨を示すエラーメッセージをゲーム開発装置に送信する（ステップＳ４）。ゲーム定義情報が得られた場合は（ステップＳ３：ＹＥＳ）、ゲームの認証は成功である。この場合、ＷＳＤＬ公開部２１は、ＷＳＤＬＤＢ２７にアクセスして、ゲーム定義情報に含まれるＷＳＤＬＩＤと同一のＷＳＤＬＩＤを含むＷＳＤＬ情報を取得する（ステップＳ５）。そして、ＷＳＤＬ公開部２１は、取得したＷＳＤＬ情報に含まれるＷＳＤＬファイルをゲーム開発装置に送信する（ステップＳ６）。
【００２９】
次に、ステップＳ２でゲーム認証部２２が行うゲーム認証処理の手順について図５を用いて説明する。ゲーム認証部２２は、ＷＳＤＬ公開部２１からリクエストを受け取ると、当該リクエストに付加されているゲームＩＤ及び認証情報を取得する（ステップＳ１０）。当該リクエストにゲームＩＤ及び認証情報が付加されていなければ、ゲーム認証部２２は、ゲームの認証が失敗した旨を示すエラーをＷＳＤＬ公開部２１に返す。
【００３０】
ゲーム認証部２２は、ゲーム定義情報ＤＢ２６にアクセスして（ステップＳ１１）、ステップＳ１０で取得したゲームＩＤと同一のゲームＩＤ及びステップＳ１０で取得した認証情報と同一の認証情報を含むゲーム定義情報が存在するか否かを判定する（ステップＳ１２）。該当するゲーム定義情報が存在する場合（ステップＳ１２：ＹＥＳ）、ゲームの認証は成功となる。この場合、ゲーム認証部２２は、該当のゲーム定義情報をＷＳＤＬ公開部２１に返す（ステップＳ１３）。該当のゲーム定義情報が存在しない場合（ステップＳ１２：ＮＯ）、ゲームの認証は失敗となる。この場合、ゲーム認証部２２は、ＷＳＤＬ公開部２１に何も返さず（ステップＳ１４）、当該ゲーム認証処理を終了する。
【００３１】
以上のように、契約時に決定された認証情報を利用することで、ＡＰＩ公開装置２０は、未契約のゲームを開発するゲーム開発装置から送信されたリクエストを破棄することができる。
【００３２】
次に、ＡＰＩの利用を要求するリクエストに対する処理の手順について説明する。ここで、まず、ＡＰＩ公開装置２０が起動時に行う初期化処理について図６を用いて説明する。ＡＰＩ公開装置２０が起動すると、リクエスト受信部２３は、ＷＳＤＬＤＢ２７に記憶されている全てのＷＳＤＬ情報に含まれるＷＳＤＬファイルを参照して（ステップＳ２０）、当該ＷＳＤＬファイルによって示されるＡＰＩ定義情報及びサービス公開アドレスを用いて、どのようなＡＰＩをどのサービス公開アドレスで公開するべきかを判定する（ステップＳ２１）。即ち、リクエスト受信部２３は、当該ＡＰＩ公開装置２０が公開し得るＡＰＩのＡＰＩ定義情報及びサービス公開アドレスを取得して、ＡＰＩの利用を要求するリクエストの待ち受けを開始する。
【００３３】
次に、ＡＰＩの利用を要求するリクエストをＡＰＩ公開装置２０がゲーム開発装置から受信した場合の処理の手順について図７を用いて説明する。ゲーム開発装置は、ＡＰＩの利用を要求するリクエストであり、当該ＡＰＩを利用するゲームのゲームＩＤ及び認証情報と、当該ＡＰＩのＡＰＩ定義情報及びサービス公開アドレスとを各々付加したリクエストを送信する。以下、このゲームのことをゲームＧ、このリクエストのことをリクエストＲと呼ぶ。ここでは、リクエストはＳＯＡＰリクエストを想定する。ＡＰＩ公開装置２０のリクエスト受信部２３は、当該リクエストＲを受信すると、これをゲーム認証部２２に渡してゲーム認証処理の実行を要求する（ステップＳ３０）。当該ゲーム認証処理の手順は上述の図５と略同様であるため、その詳細な説明は省略する。但し、ステップＳ１０でゲーム認証部２２がリクエストを受け取るのはリクエスト受信部２３からであり、当該リクエストにゲームＩＤ及び認証情報が付加されていない場合にゲーム認証部２２がエラーを返す先はリクエスト受信部２３であり、ステップＳ１３でゲーム認証部２２がゲーム定義情報を返す先はリクエスト受信部２３である。
【００３４】
リクエスト受信部２３は、ゲーム認証処理の結果、ゲーム認証部２２からゲーム定義情報が得られたかを否かを判定する（ステップＳ３１）。ゲーム定義情報が得られなかった場合（ステップＳ３１：ＮＯ）、ゲームＧの認証は失敗である。この場合、ステップＳ３３に進む。一方、ゲーム定義情報が得られた場合（ステップＳ３１：ＹＥＳ）、ゲームＧの認証は成功である。この場合、リクエスト受信部２３は、リクエストＲに付加されたＡＰＩ定義情報及びサービス公開アドレスを参照して、当該ＡＰＩ公開装置２０が公開し得るＡＰＩであるか否かを判定する（ステップＳ３２）。具体的には、リクエスト受信部２３は、上述の初期化処理で取得したＡＰＩ定義情報及びサービス公開アドレスに基づいて、リクエストＲに付加されたＡＰＩ定義情報及びサービス公開アドレスに該当するＡＰＩ（ＡＰＩαとする）が存在するか否かを判定する。該当のＡＰＩαが存在しない場合（ステップＳ３２：ＮＯ）、ステップＳ３３に進む。一方、該当のＡＰＩαが存在する場合（ステップＳ３２：ＹＥＳ）、リクエスト受信部２３は、リクエストＲと、ゲームＧのゲーム定義情報とを、流出判定部２４に渡す（ステップＳ３４）。
【００３５】
流出判定部２４は、リクエストＲ及びゲーム定義情報を受け取ると、ゲーム定義情報に含まれるＷＳＤＬＩＤと同一のＷＳＤＬＩＤを含むＷＳＤＬ情報を特定し、当該ＷＳＤＬ情報に含まれるＷＳＤＬファイルをＷＳＤＬＤＢ２７から取得する（ステップＳ３５）。次いで、流出判定部２４は、リクエストＲによって要求されたＡＰＩαの利用に対する正当性を確認する（ステップＳ３６）。つまり、流出判定部２４は、ゲームＧが、ＡＰＩαの利用が許可されたゲームであるか否かを判定する。以下の２つの条件(a),(b)を満たす場合、リクエストＲによって要求されたＡＰＩαの利用は正当であると流出判定部２４は判定する。
(a)ステップＳ３５で取得したＷＳＤＬファイルに、ＡＰＩαのＡＰＩ定義情報が示されている
(b)ステップＳ３５で取得したＷＳＤＬファイルによって示されているサービス公開アドレスが、リクエストＲに付加されたサービス公開アドレスと同一である
【００３６】
リクエストＲによって要求されたＡＰＩαの利用は正当であると判定した場合（ステップＳ３６：ＹＥＳ）、流出判定部２４は、リクエストＲとゲームＧのゲーム定義情報とをＡＰＩαへ渡す（ステップＳ３７）。ＡＰＩαは、上述したＤＢ ＡＰＩ、高速ＤＢ ＡＰＩ及び統計データＡＰＩのうち少なくとも１つである。
【００３７】
一方、リクエストＲによって要求されたＡＰＩαの利用は正当でないと判定した場合（ステップＳ３６：ＮＯ）、この時点では、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルが流出したとはまだ判定できない。なぜなら、ゲームＧと、ＡＰＩαの利用が許可されたゲームとのゲーム開発者が同一である可能性が残っているためである。このため、流出判定部２４は、ゲーム開発者ＤＢ２５に記憶されている全てのゲーム開発者情報を参照して(ステップＳ３８)、ＡＰＩαの利用が許可されたゲームのゲーム開発者と、ゲームＧのゲーム開発者とが同一であるか否かを判定する（ステップＳ３９）。具体的な判定の方法は例えば以下の通りである。流出判定部２４は、ゲーム開発者ＤＢ２５に記憶されている全てのゲーム開発者情報に含まれるゲームＩＤリストによって示されるゲームＩＤを参照して、ゲームＧのゲームＩＤを示すゲームＩＤリストを含むゲーム開発者情報を取得する。流出判定部２４は、ゲーム定義情報ＤＢ２６を参照して、取得したゲーム開発者情報に含まれるゲームＩＤリストによって示されるゲームＩＤと同一のゲームＩＤを含むゲーム定義情報を取得する。流出判定部２４は、ＷＳＤＬＤＢ２７を参照して、取得したゲーム定義情報に含まれるＷＳＤＬＩＤと同一のＷＳＤＬＩＤを含むＷＳＤＬ情報を取得し、当該ＷＳＤＬ情報に含まれるＷＳＤＬファイルを取得する。流出判定部２４は、当該ＷＳＤＬファイルにＡＰＩαのＡＰＩ定義情報が含まれていれば、ＡＰＩαの利用が許可されたゲームのゲーム開発者と、ゲームＧのゲーム開発者とが同一であると判定し、当該ＷＳＤＬファイルにＡＰＩαのＡＰＩ定義情報が含まれていなければ、双方のゲーム開発者が同一ではないと判定する。
【００３８】
双方のゲーム開発者が同一である場合（ステップＳ３９：ＹＥＳ）、ゲームＧのゲーム開発者は、ＡＰＩαのＡＰＩ定義情報を知っていると考えられるため、リクエストＲの送信は、ゲーム開発上のミスだと判定できる。従って、この場合、流出判定部２４は、ＷＳＤＬファイルが流出した可能性として、流出の重要度を「低」と判定して（ステップＳ４０）、ステップＳ４２に進む。一方、双方のゲーム開発者が異なる場合（ステップＳ３９：ＮＯ）、ゲームＧの開発者は、ＡＰＩαのＡＰＩ定義情報を知らないはずである。従って、この場合、流出判定部２４は、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルが流出した可能性が高いと判定し、流出の重要度を「高」と判定して（ステップＳ４１）、ステップＳ４２に進む。尚、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルがどのゲーム開発者に公開されているかは、ゲーム開発者ＤＢ２５とゲーム定義情報ＤＢ２６及びＷＳＤＬＤＢ２７を参照することで確認することができる。具体的には、流出判定部２４は、ゲーム定義情報ＤＢ２６を参照して、ＷＳＤＬＤＢ２７に記憶されたＷＳＤＬ情報に当該ＷＳＤＬファイルと共に含まれるＷＳＤＬＩＤと同一のＷＳＤＬＩＤを含むゲーム定義情報を取得する。流出判定部２４は、ゲーム開発者ＤＢ２５を参照して、取得したゲーム定義情報に含まれるゲームＩＤと同一のゲームＩＤを示すゲームＩＤリストを含むゲーム開発者情報を取得することにより、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルの流出元のゲーム開発者を特定することができる。
【００３９】
ステップＳ４２では、流出判定部２４は、プラットフォーム開発者にＷＳＤＬファイルの流出の発生を通知する。通知方法には、電話や電子メール等を利用する方法がある。ＷＳＤＬファイルの流出の重要度が「高」の場合には電話を利用し、ＷＳＤＬファイルの流出の重要度が「低」の場合には電子メールを利用する等の使い分けが可能である。尚、電話を利用する場合には、プラットフォーム開発者の電話番号をＡＰＩ公開装置２０は予め記憶しておき、当該電話番号に発信することで、電話を掛けるようにしても良いし、ＡＰＩ公開装置２０に通信端末が別途接続されており、当該通信端末を介して予め記憶された電話番号に発信させることで、電話を掛けるようにしても良い。電子メールを利用する場合には、ＡＰＩ公開装置２０はプラットフォーム開発者の電子メールアドレスを予め記憶しておき、当該電子メールアドレスを含み、ＷＳＤＬファイルの流出が発生した旨を示す電子メールを作成してこれを送信するようにすれば良い。その後、流出判定部２４は、リクエスト受信部２３に権限エラーを返す（ステップＳ４４）。リクエスト受信部２３は、当該権限エラーを受け取ると、ステップＳ３３に進む。ステップＳ３３では、リクエスト受信部２３は、ゲームＧの認証に失敗した旨を示すエラーメッセージを、ゲームＧのゲーム開発装置に送信する。
【００４０】
以上のように、本実施の形態においては、ＡＰＩ公開装置２０は、ゲーム毎に個別のサービス公開アドレスを割り当て、個別のＷＳＤＬファイルを作成して公開する。これにより、ＷＳＤＬファイルが流出し、特別ＡＰＩのＡＰＩ定義情報を知らないはずのゲームによる特別ＡＰＩの利用を要求するリクエストを送信しても、ＡＰＩ公開装置２０は当該リクエストを破棄することができる。即ち、ＡＰＩ公開装置２０は、ＡＰＩの不正利用を検出してこれを排除することができる。また、ＡＰＩ公開装置２０は、ＷＳＤＬファイルの流出元を特定することができる。この結果、ＷＳＤＬファイルの流出の抑制や、ＷＳＤＬファイルの流出元に対して責任を問うことが可能となる。
【００４１】
[第２の実施形態]
次に、情報処理装置及びプログラムの第２の実施の形態について説明する。尚、上述の第１の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
【００４２】
第１の実施形態のように、プラットフォーム開発者が、ゲーム毎にＡＰＩ定義情報及びサービス公開アドレスを記述したＷＳＤＬファイルを作成する操作入力を行う場合、ＷＳＤＬファイルの内容に記述ミスが生じる可能性がある。ＷＳＤＬファイルの記述に誤りがあると、本来は公開したくないＡＰＩのＡＰＩ定義情報が公開されてしまう恐れがある。また、ＷＳＤＬファイルの読み手（ゲーム開発者等）が、ＡＰＩ定義情報を理解できない恐れがある。このような問題を回避するため、本実施の形態においては、ＡＰＩ公開装置２０が、ＷＳＤＬファイルを自動で作成する。
【００４３】
図８は、本実施の形態におけるＡＰＩ公開装置２０の機能的構成を例示する図である。本実施の形態に係るＡＰＩ公開装置２０は、上述のＷＳＤＬ公開部２１と、ゲーム認証部２２と、リクエスト受信部２３と、流出判定部２４と、ゲーム開発者ＤＢ２５と、ゲーム定義情報ＤＢ２６とに加え、ＷＳＤＬ作成部２８と、ＡＰＩＤＢ２９とを更に有し、ＷＳＤＬＤＢ２７を有さない。ＷＳＤＬ作成部２８は、ＡＰＩ公開装置２０のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される。ＡＰＩＤＢ２９は、ＨＤＤ等の補助記憶部に記憶されるものである。また、本実施の形態においては、ゲーム定義情報ＤＢ２６に記憶されるゲーム定義情報が上述の第１の実施の形態と異なる。ＷＳＤＬ公開部２１の機能の一部及びリクエスト受信部２３の機能の一部が上述の第１の実施の形態と異なる。
【００４４】
ＡＰＩＤＢ２９は、ＡＰＩ公開装置２０が提供するＡＰＩに関するＡＰＩ情報を記憶する。ＡＰＩ情報は、ＡＰＩＩＤと、ＡＰＩ定義情報とを含む。ＡＰＩＩＤは、ＡＰＩを識別するためにＡＰＩに割り当てられるＩＤである。プラットフォーム開発者は、ゲーム開発者と契約を交わす前に、ＡＰＩ公開装置２０において、ＡＰＩ公開装置２０が提供するＡＰＩに関するＡＰＩ情報をＡＰＩＤＢ２９に登録する操作入力を行って、当該ＡＰＩ情報をＡＰＩＤＢ２９に記憶させる。
【００４５】
本実施の形態に係るゲーム定義情報ＤＢ２６に記憶されるゲーム定義情報は、ゲームＩＤと、ゲーム名と、認証情報との他、ＡＰＩＩＤリストと、サービス公開アドレスとを含む。ＡＰＩＩＤリストは、当該ゲームに対して利用が許可されているＡＰＩのＡＰＩＩＤを全て示す。サービス公開アドレスは、上述と同様に各ゲームに固有に割り当てられるものである。
【００４６】
ＷＳＤＬ公開部２１は、ＷＳＤＬファイルを要求するリクエストを受信すると、第１の実施の形態と同様にしてゲーム認証部２２にゲーム認証処理の実行を要求するが、ゲーム認証部２２からゲーム定義情報を受け取ると、本実施の形態においては、当該ゲーム定義情報をＷＳＤＬ作成部２８に渡してＷＳＤＬファイルの作成を要求する。そして、ＷＳＤＬ公開部２１は、当該要求に応じて作成されたＷＳＤＬファイルをＷＳＤＬ作成部２８から受け取ると、これをゲーム開発装置に送信する。
【００４７】
リクエスト受信部２３は、第１の実施の形態で説明した初期化処理において、当該ＡＰＩ公開装置２０が公開し得るＷＳＤＬファイルの作成をＷＳＤＬ作成部２８に要求する。そして、リクエスト受信部２３は、当該要求に応じて作成されたＷＳＤＬファイルをＷＳＤＬ作成部２８から受け取ると、当該ＷＳＤＬファイルによって示されるＡＰＩ定義情報及びサービス公開アドレスを取得して、Ｗｅｂサービスの利用を要求するリクエストの待ち受けを開始する。
【００４８】
ＷＳＤＬ作成部２８は、ＷＳＤＬ公開部２１やリクエスト受信部２３の要求に応じて、ゲーム定義情報と、ＡＰＩ情報とを用いて、ＷＳＤＬファイルを作成する。具体的には、ＷＳＤＬ作成部２８は、ゲーム定義情報に含まれるＡＰＩＩＤリストによって示されるＡＰＩＩＤを各々含むＡＰＩ情報に各々含まれるＡＰＩ定義情報を取得し、ゲーム定義情報に含まれるサービス公開アドレスと合わせてＷＳＤＬファイルを作成する。そして、ＷＳＤＬ作成部２８は、作成したＷＳＤＬファイルを要求元のＷＳＤＬ公開部２１やリクエスト受信部２３に渡す。
【００４９】
次に、本実施の形態に係るゲーム開発者とプラットフォーム開発者との業務フローについて説明する。図９は、本実施の形態に係る契約時の業務フローを示す図である。業務ステップＧ１〜Ｇ４は第１の実施の形態と同様である。業務ステップＧ４の後は、プラットフォーム開発者は、ＷＳＤＬファイルを作成する操作入力及び当該ＷＳＤＬファイルを含むＷＳＤＬ情報をＷＳＤＬＤＢ２７に登録する操作入力を行うことなく、上述と同様の業務ステップＧ７〜Ｇ８を行う。
【００５０】
次に、ＡＰＩ公開装置２０が行う処理の手順について説明する。まず、ＡＰＩ公開装置２０がゲーム開発装置からの要求に応じてＷＳＤＬファイルを公開する処理の手順について図１０を用いて説明する。ステップＳ１〜Ｓ４は第１の実施の形態と同様である。ステップＳ３でゲーム定義情報を得られた場合（ステップＳ３：ＹＥＳ）、ＷＳＤＬ公開部２１は、得られたゲーム定義情報をＷＳＤＬ作成部２８に渡す（ステップＳ５０）。ＷＳＤＬ作成部２８は、ゲーム定義情報を受け取ると、ＡＰＩＤＢ２９を参照して、当該ゲーム定義情報に含まれるＡＰＩＩＤリストによって示されるＡＰＩＩＤを各々含むＡＰＩ情報に各々含まれるＡＰＩ定義情報を取得する（ステップＳ５１）。そして、ＷＳＤＬ作成部２８は、当該ＡＰＩ定義情報と、当該ゲーム定義情報に含まれるサービス公開アドレスとを示すＷＳＤＬファイルを作成して、これをＷＳＤＬ公開部２１に渡す（ステップＳ５２）。ＷＳＤＬ公開部２１は、ＷＳＤＬファイルを受け取ると、これをゲーム開発装置に送信する（ステップＳ５３）。
【００５１】
次に、ＡＰＩの利用を要求するリクエストに対する処理の手順について説明する。ここで、まず、ＡＰＩ公開装置２０が起動時に行う初期化処理について図１１を用いて説明する。ＡＰＩ公開装置２０が起動すると、リクエスト受信部２３は、ＡＰＩ公開装置２０が公開し得る全てのＷＳＤＬファイルの作成をＷＳＤＬ作成部２８に要求する（ステップＳ６０）。ＷＳＤＬ作成部２８は、ゲーム定義情報ＤＢ２６に記憶されている全てのゲーム定義情報を参照して、ゲーム定義情報に含まれるＡＰＩＩＤリスト及びサービス公開アドレスを取得する（ステップＳ６１）。次いで、ＷＳＤＬ作成部２８は、ＡＰＩＤＢ２９を参照して、ゲーム毎に、ＡＰＩＩＤリストによって示されるＡＰＩＩＤを各々含むＡＰＩ情報に各々含まれるＡＰＩ定義情報を取得し、当該ＡＰＩ定義情報と、当該ゲームのゲーム定義情報に含まれるサービス公開アドレスとを示すＷＳＤＬファイルを作成する（ステップＳ６２）。このようにしてＷＳＤＬ作成部２８はゲーム毎のＷＳＤＬファイルを作成して、これらをリクエスト受信部２３に渡す。リクエスト受信部２３は、当該ＷＳＤＬファイルを受け取ると、当該ＷＳＤＬファイルによって示されるＡＰＩ定義情報及びサービス公開アドレスを取得して、Ｗｅｂサービスの利用を要求するリクエストの待ち受けを開始する（ステップＳ６３）。
【００５２】
次に、ＡＰＩの利用を要求するリクエストをＡＰＩ公開装置２０がゲーム開発装置から受信した場合の処理の手順について図１２を用いて説明する。ゲーム開発装置が、第１の実施の形態と同様に、ＡＰＩの利用を要求するリクエストをＡＰＩ公開装置２０に送信する。以下、このゲームのことをゲームＧ、このリクエストのことをリクエストＲと呼ぶ。ステップＳ３０〜Ｓ３４は第１の実施の形態と同様である。ステップＳ３４の後、ステップＳ７０では、流出判定部２４は、リクエストＲ及びゲーム定義情報を受け取ると、ゲーム定義情報に含まれるＡＰＩＩＤリストによって示されるＡＰＩＩＤを含むＡＰＩ情報を取得する。次いで、流出判定部２４は、リクエストＲによって要求されたＡＰＩαの利用の正当性を確認する（ステップＳ７１）。以下の２つの条件(c),(d)を満たす場合、リクエストＲによって要求されたＡＰＩαの利用は正当であると流出判定部２４は判定する。
(c)ステップＳ７０で取得したＡＰＩ情報のうち、ＡＰＩαのＡＰＩ定義情報を含むＡＰＩ情報が存在する
(d)リクエストＲに付加されたサービス公開アドレスと、ゲーム定義情報に含まれるサービス公開アドレスとが同一である
【００５３】
リクエストＲによって要求されたＡＰＩαの利用は正当であると判定した場合（ステップＳ７１：ＹＥＳ）、上述と同様にステップＳ３７に進む。一方、リクエストＲによって要求されたＡＰＩαの利用は正当でないと判定した場合（ステップＳ７１：ＮＯ）、流出判定部２４は、第１の実施の形態と同様に、ゲーム開発者ＤＢ２５に記憶されている全てのゲーム開発者情報を参照して(ステップＳ３８)、ＡＰＩαの利用が許可されたゲームのゲーム開発者と、ゲームＧのゲーム開発者とが同一であるか否かを判定する（ステップＳ３９）。但し、本実施の形態においては、具体的な判定の方法が第１の実施の形態と異なる。流出判定部２４は、ゲーム開発者ＤＢ２５に記憶されている全てのゲーム開発者情報に含まれるゲームＩＤリストによって示されるゲームＩＤを参照して、ゲームＧのゲームＩＤを示すゲームＩＤリストを含むゲーム開発者情報を取得する。流出判定部２４は、ゲーム定義情報ＤＢ２６を参照して、取得したゲーム開発者情報に含まれるゲームＩＤリストによって示されるゲームＩＤと同一のゲームＩＤを含むゲーム定義情報を取得する。ここまでは、第１の実施の形態と同様である。その後、流出判定部２４は、ＡＰＩＤＢ２９を参照して、取得したゲーム定義情報に含まれるＡＰＩＩＤと同一のＡＰＩＬＩＤを含むＡＰＩ情報を取得する。そして、流出判定部２４は、ゲーム定義情報毎に、ＡＰＩ情報及びサービス公開アドレスを組み合わせて、その組み合わせのいずれかにＡＰＩαに関するＡＰＩ情報が含まれていれば、ＡＰＩαの利用が許可されたゲームのゲーム開発者と、ゲームＧのゲーム開発者とが同一であると判定し、その組み合わせのいずれかにＡＰＩαに関するＡＰＩ情報が含まれていなければ、双方のゲーム開発者が同一ではないと判定する。
【００５４】
ステップＳ３７，Ｓ３９〜Ｓ４４は第１の実施の形態と同様である。尚、ＷＳＤＬファイルが流出したと判定した場合、尚、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルが、どのゲーム開発者に公開されているかは、ゲーム開発者ＤＢ２５、ゲーム定義情報ＤＢ２６及びＡＰＩＤＢ２９を参照することで確認することができる。具体的には、流出判定部２４は、ゲーム定義情報ＤＢ２６を参照して、ＡＰＩＤＢ２９に記憶されたＡＰＩ情報に当該ＡＰＩ定義情報と共に含まれるＡＰＩＩＤと同一のＡＰＩＩＤを含むゲーム定義情報を取得する。流出判定部２４は、ゲーム開発者ＤＢ２５を参照して、取得したゲーム定義情報に含まれるゲームＩＤと同一のゲームＩＤを示すゲームＩＤリストを含むゲーム開発者情報を取得することにより、ＡＰＩαのＡＰＩ定義情報を示すＷＳＤＬファイルの流出元のゲーム開発者を特定することができる。
【００５５】
以上のように、本実施の形態においては、ＡＰＩ公開装置２０の提供するＡＰＩに関するＡＰＩ情報をＡＰＩＤＢ２９に予め記憶させておき、ゲーム開発者との契約時に、ゲームがその利用を許可されたＡＰＩのＡＰＩＩＤを示すＡＰＩＩＤリストをゲーム定義情報に含ませることで、ゲーム毎に個別のサービス公開アドレスを割り当てた個別のＷＳＤＬファイルの作成を機械的に行うことが可能になる。従って、プラットフォーム開発者がＷＳＤＬファイルを作成しなくて良くなる。このため、ＷＳＤＬファイルの記述ミスを避けることができると共に、ＷＳＤＬファイルの流出が生じた場合に、その流出元を特定することができる。
【００５６】
尚、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施形態に示される全構成要素からいくつかの構成要素を削除しても良い。さらに、異なる実施形態にわたる構成要素を適宜組み合わせても良い。
【００５７】
上述した各実施の形態において、ＡＰＩ公開装置２０で実行される各種プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供するように構成しても良い。
【００５８】
上述した各実施の形態において、ＡＰＩ公開装置２０が実現するＡＰＩは、上述の例に限らず、例えば、ユーザ情報管理機能等の機能であっても良い。また、データベース装置３０が有するデータベースは、上述の例に限らず、例えば、ユーザデータを記憶するユーザデータベースであっても良い。また、ゲームデータベース３１及び統計データベース３２を有するデータベース装置３０は１つであっても良いし、複数であっても良い。また、複数のデータベース装置３０でゲームデータベース３１及び統計データベース３２のうち少なくとも１つを複数のデータベース装置３０で分散して管理するようにしても良い。また、プラットフォーム１０がデータベース装置３０を有さず、ＡＰＩ公開装置２０がゲームデータベース３１及び統計データベース３２のうち少なくとも１つを有するようにしても良いし、ＷｅｂサービスＡＰＩによってアプリケーションプログラムからアクセスされるその他のデータベースを有するようにしても良い。
【００５９】
上述した各実施の形態において、ＡＰＩ公開装置２０が公開するＷｅｂサービスＡＰＩを利用するアプリケーションプログラムとしてゲームを例に挙げて説明したが、アプリケーションプログラムはこれに限らない。
【００６０】
上述した各実施の形態において、ＷＳＤＬファイルは、ＡＰＩ定義情報及びサービス公開アドレスの他、例えば、ＡＰＩ公開装置２０のＩＰアドレスや、リクエストを待ち受けるポート番号を示すようにしても良い。
【００６１】
上述した各実施の形態において、ゲーム開発者にＷＳＤＬファイルを渡す方法は、ＡＰＩ公開装置２０がネットワークＮＴ１を介してゲーム開発装置にＷＳＤＬファイルを送信する方法を例に挙げて説明したが、これに限らず、例えば、ＦＴＰを利用してゲーム開発装置にＷＳＤＬファイルを送信する方法や電子メールを利用してＷＳＤＬファイルを送信する方法、持ち運び可能なディスクを利用して、ＷＳＤＬファイルを記憶したディスクをゲーム開発者に渡す方法等であっても良い。
【００６２】
上述した第２の実施の形態において、ＡＰＩ公開装置２０のリクエスト受信部２３が、ＷＳＤＬファイルを要求するリクエストを受信する度に、ＷＳＤＬ作成部２８がＷＳＤＬファイルを繰り返し作成することを避けるために、ＷＳＤＬ作成部２８が一度作成したＷＳＤＬファイルを例えばＲＡＭ等の主記憶部にキャッシュするようにしても良い。そして、リクエスト受信部２３は、ＷＳＤＬファイルを要求するリクエストを受信した場合、当該リクエストに応じたＷＳＤＬファイルがキャッシュされているか否かを判定し、当該判定結果が肯定的である場合キャッシュされたＷＳＤＬファイルをゲーム開発装置に送信し、当該判定結果が否定的である場合、ＷＳＤＬファイルの作成をＷＳＤＬ作成部２８に要求するようにすれば良い。
【符号の説明】
【００６３】
１０ プラットフォーム
２０ ＡＰＩ公開装置
２１ ＷＳＤＬ公開部
２２ ゲーム認証部
２３ リクエスト受信部
２４ 流出判定部
２５ ゲーム開発者ＤＢ
２６ ゲーム定義情報ＤＢ
２７ ＷＳＤＬＤＢ
２８ ＷＳＤＬ作成部
２９ ＡＰＩＤＢ
３０ データベース装置
３１ ゲームデータベース
３２ 統計データベース
ＮＴ１，ＮＴ２ ネットワーク
【特許請求の範囲】
【請求項１】
アプリケーションプログラムによって各種機能を実現させるために利用される各種ＡＰＩ（Application Programming Interface）を提供する情報処理装置であって、
アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に記憶する第１記憶部と、
前記アプリケーションプログラムの開発者を特定する開発者情報を記憶する第２記憶部と、
前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開する公開部と、
Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信する受信部と、
前記第１記憶部に記憶された前記ＷＳＤＬファイルのうち、前記第１のアプリケーションプログラムに対応する第１のＷＳＤＬファイルに前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する第１判定部と、
前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合、前記第２記憶部に記憶された前記開発者情報を用いて、前記第１のＷＳＤＬファイルの流出の有無を判定する第２判定部とを備える
ことを特徴とする情報処理装置。
【請求項２】
前記第１記憶部は、前記アプリケーションプログラムに対して割り当てられたアドレスを更に示す前記ＷＳＤＬファイルを前記アプリケーションプログラム毎に記憶し、
前記受信部は、第１のアドレスが付加された前記リクエストを受信し、
前記第１判定部は、前記第１のＷＳＤＬファイルによって示されるアドレスと、前記リクエストに付加された前記第１のアドレスとが同一であるか否か及び前記第１のＷＳＤＬファイルによって前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記アプリケーションプログラムの認証情報を記憶する第３記憶部と、
前記第３記憶部に記憶された前記認証情報に基づいて、前記アプリケーションプログラムを認証する認証部とを更に備え、
前記公開部は、認証が成功した前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開し、
前記第１判定部は、前記第１のアプリケーションプログラムの認証が成功した場合に、前記第１のＷＳＤＬファイルによって示されるアドレスと、前記リクエストに付加された前記第１のアドレスとが同一であるか否か及び前記第１のＷＳＤＬファイルによって前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記第２記憶部は、前記アプリケーションプログラムの開発者を識別するための開発者識別情報と、前記開発者が開発する１つ又は複数のアプリケーションプログラムを識別するためのアプリケーション識別情報とを含む前記開発者情報を記憶し、
前記受信部は、前記第１のアプリケーションプログラムを識別するための第１のアプリケーション識別情報が付加された前記リクエストを受信し、
前記第２判定部は、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合且つ前記第１のアプリケーションプログラムの開発者の前記開発者情報によって示される前記アプリケーション識別情報によって示される他のアプリケーションプログラムに対応する第２のＷＳＤＬファイルによって前記第１のＡＰＩの前記定義情報が示される場合、前記第１のＷＳＤＬファイルが流出した可能性は低いと判定し、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合且つ前記第２のＷＳＤＬファイルによって前記第１のＡＰＩの前記定義情報が示されない場合、前記第１のＷＳＤＬファイルが流出した可能性は高いと判定する
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記第３記憶部は、前記認証情報と、前記アプリケーション識別情報とを含むアプリケーション定義情報を記憶し、
前記受信部は、第１の認証情報が更に付加された前記リクエストを受信し、
前記認証部は、前記リクエストに付加された前記第１の認証情報と同一の前記認証情報及び前記第１のアプリケーション識別情報と同一の前記アプリケーション識別情報を含む第１のアプリケーション定義情報が前記第３記憶部に記憶されている場合、前記第１のアプリケーションプログラムの認証に成功する
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記第１記憶部は、前記ＷＳＤＬファイルを識別するためのＷＳＤＬ識別情報と、前記ＷＳＤＬファイルとを含むＷＳＤＬ情報を記憶し、
前記第３記憶部は、前記認証情報と、前記アプリケーション識別情報と、前記アプリケーションプログラムに対応する前記ＷＳＤＬファイルの前記ＷＳＤＬ識別情報とを含むアプリケーション定義情報を記憶し、
前記判定部は、前記第１のアプリケーションプログラムの認証に成功した場合、前記第１のアプリケーション定義情報に含まれる第１のＷＳＤＬ識別情報と同一の前記ＷＳＤＬ識別情報と共に前記ＷＳＤＬ情報に含まれる前記ＷＳＤＬファイルである前記第１のＷＳＤＬファイルによって示されるアドレスと、前記リクエストに付加された前記第１のアドレスとが同一であるか否か及び前記第１のＷＳＤＬファイルによって前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する
ことを特徴とする請求項５に記載の情報処理装置。
【請求項７】
アプリケーションプログラムによって各種機能を実現させるために利用される各種ＡＰＩ（Application Programming Interface）を提供する情報処理装置であって、
ＡＰＩの定義情報を記憶する第１記憶部と、
前記アプリケーションプログラムに対して利用が許可されたＡＰＩを識別するためのＡＰＩ識別情報とを含むアプリケーション定義情報を前記アプリケーションプログラム毎に記憶する第２記憶部と、
前記アプリケーションプログラムの開発者を特定する開発者情報を記憶する第３記憶部と、
前記定義情報と、前記アプリケーション定義情報とを用いて、前記アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に作成する作成部と、
前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開する公開部と、
Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信する受信部と、
前記第１のアプリケーションプログラムに対応する第１のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する第１判定部と、
前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合、前記第３記憶部に記憶された前記開発者情報を用いて、前記第１のＷＳＤＬファイルの流出の有無を判定する第２判定部とを備える
ことを特徴とする情報処理装置。
【請求項８】
前記第２記憶部は、前記アプリケーションプログラムに対して割り当てられたアドレスを更に含む前記アプリケーション定義情報を前記アプリケーションプログラム毎に記憶し、
前記受信部は、第１のアドレスが付加された前記リクエストを受信し、
前記第１判定部は、前記第１のアプリケーション定義情報に含まれるアドレスと、前記リクエストに付加された前記第１のアドレスとが同一であるか否か及び前記第１のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する
ことを特徴とする請求項７に記載の情報処理装置。
【請求項９】
前記第２記憶部は、前記アプリケーションプログラムの認証情報を更に含む前記アプリケーション定義情報を記憶し、
前記第２記憶部に記憶された前記アプリケーション定義情報に含まれる前記認証情報に基づいて、前記アプリケーションプログラムを認証する認証部とを更に備え、
前記公開部は、認証が成功した前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開し、
前記第１判定部は、前記第１のアプリケーションプログラムの認証が成功した場合に、前記第１のアプリケーション定義情報に含まれるアドレスと、前記リクエストに付加された前記第１のアドレスとが同一であるか否か及び前記第１のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する
ことを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
前記第３記憶部は、前記アプリケーションプログラムの開発者を識別するための開発者識別情報と、前記開発者が開発する１つ又は複数のアプリケーションプログラムを識別するための前記アプリケーション識別情報とを含む前記開発者情報を記憶し、
前記受信部は、前記第１のアプリケーションプログラムを識別するための第１のアプリケーション識別情報が付加された前記リクエストを受信し、
前記第２判定部は、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合且つ前記第１のアプリケーションプログラムの開発者の前記開発者情報によって示される前記アプリケーション識別情報によって示される他のアプリケーションプログラムに対応する第２のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれる場合、前記第１のＡＰＩの前記定義情報を示す第１のＷＳＤＬファイルが流出した可能性は低いと判定し、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合且つ前記第２のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれない場合、前記第１のＷＳＤＬファイルが流出した可能性は高いと判定する
ことを特徴とする請求項９に記載の情報処理装置。
【請求項１１】
アプリケーションプログラムによって各種機能を実現させるために利用される各種ＡＰＩ（Application Programming Interface）を提供するコンピュータを、
アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に記憶する第１記憶手段と、
前記アプリケーションプログラムの開発者を特定する開発者情報を記憶する第２記憶手段と、
前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開する公開手段と、
Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信する受信手段と、
前記第１記憶手段に記憶された前記ＷＳＤＬファイルのうち、前記第１のアプリケーションプログラムに対応する第１のＷＳＤＬファイルに前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する第１判定手段と、
前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合、前記第２記憶手段に記憶された前記開発者情報を用いて、前記第１のＷＳＤＬファイルの流出の有無を判定する第２判定手段と
して機能させるためのプログラム。
【請求項１２】
アプリケーションプログラムによって各種機能を実現させるために利用される各種ＡＰＩ（Application Programming Interface）を提供するコンピュータを、
アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に記憶する第１記憶手段と、
ＡＰＩの定義情報を記憶する第１記憶手段と、
前記アプリケーションプログラムに対して利用が許可されたＡＰＩを識別するためのＡＰＩ識別情報とを含むアプリケーション定義情報を前記アプリケーションプログラム毎に記憶する第２記憶手段と、
前記アプリケーションプログラムの開発者を特定する開発者情報を記憶する第３記憶手段と、
前記定義情報と、前記アプリケーション定義情報とを用いて、前記アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に作成する作成手段と、
前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開する公開手段と、
Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信する受信手段と、
前記第１のアプリケーションプログラムに対応する第１のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する第１判定手段と、
前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合、前記第３記憶手段に記憶された前記開発者情報を用いて、前記第１のＷＳＤＬファイルの流出の有無を判定する第２判定手段と
して機能させるためのプログラム。
【請求項１】
アプリケーションプログラムによって各種機能を実現させるために利用される各種ＡＰＩ（Application Programming Interface）を提供する情報処理装置であって、
アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に記憶する第１記憶部と、
前記アプリケーションプログラムの開発者を特定する開発者情報を記憶する第２記憶部と、
前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開する公開部と、
Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信する受信部と、
前記第１記憶部に記憶された前記ＷＳＤＬファイルのうち、前記第１のアプリケーションプログラムに対応する第１のＷＳＤＬファイルに前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する第１判定部と、
前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合、前記第２記憶部に記憶された前記開発者情報を用いて、前記第１のＷＳＤＬファイルの流出の有無を判定する第２判定部とを備える
ことを特徴とする情報処理装置。
【請求項２】
前記第１記憶部は、前記アプリケーションプログラムに対して割り当てられたアドレスを更に示す前記ＷＳＤＬファイルを前記アプリケーションプログラム毎に記憶し、
前記受信部は、第１のアドレスが付加された前記リクエストを受信し、
前記第１判定部は、前記第１のＷＳＤＬファイルによって示されるアドレスと、前記リクエストに付加された前記第１のアドレスとが同一であるか否か及び前記第１のＷＳＤＬファイルによって前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記アプリケーションプログラムの認証情報を記憶する第３記憶部と、
前記第３記憶部に記憶された前記認証情報に基づいて、前記アプリケーションプログラムを認証する認証部とを更に備え、
前記公開部は、認証が成功した前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開し、
前記第１判定部は、前記第１のアプリケーションプログラムの認証が成功した場合に、前記第１のＷＳＤＬファイルによって示されるアドレスと、前記リクエストに付加された前記第１のアドレスとが同一であるか否か及び前記第１のＷＳＤＬファイルによって前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記第２記憶部は、前記アプリケーションプログラムの開発者を識別するための開発者識別情報と、前記開発者が開発する１つ又は複数のアプリケーションプログラムを識別するためのアプリケーション識別情報とを含む前記開発者情報を記憶し、
前記受信部は、前記第１のアプリケーションプログラムを識別するための第１のアプリケーション識別情報が付加された前記リクエストを受信し、
前記第２判定部は、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合且つ前記第１のアプリケーションプログラムの開発者の前記開発者情報によって示される前記アプリケーション識別情報によって示される他のアプリケーションプログラムに対応する第２のＷＳＤＬファイルによって前記第１のＡＰＩの前記定義情報が示される場合、前記第１のＷＳＤＬファイルが流出した可能性は低いと判定し、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合且つ前記第２のＷＳＤＬファイルによって前記第１のＡＰＩの前記定義情報が示されない場合、前記第１のＷＳＤＬファイルが流出した可能性は高いと判定する
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記第３記憶部は、前記認証情報と、前記アプリケーション識別情報とを含むアプリケーション定義情報を記憶し、
前記受信部は、第１の認証情報が更に付加された前記リクエストを受信し、
前記認証部は、前記リクエストに付加された前記第１の認証情報と同一の前記認証情報及び前記第１のアプリケーション識別情報と同一の前記アプリケーション識別情報を含む第１のアプリケーション定義情報が前記第３記憶部に記憶されている場合、前記第１のアプリケーションプログラムの認証に成功する
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記第１記憶部は、前記ＷＳＤＬファイルを識別するためのＷＳＤＬ識別情報と、前記ＷＳＤＬファイルとを含むＷＳＤＬ情報を記憶し、
前記第３記憶部は、前記認証情報と、前記アプリケーション識別情報と、前記アプリケーションプログラムに対応する前記ＷＳＤＬファイルの前記ＷＳＤＬ識別情報とを含むアプリケーション定義情報を記憶し、
前記判定部は、前記第１のアプリケーションプログラムの認証に成功した場合、前記第１のアプリケーション定義情報に含まれる第１のＷＳＤＬ識別情報と同一の前記ＷＳＤＬ識別情報と共に前記ＷＳＤＬ情報に含まれる前記ＷＳＤＬファイルである前記第１のＷＳＤＬファイルによって示されるアドレスと、前記リクエストに付加された前記第１のアドレスとが同一であるか否か及び前記第１のＷＳＤＬファイルによって前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する
ことを特徴とする請求項５に記載の情報処理装置。
【請求項７】
アプリケーションプログラムによって各種機能を実現させるために利用される各種ＡＰＩ（Application Programming Interface）を提供する情報処理装置であって、
ＡＰＩの定義情報を記憶する第１記憶部と、
前記アプリケーションプログラムに対して利用が許可されたＡＰＩを識別するためのＡＰＩ識別情報とを含むアプリケーション定義情報を前記アプリケーションプログラム毎に記憶する第２記憶部と、
前記アプリケーションプログラムの開発者を特定する開発者情報を記憶する第３記憶部と、
前記定義情報と、前記アプリケーション定義情報とを用いて、前記アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に作成する作成部と、
前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開する公開部と、
Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信する受信部と、
前記第１のアプリケーションプログラムに対応する第１のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する第１判定部と、
前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合、前記第３記憶部に記憶された前記開発者情報を用いて、前記第１のＷＳＤＬファイルの流出の有無を判定する第２判定部とを備える
ことを特徴とする情報処理装置。
【請求項８】
前記第２記憶部は、前記アプリケーションプログラムに対して割り当てられたアドレスを更に含む前記アプリケーション定義情報を前記アプリケーションプログラム毎に記憶し、
前記受信部は、第１のアドレスが付加された前記リクエストを受信し、
前記第１判定部は、前記第１のアプリケーション定義情報に含まれるアドレスと、前記リクエストに付加された前記第１のアドレスとが同一であるか否か及び前記第１のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する
ことを特徴とする請求項７に記載の情報処理装置。
【請求項９】
前記第２記憶部は、前記アプリケーションプログラムの認証情報を更に含む前記アプリケーション定義情報を記憶し、
前記第２記憶部に記憶された前記アプリケーション定義情報に含まれる前記認証情報に基づいて、前記アプリケーションプログラムを認証する認証部とを更に備え、
前記公開部は、認証が成功した前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開し、
前記第１判定部は、前記第１のアプリケーションプログラムの認証が成功した場合に、前記第１のアプリケーション定義情報に含まれるアドレスと、前記リクエストに付加された前記第１のアドレスとが同一であるか否か及び前記第１のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する
ことを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
前記第３記憶部は、前記アプリケーションプログラムの開発者を識別するための開発者識別情報と、前記開発者が開発する１つ又は複数のアプリケーションプログラムを識別するための前記アプリケーション識別情報とを含む前記開発者情報を記憶し、
前記受信部は、前記第１のアプリケーションプログラムを識別するための第１のアプリケーション識別情報が付加された前記リクエストを受信し、
前記第２判定部は、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合且つ前記第１のアプリケーションプログラムの開発者の前記開発者情報によって示される前記アプリケーション識別情報によって示される他のアプリケーションプログラムに対応する第２のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれる場合、前記第１のＡＰＩの前記定義情報を示す第１のＷＳＤＬファイルが流出した可能性は低いと判定し、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合且つ前記第２のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれない場合、前記第１のＷＳＤＬファイルが流出した可能性は高いと判定する
ことを特徴とする請求項９に記載の情報処理装置。
【請求項１１】
アプリケーションプログラムによって各種機能を実現させるために利用される各種ＡＰＩ（Application Programming Interface）を提供するコンピュータを、
アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に記憶する第１記憶手段と、
前記アプリケーションプログラムの開発者を特定する開発者情報を記憶する第２記憶手段と、
前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開する公開手段と、
Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信する受信手段と、
前記第１記憶手段に記憶された前記ＷＳＤＬファイルのうち、前記第１のアプリケーションプログラムに対応する第１のＷＳＤＬファイルに前記第１のＡＰＩの前記定義情報が示されるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する第１判定手段と、
前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合、前記第２記憶手段に記憶された前記開発者情報を用いて、前記第１のＷＳＤＬファイルの流出の有無を判定する第２判定手段と
して機能させるためのプログラム。
【請求項１２】
アプリケーションプログラムによって各種機能を実現させるために利用される各種ＡＰＩ（Application Programming Interface）を提供するコンピュータを、
アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に記憶する第１記憶手段と、
ＡＰＩの定義情報を記憶する第１記憶手段と、
前記アプリケーションプログラムに対して利用が許可されたＡＰＩを識別するためのＡＰＩ識別情報とを含むアプリケーション定義情報を前記アプリケーションプログラム毎に記憶する第２記憶手段と、
前記アプリケーションプログラムの開発者を特定する開発者情報を記憶する第３記憶手段と、
前記定義情報と、前記アプリケーション定義情報とを用いて、前記アプリケーションプログラムに対して利用が許可されたＡＰＩの定義情報を示すＷＳＤＬ（Web Service Description Language）ファイルを前記アプリケーションプログラム毎に作成する作成手段と、
前記アプリケーションプログラムに対して、当該アプリケーションプログラムに対応する前記ＷＳＤＬファイルを公開する公開手段と、
Ｗｅｂサービスを介して、第１のアプリケーションプログラムによる第１のＡＰＩの利用を要求するリクエストを受信する受信手段と、
前記第１のアプリケーションプログラムに対応する第１のアプリケーション定義情報に前記第１のＡＰＩの前記定義情報が含まれるか否かを判定することにより、前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当であるか否かを判定する第１判定手段と、
前記第１のアプリケーションプログラムによる前記第１のＡＰＩの利用が正当ではないと判定された場合、前記第３記憶手段に記憶された前記開発者情報を用いて、前記第１のＷＳＤＬファイルの流出の有無を判定する第２判定手段と
して機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−９８８１４（Ｐ２０１２−９８８１４Ａ）
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願番号】特願２０１０−２４４２７０（Ｐ２０１０−２４４２７０）
【出願日】平成２２年１０月２９日（２０１０．１０．２９）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願日】平成２２年１０月２９日（２０１０．１０．２９）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]