(57)【要約】      （修正有）【課題】アプリケーションにアクセスするための開発者サービスポータルを含む、拡張可能な鍵管理システムを提供する。【解決手段】システムは、アプリケーションとサードパーティプロバイダサービスの外部ＡＰＩとの関連付けの開発者サービスポータルを介した開始を識別し、アプリケーションの開発者に代わり外部ＡＰＩのためのサブ鍵をサードパーティプロバイダサービスから自動的に取得する。サブ鍵は、サードパーティプロバイダサービスから以前に提供されたマスター鍵により提供される認可に従って取得される。システムは、サブ鍵、アプリケーション、および外部ＡＰＩの間の関連付けをマッピングし、関連付けを記憶する。アプリケーションを実行するユーザデバイスからの要求から生じるサービスコールメッセージを受信すると、システムは、記憶された関連付けに基づいてサービスコールメッセージ内に含まれる開発者ＡＰＩ鍵を識別し、サブ鍵と置き換える。【選択図】図３
2018186492.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラミングインターフェース（ＡＰＩ）のための拡張可能な鍵管理を遂行する方法であって、
プロセッサにより、開発者サービスポータルを介してアプリケーションにアクセスするステップと、
前記プロセッサにより、前記アプリケーションとサードパーティプロバイダサービスの外部ＡＰＩとの関連付けの前記開発者サービスポータルを介した開始を識別するステップと、
前記プロセッサにより、前記サードパーティプロバイダサービスから前記外部ＡＰＩのためのサブ鍵を取得するステップであって、マスター鍵に基づいて前記サブ鍵を取得する認可が、以前に前記サードパーティプロバイダサービスから提供されている、取得するステップと、
前記プロセッサにより、前記サブ鍵、前記アプリケーション、および前記サードパーティプロバイダサービスの前記外部ＡＰＩの間の関連付けをマッピングするステップと、
前記プロセッサにより、サービスコールメッセージであって、前記アプリケーションを実行するユーザデバイスからの要求から生じる、サービスコールメッセージ、内に含まれる開発者ＡＰＩ鍵を前記サブ鍵で置き換えるステップと、を含む、方法。
【請求項２】
前記アプリケーションと前記外部ＡＰＩとの前記関連付けが、前記プロセッサにより、前記外部ＡＰＩのためのＡＰＩプロキシと前記アプリケーションとの関連付けを作成するステップを含み、前記プロセッサにより、前記開発者ＡＰＩ鍵を置き換える前記ステップが、前記プロセッサにより、前記サービスコールメッセージが前記ＡＰＩプロキシにより受信されるとき、前記開発者ＡＰＩ鍵が前記サービスコールメッセージ内に含まれていることに応答して、置き換えを遂行すべきサービス種類を識別するステップを含む、請求項１に記載の方法。
【請求項３】
前記プロセッサにより、前記サービスコールメッセージ内で受信された前記開発者ＡＰＩ鍵を前記サブ鍵で置き換えるステップが、
前記プロセッサにより、前記開発者ＡＰＩ鍵を含む前記サービスコールメッセージに応答して鍵管理サービスを呼び出すステップと、
前記プロセッサにより前記鍵管理サービスを介して、前記サブ鍵、前記アプリケーション、および前記サードパーティプロバイダサービスの前記外部ＡＰＩの間でマッピングされた前記関連付けに基づいて前記サブ鍵を取り出すステップと、
前記プロセッサにより前記鍵管理サービスを介して、前記サブ鍵を前記サービスコールメッセージ内に注入するステップと、
前記プロセッサにより、前記サービスコールメッセージを前記注入されたサブ鍵と共に、前記サードパーティプロバイダサービスの前記外部ＡＰＩにプロキシ送信するステップと、を含む、請求項１に記載の方法。
【請求項４】
前記プロセッサを用いて、前記サブ鍵、前記アプリケーション、および前記サードパーティプロバイダサービスの前記外部ＡＰＩの間でマッピングされた前記関連付けに基づいて前記サブ鍵を取り出すステップが、前記外部ＡＰＩに対して前記アプリケーションを識別するために前記サービスコールメッセージ内にＡＰＩ鍵が必要とされることを識別する初期ステップを含む、請求項３に記載の方法。
【請求項５】
前記プロセッサを用いて、前記アプリケーションとサードパーティプロバイダサービスの前記外部ＡＰＩとの関連付けの前記開発者サービスポータルを介した開始を識別するステップが、前記開発者サービスポータル内で受信された前記アプリケーションを前記外部ＡＰＩのＡＰＩプロキシに関連付けるための入力に基づいて前記サードパーティプロバイダサービスの前記外部ＡＰＩとの前記関連付けを自動的に識別するステップと、前記アプリケーションの開発者に代わって自動的にサブ鍵の要求を生成し前記サードパーティプロバイダサービスに送信するステップと、を含む、請求項１に記載の方法。
【請求項６】
前記プロセッサを用いて、前記サブ鍵、前記アプリケーション、および前記サードパーティプロバイダサービスの前記外部ＡＰＩの間の関連付けをマッピングするステップが、前記アプリケーションに関連付けられたＡＰＩプロキシを前記プロセッサにより実行可能なカスタムサービス層にリンクして、前記開発者ＡＰＩ鍵を前記サブ鍵で置き換えるステップと、前記関連付けをカスタムサービス層からアクセス可能なＡＰＩ鍵記憶装置内に記憶するステップと、を含む、請求項１に記載の方法。
【請求項７】
前記プロセッサを用いて、前記外部ＡＰＩのための前記サブ鍵を前記サードパーティプロバイダサービスから入手するステップが、前記マスター鍵と前記サブ鍵の要求とを前記サードパーティプロバイダサービスに送信するステップを含む、請求項１に記載の方法。
【請求項８】
拡張可能な鍵管理システムであって、
アプリケーションに関連付けられ、サービスコールメッセージをサードパーティプロバイダサービスの外部ＡＰＩに向けてプロキシ送信するようにプロセッサにより実行可能な、ＡＰＩプロキシと、
前記サービスコールメッセージを構文解析し、前記サービスコールメッセージ内に含まれる開発者ＡＰＩ鍵を識別するように、前記プロセッサにより実行可能なコンテキストサービスと、
鍵管理サービスであって、前記開発者ＡＰＩ鍵の識別に応答して前記開発者ＡＰＩ鍵を前記外部ＡＰＩのためのサブ鍵で置き換えるように前記プロセッサにより実行可能であり、前記サブ鍵が、前記開発者ＡＰＩ鍵、前記アプリケーション、および前記サードパーティプロバイダサービスの前記外部ＡＰＩに関連付けられており、
前記鍵管理サービスがさらに、前記サービスコールメッセージを前記サブ鍵と共に前記サードパーティプロバイダサービスの前記外部ＡＰＩにプロキシ送信するように前記プロセッサを用いて実行可能である、鍵管理サービスと、を含む、拡張可能な鍵管理システム。
【請求項９】
複数のサブ鍵がそれぞれのアプリケーションおよび外部ＡＰＩに関連付けられた状態で記憶されるＡＰＩ鍵記憶装置をさらに備え、前記コンテキストサービスが、前記サービスコールメッセージのサービス種類を鍵管理の種類として識別し、前記ＡＰＩ鍵記憶装置内の前記サブ鍵の記憶位置を前記鍵管理サービスに対して識別するように前記プロセッサにより実行可能である、請求項８に記載の拡張可能な鍵管理システム。
【請求項１０】
前記アプリケーションと前記外部ＡＰＩとの関連付けを可能にするように構成された開発者サービスポータルをさらに備え、前記開発者サービスポータルが、前記開発者サービスポータル内で受信された前記ＡＰＩプロキシと前記アプリケーションとの関連付けを開始するための入力に応答して、前記サードパーティプロバイダサービスの前記外部ＡＰＩのための前記サブ鍵を自動的に取得するように前記プロセッサにより実行可能である、請求項８に記載の拡張可能な鍵管理システム。
【請求項１１】
前記ＡＰＩプロキシにおける前記サービスコールメッセージの受信に応答して前記コンテキストサービスが選択されるように、前記開発者サービスポータルが、前記ＡＰＩプロキシを前記コンテキストサービスに自動的にリンクするように前記プロセッサにより実行可能である、請求項１０に記載の拡張可能な鍵管理システム。
【請求項１２】
前記コンテキストサービスが、複数のコンテキストサービスであり、前記ＡＰＩプロキシが、前記ＡＰＩプロキシと前記コンテキストサービスとの間の関連付けに基づいて、前記複数のコンテキストサービスの中から前記コンテキストサービスを選択するように前記プロセッサにより実行可能である、請求項８に記載の拡張可能な鍵管理システム。
【請求項１３】
前記鍵管理サービスが、ＡＰＩゲートウェイプラットフォームを介して前記外部ＡＰＩの前記サブ鍵を自動的に追加するように、開発者サービスポータルにより呼び出され、前記鍵管理サービスが、前記アプリケーションからの前記サービスコールメッセージに応答して前記ＡＰＩゲートウェイプラットフォームを介して前記プロセッサにより呼び出される、請求項８に記載の拡張可能な鍵管理システム。
【請求項１４】
アプリケーションプログラミングインターフェース（ＡＰＩ）のための拡張可能な鍵管理を遂行する方法であって、
開発者サービスポータルを介して、アプリケーションと、第１のサードパーティプロバイダサービスの第１の外部ＡＰＩのための第１のＡＰＩプロキシおよび第２のサードパーティプロバイダサービスの第２の外部ＡＰＩのための第２のＡＰＩプロキシとを関連付けるステップと、
前記アプリケーションが前記第１のＡＰＩプロキシおよび前記第２のＡＰＩプロキシと関連付けられているとき、プロセッサにより、前記第１の外部ＡＰＩのための第１のサブ鍵および前記第２の外部ＡＰＩのための第２のサブ鍵を取得および記憶するステップと、
前記アプリケーションから前記第１の外部ＡＰＩに向けた第１のサービスコールメッセージであって、開発者ＡＰＩ鍵を含む、第１のサービスコールメッセージ、を受信し、前記アプリケーションから前記第２の外部ＡＰＩに向けた第２のサービスコールメッセージであって、前記開発者ＡＰＩ鍵を含む、第２のサービスコールメッセージ、を受信するステップと、
前記開発者ＡＰＩ鍵と、前記第１のサブ鍵、前記アプリケーション、および前記第１の外部ＡＰＩとの記憶された関連付けに基づいて、前記プロセッサにより、前記開発者ＡＰＩ鍵を前記第１のサービスコールメッセージ内の前記第１のサブ鍵で置き換えるステップと、
前記開発者ＡＰＩ鍵と、前記第２のサブ鍵、前記アプリケーション、および前記第２の外部ＡＰＩとの記憶された関連付けに基づいて、前記プロセッサにより、前記開発者ＡＰＩ鍵を前記第２のサービスコールメッセージ内の前記第２のサブ鍵で置き換えるステップと、を含む、方法。
【請求項１５】
前記プロセッサにより、前記第１の外部ＡＰＩのための前記第１のサブ鍵および前記第２の外部ＡＰＩのための前記第２のサブ鍵を取得および記憶するステップが、前記プロセッサにより、前記第１のサブ鍵を求める第１のマスター鍵を含む第１の要求を前記第１のサードパーティプロバイダサービスに送信し、前記第２のサブ鍵を求める第２のマスター鍵を含む第２の要求を前記第２のサードパーティプロバイダサービスに送信するステップを含み、前記第１のマスター鍵および前記第２のマスター鍵が、前記アプリケーションの開発者に代わって前記第１のサブ鍵および前記第２のサブ鍵を取得するための事前認可として、それぞれ前記第１のサードパーティプロバイダサービスおよび前記第２のサードパーティプロバイダサービスから以前に提供されている、請求項１４に記載の方法。
【請求項１６】
前記プロセッサにより、前記第１の外部ＡＰＩのための前記第１のサブ鍵および前記第２の外部ＡＰＩのための前記第２のサブ鍵を取得および記憶するステップが、前記第１のサブ鍵、前記アプリケーション、および前記第１のサードパーティプロバイダサービスの前記第１の外部ＡＰＩの間の第１の関連付けをマッピングおよび記憶し、前記第２のサブ鍵、前記アプリケーション、および前記第２のサードパーティプロバイダサービスの前記第２の外部ＡＰＩの間の第２の関連付けをマッピングおよび記憶するステップを含む、請求項１４に記載の方法。
【請求項１７】
前記プロセッサにより、前記第１のサブ鍵を含む前記第１のサービスコールメッセージを前記第１のサードパーティプロバイダサービスの前記第１の外部ＡＰＩにプロキシ送信し、前記プロセッサにより、前記第２のサブ鍵を含む前記第２のサービスコールメッセージを前記第２のサードパーティプロバイダサービスの前記第２の外部ＡＰＩにプロキシ送信するステップをさらに含む、請求項１４に記載の方法。
【請求項１８】
前記開発者サービスポータルを介して、前記アプリケーションと前記第１のサードパーティプロバイダサービスの前記第１の外部ＡＰＩのための前記第１のＡＰＩプロキシおよび前記第２のサードパーティプロバイダサービスの前記第２の外部ＡＰＩのための前記第２のＡＰＩプロキシとを関連付けるステップが、前記アプリケーションと前記第１のＡＰＩプロキシおよび前記第２のＡＰＩプロキシとの関連付けの開始を識別し、前記プロセッサを用いて自動的に、前記第１のサブ鍵を求める第１の要求を前記第１のサードパーティプロバイダサービスに送信し、前記第２のサブ鍵を求める第２の要求を前記第２のサードパーティプロバイダサービスに送信するステップを含む、請求項１４に記載の方法。
【請求項１９】
前記第１のサブ鍵を求める前記第１の要求を前記第１のサードパーティプロバイダサービスに送信し、前記第２のサブ鍵を求める前記第２の要求を前記第２のサードパーティプロバイダサービスに送信するステップが、前記プロセッサにより、前記第１のサードパーティプロバイダサービスから以前に取得された第１のマスター鍵を取り出し、前記第１の要求内に含めるステップと、前記プロセッサにより、前記第２のサードパーティプロバイダサービスから以前に取得された第２のマスター鍵を取り出し、前記第２の要求内に含めるステップとを含み、前記第１のサブ鍵が、前記第１のマスター鍵に関連付けられ、前記第２のサブ鍵が、前記第２のマスター鍵に関連付けられている、請求項１８に記載の方法。
【請求項２０】
前記アプリケーションから前記第１の外部ＡＰＩに向けた前記第１のサービスコールメッセージであって、前記開発者ＡＰＩ鍵を含む、前記第１のサービスコールメッセージ、を受信するステップと、前記アプリケーションから前記第２の外部ＡＰＩに向けた前記第２のサービスコールメッセージであって、前記開発者ＡＰＩ鍵を含む、前記第２のサービスコールメッセージ、を受信するステップとが、前記プロセッサにより、前記第１のサービスコールメッセージおよび前記第２のサービスコールメッセージを構文解析して、前記開発者ＡＰＩ鍵および鍵管理サービスとしてのサービス種類を識別するステップと、前記プロセッサにより、前記鍵管理サービスに含まれる第１のコア能力サービスを用いて、前記開発者ＡＰＩ鍵と前記アプリケーションおよび前記第１の外部ＡＰＩとの記憶された関連付けに基づいて前記第１のサブ鍵を取り出し、前記プロセッサにより、前記鍵管理サービスに含まれる第２のコア能力サービスを用いて、前記開発者ＡＰＩ鍵と前記アプリケーションおよび前記第２の外部ＡＰＩとの記憶された関連付けに基づいて前記第２のサブ鍵を取り出すステップと、を含む、請求項１４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、アプリケーションプログラミングインターフェースに関し、より具体的には、アプリケーションプログラミングインターフェースのための拡張可能な鍵管理システムに関する。
【０００２】
優先権
本出願は、２０１７年３月１７日に出願された米国仮出願第６２／４７３，１９４号の利益を主張し、同出願は、ここに、その全体が参照により本明細書に組み込まれる。
【背景技術】
【０００３】
デジタルの製品およびサービスは、ますます相互接続され、シームレスな体験をエンドユーザに提供している。このような相互接続をグローバルに提供する１つの方法は、アプリケーションプログラミングインターフェース（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）によるものであり、アプリケーションプログラミングインターフェースは、典型的に、２つのソフトウェアコンポーネントが互いに相互作用する方法を決定する一組のルーチン、プロトコル、およびツールである。開発者は、ＡＰＩプロバイダを調達し、ＡＰＩプロバイダとの関係を構築するのに相当の時間を費やしており、ＡＰＩ使用の市場がさらに大きくなるにつれて、さらに多くの時間を費やすことになる。このような管理上のオーバーヘッドを低減するためのシステムおよび方法に対するニーズが存在する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上述のように、開発者は、ＡＰＩプロバイダを調達し、ＡＰＩプロバイダとの関係を構築するのに相当の時間を費やしており、ＡＰＩ使用の市場がさらに大きくなるにつれて、さらに多くの時間を費やすことになる。このような管理上のオーバーヘッドを低減するためのシステムおよび方法に対するニーズが存在する。
【課題を解決するための手段】
【０００５】
アプリケーションプログラミングインターフェース（ＡＰＩ）のための拡張可能な鍵管理システムは、金融機関および他のデジタル配信サービスなどのＡＰＩプロバイダからのＡＰＩ鍵を統合、集約、および単純化するためのプラットフォームを提供する。システムは、単一の場所内でＡＰＩのコレクションを含むプラットフォームを提供して、ＡＰＩ牽引型の提案を構築することおよび関連付けられたＡＰＩ鍵を管理することにまつわる開発オーバーヘッドを劇的に低減する。
【０００６】
システムは、複数のソースからのＡＰＩ製品の一元的な消費を管理することに対する、インテリジェントな構成ベースのアプローチを可能にする。歴史的に、集約（多くのサービスをコールするが、単一の組の結果を生み出す）または選択（一組の基準に基づいて類似サービスの大群の中から特定のサービスを選ぶ）を行うためのロジックを物理的に実装するサービスまたはコンポーネントを構築することにより、小さな組の類似ＡＰＩにわたって集積または選択する解決策を作成するのは容易であった。しかしながら、サービスの数が増えるにつれて、またはサービスの形態が変わるにつれて（例えば、入力または出力フォーマットの数／スタイル）、これを管理、維持、および成長させることは、ますます厄介になってくる。集約されているＡＰＩに対する下流での変更に対処すること、およびプールに新しいサービスを加えることも、非常に困難であり、時間がかかる上、高価であり、しばしば、安定して機能するシステムを維持するためにコードリリースまたは類似のリリース管理プロセスを必要とする。
【０００７】
拡張可能な鍵管理システムは、ＡＰＩサービスおよびＡＰＩ鍵の管理に対する階層状かつステートレスな、構成ベースのアプローチを可能にすることにより、この問題を解決する。ＡＰＩサービスおよびＡＰＩ鍵は、ランタイムに変更可能な記憶された構成エンティティを介して迅速かつ効率的に修正、拡張、および保守され得る一元的な鍵管理能力を有する集約、選択、およびプロキシサービスを可能にする。
【０００８】
他のシステム、方法、特徴、および利点は、以下の図および詳細な説明を検討すると、当業者に明らかであり、または明らかになるであろう。全てのこのような追加のシステム、方法、特徴、および利点は、本明細書内に含まれ、本発明および以下の請求項の範囲内にあることを意図する。
【０００９】
実施形態は、次の図面および説明を参照することにより、よりよく理解され得る。図中のコンポーネントは、必ずしも縮尺一定ではない。その上、図において、似通った参照番号は、異なる図を通じて対応する部分を指し示す。
【図面の簡単な説明】
【００１０】
【図１】クライアント、顧客、およびサードパーティプロバイダなどのユーザと連通しているアプリケーションプログラミングインターフェース（ＡＰＩ）のための拡張可能な鍵管理システムの一例を示すブロック図である。
【図２】拡張可能な鍵管理システム内の開発者サービスポータル、ＡＰＩゲートウェイプラットフォーム、およびカスタムサービス層の機能を例示するブロック図の例である。
【図３】コンテキスト層とコアサービス層とを含む、拡張可能な鍵管理システム内の例示的なカスタムサービス層を示すブロック図である。
【図４】コンテキストサービスとコア能力サービスとの間の通信プロセスの例示的な動作の流れ図である。
【図５】鍵管理を遂行するための、拡張可能な鍵管理システムの例示的な動作である。
【図６】複数のサービスプロバイダからの応答を集約するアプリケーションにおける、拡張可能な鍵管理システムの動作の一例である。
【図７】ユーザが特定の一サービスプロバイダをターゲットとする支払取引を開始するアプリケーションにおける、拡張可能な鍵管理システムの動作の一例である。
【図８】鍵管理サービスがサードパーティ通信サービスにアクセスするアプリケーションにおける、拡張可能な鍵管理システムの動作の一例である。
【発明を実施するための形態】
【００１１】
図１は、エンドユーザおよび開発者などのユーザにより操作されるユーザデバイス１０２と連通し、かつ商品および／またはサービスのプロバイダを含み得るサードパーティプロバイダサービス１０４とも連通する、ＡＰＩ１００のための拡張可能な鍵管理システムの一例を示すブロック図である。拡張可能な鍵管理システム１００は、開発者サービスポータル１０８、ＡＰＩゲートウェイプラットフォーム１１０、およびカスタムサービス層１１２を含み得る。システム１００は、１つ以上のコンピュータサーバ、コンピュータ、またはロジックを実行している場合がある他の形態のコンピューティングデバイス、回路、もしくは他のハードウェアであり得る。システム１００は、メモリ内に記憶された命令を実行し、メモリ内のデータにアクセスし、メモリ内にデータを記憶する１つ以上のプロセッサを含み得る。システム１００は、無線または有線ネットワーク１１４を介してユーザデバイス１０２およびサードパーティプロバイダサービス１０４と通信し得る。
【００１２】
システム１００は、金融系および非金融系ソースなどの様々なサードパーティプロバイダサービス１０４からの、開発者ポータルからアクセス可能なＡＰＩを統合および結集し得る。サードパーティプロバイダサービス１０４としては、銀行、レストラン、給油所、小売業者、または類似の分野における他の商品およびサービスのプロバイダなどの、商品および／またはサービスを提供する競合会社として運営されている競合サービスプロバイダ１１８の１つ以上の群からのＡＰＩが挙げられる。サードパーティプロバイダサービス１０４としては、ユーザがアカウントを有し、それぞれのサードパーティプロバイダサービスにより別々に認証された後でのみパーソナル化されたサービスが提供されるユーザの銀行または金融機関などの、資格証明書を有する個々のサービスのサービスプロバイダ１２０も挙げられる。追加的に、サードパーティプロバイダサービス１０４は、マッピングプロバイダ１２４、ソーシャルメディアプロバイダ１２６、および通信プロバイダ１２８、またはユーザがそこにアカウントを有し、アクセスのためにログインすることができる他の非金融系プロバイダなどの、任意の数のアカウントサービスプロバイダ１２２からのＡＰＩを含み得る。競合サービスプロバイダ１１８、資格証明書を有する個々のサービスプロバイダ１２０、およびアカウントサービスプロバイダ１２２の群のＡＰＩは、システム１００内に含まれるカスタムサービス層１１２により処理され得る。異なるサードパーティプロバイダサービスのＡＰＩエンドポイントが、開発者サービスポータル１０８を介して、開発者デバイス１３０などのユーザデバイス１０２に提供され得る。
【００１３】
拡張可能な鍵管理システム１００は、１）開発者サービスポータル１０８、２）ＡＰＩゲートウェイプラットフォーム１１０、および３）カスタムサービス層１１２、のコアシステムコンポーネントを含む。システム１００は、システムを安全にし、ユーザ／開発者を認証し、ユーザ／開発者のセキュリティ資格証明書に基づいてシステムへの様々なアクセスレベルを提供するための、セキュリティおよび認証機能を含み得る。他の例では、本明細書に記載の拡張可能な鍵管理システム１００の機能は、より少ない、またはより多い数のコアシステムコンポーネントと共に描かれ得る。
【００１４】
開発者サービスポータル１０８およびＡＰＩゲートウェイプラットフォーム１１０は、システム１００の使用統計および鍵管理情報を含み、または表示し得る。追加的に、開発者サービスポータル１０８は、開発者デバイス１３０を使用してプラットフォームにアクセスする開発者である外部ユーザのエントリポイントであり得る。よって、開発者サービスポータル１０８は、開発者ユーザのアクセスポータルに、ＡＰＩゲートウェイプラットフォーム１１０、例えばＡＰＩエンドポイントから公開された機能の要素を提供し得る。さらに、開発者サービスポータル１０８は、開発者デバイス１３０を使用する開発者が、アプリケーション１３６を登録し、それぞれの開発者により開発されるそれぞれのアプリケーション１３６により使用されるサードパーティプロバイダサービスのＡＰＩ群の製品バンドルを選択する能力を提供し得る。追加的に、ＡＰＩ文書、分析、および開発者サービスユーティリティなどの、他の情報および機能が、開発者サービスポータル１０８内で利用可能であり得る。開発者サービスポータル１０８はまた、システム１００内の機能および情報へのアクセスを提供するグラフィカルユーザインターフェースなどのユーザインターフェースを提供し得る。
【００１５】
開発者サービスポータル１０８を介したシステム１００へのアクセスは、開発者デバイス１３０については、１つ以上の無線および／または有線ネットワーク１１４（以下、ネットワーク１１４）を介してであり得る。追加的に、消費者デバイス１３２によるアプリケーション１３６またはＡＰＩゲートウェイプラットフォーム１１０へのアクセスは、ネットワーク１１４を介してであり得る。ネットワーク１１４としては、インターネット、公衆もしくはプライベートＬＡＮもしくはＷＡＮ、または電子通信を可能にする他の任意のリンク通信システムが挙げられる。開発者デバイス（複数可）１３０および消費者デバイス（複数可）１３２は、コンピュータ、モバイルデバイス、またはネットワーク１１４を介してシステム１００にアクセスするために使用される端末などのハードウェアであり得る。図１の例では、消費者デバイス（複数可）１３２は、消費者デバイス１３２を使用する消費者がサードパーティプロバイダサービス１０４のいくつかの異なるサービスにアクセスし得るように、上でアプリケーション１３６が実行されるモバイル端末または他のコンピューティングデバイスであり得る。追加的または代替的に、消費者デバイス１３２は、例えば、ウェブブラウザ、消費者用ツール、またはコンピュータ上で実行される他のなんらかの機構（物理的もしくは仮想的）を介して、アプリケーション１３６に直接アクセスし得る。開発者デバイス１３０は、例えば、ウェブブラウザ、開発者用ツール、またはコンピュータ上で実行される他のなんらかの機構（物理的もしくは仮想的）を介して、開発者サービスポータル１０８に直接アクセスし得る。ユーザおよび開発者によるシステム１００へのアクセスは、ログイン、トークン、鍵、および／または他の任意の形態の認証およびセキュリティを伴い得る。ある例では、アプリケーション１３６は、システム１００の使用のための検証および認証として、開発者用ＡＰＩ鍵および秘密をシステム１００に渡し得る。
【００１６】
ＡＰＩゲートウェイプラットフォーム１１０は、ＡＰＩゲートウェイ自体として動作するだけではなく、拡張可能な鍵管理システム１００のセットアップに対する管理インターフェースも提供し得る。ＡＰＩゲートウェイプラットフォーム１１０は、専有コードなどのロジックを実行して、本明細書に記載のＡＰＩ管理機能を遂行し得る。追加的に、ＡＰＩゲートウェイプラットフォーム１１０は、例えば、ＩＢＭ  ＡＰＩ  ｃｏｎｎｅｃｔ（登録商標）、Ａｍａｚｏｎ（登録商標）  ＡＷＳ（登録商標）、ＡＰＩｇｅｅ（登録商標）、Ｍｕｌｅｓｏｆｔ（登録商標）、または他のＡＰＩ管理解決策に類似した機能を含み得る。ＡＰＩゲートウェイプラットフォーム１１０は、ＡＰＩプロキシがアプリケーション１３６のために構成される場所であるだけではなく、分析、監視、およびセキュリティのセットアップに対するアクセスも提供し得る。ある例示的な構成では、ＡＰＩゲートウェイプラットフォーム１１０は、金融取引に関係するアプリケーション１３６のために、ＰＳＤ２（改正支払サービス指令：ｒｅｖｉｓｅｄ  ｐａｙｍｅｎｔ  ｓｅｒｖｉｃｅ  ｄｉｒｅｃｔｉｖｅ）およびＣＭＡ（Ｃｏｍｐｅｔｉｔｉｏｎ  ａｎｄ  Ｍａｒｋｅｔｓ  Ａｕｔｈｏｒｉｔｙ）のためのＡＰＩプロキシを含み得る。他の例では、任意の数の追加のＡＰＩプロキシが、任意の数の異なるアプリケーション１３６のＡＰＩゲートウェイプラットフォーム１１０内に含まれ得る。システム１００は、実際のサービスロジック自体をＡＰＩゲートウェイプラットフォームの内側に組み込む能力を含む広範な機能を提供し得る。代替的または追加的に、プラットフォームは、主要ビジネスロジックおよびコード要素を、カスタムサービス層１１２などの専用サービス層内のＡＰＩ構成自体から分離することを可能にし得る。
【００１７】
カスタムサービス層１１２の形での専用サービス層が、少なくとも２つの理由のために設けられ得る。第１に、良好な関心の分離を維持するため、およびより分離した設計を可能にするためであり、第２に、異なる要素が互いから独立して拡大縮小するのを可能にするためである。関心の分離はまた、例えば、個々のサービスコンポーネントを他の技術により書くことまたはある点において別のＡＰＩゲートウェイ製品に移行することなどの、異なる層で異なる実装コンポーネント／技術を使用する可能性から保護し得る。異なる要素が互いから独立して拡大縮小されるのを可能にすることは、例えば、プラットフォームを単一のモノリシックなアプリケーションとして拡大縮小する必要性を回避し得、かつ／または異なるサービスが異なる時に異なるレベルに拡大されることを可能にし得る。カスタムサービス層１１２とサードパーティプロバイダサービス１０４との間の通信、ならびにＡＰＩゲートウェイプラットフォーム１１０とサードパーティプロバイダサービス１０４との間の通信は、ネットワーク１１４を介してもよい。
【００１８】
図２は、開発者サービスポータル１０８、ＡＰＩゲートウェイプラットフォーム１１０、およびカスタムサービス層１１２の機能を例示する、システム１００のブロック図の例である。カスタムサービス層１１２は、消費者１０８などのエンドユーザにサービスを提供するためのロジックを収納するために使用され得る個々のサービスの実装を提供する回路を含み得る。カスタムサービス層１１２は、利用可能なサービスの各々のためのマイクロサービスおよびユーティリティのコレクションであり得、これは、サービスごとに水平にスケールアウトするネイティブな能力を可能にし、同じサービスの異なるインスタンス間のネイティブな負荷分散を提供する、コンテナ化された環境内で実行され得る。代替的または追加的に、マイクロサービスのうちの少なくとも一部は、コンピュータサーバ上で直接実行され得る（仮想的または物理的）。
【００１９】
カスタムサービス層１１２は、ｎｏｄｅ．ｊｓまたは他の技術で実装されたマイクロサービスなどの、一組のマイクロサービス２０２を含み得る。マイクロサービス２０２は、ＪｓｏｎファイルもしくはＸＭＬファイルまたは類似の表現などの構成エンティティ２０４を入力として使用して、システム１００のコアロジック、変換、マッピング、および鍵取り扱いコンポーネントを提供し得る。それぞれのアプリケーション１３６のためのＡＰＩゲートウェイプラットフォーム１１０内で定義された任意の数のＡＰＩプロキシ２０６の各々は、提供されているサービスの実装ロジックを提供する対応するマイクロサービス２０２または一連のマイクロサービスにより支援またはサポートされ得る。マイクロサービス２０２は、セキュリティゾーン２０７内でマイクロサービス１、マイクロサービス２などとして個別的かつ別々に実行され得る。ある例示的な構成では、マイクロサービスが実行され得る２つ以上の異なるセキュリティゾーン、セキュリティ領域、管轄区域、または他の形態のコンテナシステム（複数可）が、運用され得る。一部の例では、マイクロサービスは、異なる国家内などの異なるセキュリティゾーン内に複製され得る。追加的または代替的に、マイクロサービスは、取り扱われている対応するデータのセキュリティ、秘密保持、および分離をサンドボックス（複数可）により提供される制限されたオペレーティングシステム環境内で維持するように、サンドボックス内で実行され得る。
【００２０】
ある例では、システム１００は、マイクロサービス（マイクロサービス１）を実行して競合サービスプロバイダ１１８である一群のサービスプロバイダ２１４の複数の異なる外部ＡＰＩ２１２に対してコールを行うことにより、支払サービス指令２（ＰＳＤ２：Ｐａｙｍｅｎｔ  Ｓｅｒｖｉｃｅｓ  Ｄｉｒｅｃｔｉｖｅ  ２）を実装する銀行アプリケーションなどのアプリケーション１３６に所定の種類のサービスを提供し得る（図１）。例えば、銀行アプリケーションは、ＡＴＭロケータアプリケーションであり得る。別の例では、システム１００は、マイクロサービス（マイクロサービス２）の実行により、公認管理会計士（ＣＭＡ：ｃｅｒｔｉｆｉｅｄ  ｍａｎａｇｅｍｅｎｔ  ａｃｃｏｕｎｔａｎｔ）のためのアプリケーションなどのアプリケーション１３６に異なる所定の種類のサービスを提供し得る。さらに別の例では、システム１００は、マイクロサービス（マイクロサービス３）を実行してＡＰＩ鍵管理を独立して、または他の所定のサービスと共に提供することにより、さらに別の異なる種類のサービスをアプリケーション１３６に提供し得る。他の例では、任意の数の追加の異なる種類の所定のサービスを提供する拡張可能な鍵管理システム１００の機能をサポートするために、任意の数の他のマイクロサービスの実行が、含まれ得る。
【００２１】
ある例示的な構成では、拡張可能な鍵管理システム１００を使用して提供されるサービスは、コアサービスと言うこともできる４つの異なるサービス種類または種類のサービスに機能的に分割され得る。
【００２２】
集約サービス
これらは、消費者デバイス１３２が複数のサービスプロバイダ２１４からの統合、集約された応答にアクセスするための、単一の統一されたエントリポイントを提供するコアサービスであり得る。消費者デバイス１３２を使用するユーザにより実行されているアプリケーション１３６からのサービス要求の受信に続いて、サービス要求内に含まれる要求パラメータが、外部ＡＰＩ２１２を提供するサービスプロバイダ２１４のうちのいくつかの異なる該当するソースに対してそれぞれのＡＰＩサービスコールとして送付され得るように、集約サービスが、構成エンティティ２０４により適合され得る。追加的に、サービスプロバイダ２１４のうちの該当するソースの外部ＡＰＩ２１２からの応答は、適合された集約サービスにより、単一の応答に統合され得る。例えば、集約の種類のサービスは、マイクロサービス１が構成エンティティ１により動的に適合された後に、マイクロサービス１により提供され得る。この例では、ひとたび構成エンティティ１により動的に適合されると、マイクロサービス１は、適合された状態のマイクロサービス１を使用して集約サービスにより異なる応答がそこから受信および集約され得る、複数の異なるサービスプロバイダソース２１４を表すいくつかの異なる外部ＡＰＩ２１２に対して集約サービスが独立したコールを行うことができるように、構成され得る。
【００２３】
選択サービス
これらは、消費者が、アプリケーション１３６を使用して、サードパーティプロバイダサービス２１４の中の複数のソースから公開されている選択された利用可能な外部ＡＰＩ２１２のうちの１つにアクセスするための、単一の統一されたエントリポイントを提供するコアサービスであり得る。特定のサービスに関するユーザからのサービス要求の受信に続いて、要求パラメータを、選択サービスにより問い合わせて、要求の所望の最終ターゲットを決定し得る。選択サービスは、どの命令パラメータを使用すべきかを決定するためだけではなく、この決定を行うように選択サービスを動的に適合させるためにも、構成エンティティ２０４を使用し得る。次いで、要求は、単一の特定のターゲットサービスプロバイダ２１４の外部ＡＰＩ２１２に送付され得、単一の特定のターゲットサービスプロバイダ２１４は、適合された選択サービスを使用して生成されるＡＰＩサービスコールメッセージ内への命令パラメータの統合に基づいて決定される。例えば、選択の種類のサービスは、マイクロサービス２が構成エンティティ２により動的に適合された後に、マイクロサービス２により提供され得る。この例では、ひとたび構成エンティティ２により動的に適合されると、マイクロサービス２は、選択サービスを有効化して、単一の特定のターゲットサービスプロバイダ２１４の外部ＡＰＩ２１２をコールし、適合された状態のマイクロサービス２を使用して受信するように構成され得る。
【００２４】
鍵管理サービス
これらは、サービス要求がシステム１００を通じてプロキシ送信されることを促進するコアサービスであり得る。鍵管理サービスは、統一された開発者／アプリケーションＡＰＩ鍵管理能力を透過的に要求元アプリケーションに提供し得る。鍵管理サービスは、カスタムサービス層１１２によりＡＰＩゲートウェイプラットフォーム１１０に提供され得る。一般に、鍵管理サービスは、コールされているサードパーティ外部ＡＰＩ２１２がＡＰＩ鍵を必要とするときはいつでも、呼び出され得る。開発者が新しいサードパーティＡＰＩ２１２を能力として開発者のアプリケーション１３６に加えるとき、鍵管理サービスは、サードパーティプロバイダサービス１０４における開発者のアカウントを透過的かつ自動的に作成し、鍵管理サービスにより開発者のアプリケーション１３６に関連付けられた、新しいサードパーティＡＰＩ２１２をコールする際に使用するためのサブ鍵を取得し得る。アプリケーション１３６に対するユーザ入力は、アプリケーション１３６がシステム１００に対してサービス要求を行うという結果をもたらし得る。システム１００は、サービス要求に応答して、ＡＰＩサービスコールメッセージ（複数可）を生成し、ＡＰＩ鍵を必要とするサードパーティＡＰＩ（複数可）に送信し得る。ＡＰＩサービスコールメッセージ（複数可）の生成および送信の一環として、鍵管理サービスは、それぞれのサブ鍵を必要とする１つ以上のＡＰＩ製品を公開するように、独立して、または集約サービスと共に、もしくは選択サービスと共に、使用され得る。例えば、鍵管理の種類のサービスは、マイクロサービス３により提供され得る。この例では、マイクロサービス３は、鍵管理サービスが集約サービスまたは選択サービスと共に協働的に、または独立して動作してそれぞれのアプリケーションのＡＰＩ鍵を管理することができるように、構成され得る。
【００２５】
ユーティリティサービス
３つの上述のサービス種類（コアサービス）により使用される汎用能力のうちのいくつか、例えば集約、選択、鍵管理、を提供するために、追加のユーティリティサービスが、第４のコアサービス種類として利用可能であり得る。ユーティリティサービスは、コアサービスにより、汎用サービスがユーザ／クライアントからの所与の要求に合うように特に仕立てられることを可能にする必要なパラメータと共にコールされ得る。このような１つのコアサービスが、構成エンティティ２０４にアクセスする構成ルックアップサービスである。
【００２６】
図２では、ユーザ／クライアントは、例えば、スマートフォンアプリケーションを実行してＡＰＩゲートウェイプラットフォーム１１０内に含まれるＡＰＩプロキシ２０６と通信するスマートフォンなどの、アプリケーション１３６を実行するための消費者デバイス１３２を使用し得る。追加的または代替的に、エンドユーザは、消費者デバイス１３２を使用して、ＡＰＩゲートウェイプラットフォーム１１０と通信し得る。追加的に、開発者は、開発者デバイス１３０を使用して、開発者サービスポータル１０８内に含まれる開発者アクセスポイントおよびツールキット２０８と通信し得る。ＡＰＩゲートウェイプラットフォーム１１０および開発者アクセスポイントおよびツールキット２０８は、開発者デバイス１３０による開発者サービスポータル１０８へのアクセスの間、双方向に通信し得る。開発者サービスポータル１０８は、アプリケーション用に分析画面をレンダリングする要求などの、ＡＰＩゲートウェイプラットフォーム１１０から情報を要求し得、またはＡＰＩゲートウェイプラットフォーム１１０は、開発者サービスポータル２０８に情報をプッシュし得る。情報は、例えば、開発者による新しいＡＰＩプロキシ２０６の配備などの、アプリケーション１３６に対する管理上の変更に応答して、開発者サービスポータル１０８にプッシュされ得る。
【００２７】
追加的に、ＡＰＩゲートウェイプラットフォーム１１０は、カスタムサービス層１１２と通信して、コア能力サービスおよび／またはユーティリティにアクセスし得る。カスタムサービス層１１２は、下流のサードパーティプロバイダサービス１０４の外部ＡＰＩ２１２と選択的に通信し得る。複数の異なるサードパーティプロバイダ２１４の各々は、個別的に、かつ独立して、カスタムサービス層１１２またはＡＰＩゲートウェイプラットフォーム１１０と通信し得る。他の例では、本明細書に記載のサービスの機能は、より少ないサービス種類または追加のサービス種類に分割され得る。
【００２８】
この能力を動かすために使用されるコア技術は、システム１００のカスタムサービス層１１２の設計および実装内に収納され得る。拡張可能な鍵管理システム１００の狙いは、サービスプロバイダ２１４内に存在する少なくとも３つのカテゴリスタイルのＡＰＩ、すなわち以下のものの作成および整備を可能にする汎用機構を提供することである。
【００２９】
集約スタイルＡＰＩ  −  既存サービスが外部ＡＰＩ２１２により、要求の性質またはコンテキストに基づいて、競合サービスプロバイダ１１８（図１）などの、サードパーティプロバイダサービス１０４の中から選択された複数のＡＰＩプロバイダ２１４から提供されている場合、ＡＰＩのカテゴリまたはスタイルであり得る。旅行に関係する要求に応答することができるとして識別される複数の旅行サービスプロバイダなどの、複数のＡＰＩプロバイダ２１４は、類似のサービスを提供することに基づいて選択され得る。選択されたＡＰＩプロバイダ２１４のそれぞれのＡＰＩ２１２は、異なるＡＰＩエンドポイント構成を有し得、もしかすると、選択されたＡＰＩプロバイダ２１４間で組み合わされるとき、より大きな価値および関連性がある共通の一組の機能／データを提供する異なる実装（例えば、入力パラメータ、出力フォーマットなど）を有する。例としては、以下のものが挙げられる。
ａ．複数の異なる銀行により提供される銀行支店位置ＡＰＩ。
ｂ．複数の異なるホテルチェーンにより提供されるホテル予約および価格情報ＡＰＩ。
ｃ．複数の異なる航空会社により提供される飛行時間情報ＡＰＩ。
【００３０】
選択スタイルＡＰＩ  −  ＡＰＩ消費者（ユーザ／クライアント）が、資格証明書を有する個々のサービスのサービスプロバイダ１２０などの、ＡＰＩプロバイダ２１４のうちのただ１つと共に動作を遂行することを希望する場合にコールされるＡＰＩのカテゴリまたはスタイルであり得る（図１）。選択スタイルＡＰＩは、資格証明書を有する個々のサービスのサービスプロバイダ１２０などの、類似または無関係のサービスを提供することができるサービスプロバイダ１０４からのものであり得る（図１）。ＡＰＩ２１２は、特に個々の要求のためのものであってもよく、または代替的に、集約スタイルＡＰＩカテゴリのＡＰＩと同じまたは類似のＡＰＩであってもよい。サードパーティプロバイダサービス１０４の中からのＡＰＩプロバイダ２１４のＡＰＩ２１２の個々の選択は、システム１００により、クライアント／ユーザにより渡されるプロバイダ固有の情報（例えば、入力パラメータ、要求ヘッダ、セキュリティトークン、および／またはシステム内のユーザ／クライアント相互作用に関連付けられた他の情報）を介して決定され得る。ユーザの既存アカウントにアクセスする要求などの、特定のサードパーティプロバイダサービスに差し向けられたユーザ要求の場合、ユーザのアカウントに関連付けられた特定のターゲットＡＰＩプロバイダ２１４および対応するＡＰＩ２１２は、ユーザ要求に関連付けられたプロバイダ固有の情報に基づいてシステム１００により識別され得る。代替的に、要求が、システムにより複数のＡＰＩプロバイダ２１４に対するものとして識別される場合、システム１００は、ユーザと複数のＡＰＩプロバイダ２１４との間の通信を監視して、特定のターゲットＡＰＩプロバイダ２１４に差し向けられたプロバイダ固有の情報を識別し得る。この場合、ユーザからの初期要求はシステム１００により複数のＡＰＩプロバイダ２１４のＡＰＩ２１２に差し向けられるので（集約スタイルＡＰＩと同様に）、特定のターゲットＡＰＩプロバイダ２１４は、当初は選択されず、続いて、システム１００により、特定のターゲットＡＰＩプロバイダ２１４および対応するターゲットＡＰＩ２１２が、ユーザからの通信に関連付けられたプロバイダ固有の情報に基づいて、選択される。例としては、以下のものが挙げられる。
ａ．ユーザの銀行に固有の支払要求。
ｂ．一群のレンタカー会社内の料金を比較し、次いでそこで予約を行う単一のレンタカー会社を選択することにより、選択されたレンタル会社のうちの１つから自動車を賃借する。
ｃ．一群の映画館における映画を閲覧した後、選択された映画館のうちの１つから映画チケットを予約する。
【００３１】
単一鍵ＡＰＩ  −  独立して動作し、システム１００の外側からＡＰＩ鍵を使用してアクセス可能であるが、拡張可能な鍵管理システム１００を通じてＡＰＩ鍵の使用を必要としないＡＰＩと共に、またはそれに加えてシームレスに利用可能にされる、ＡＰＩのカテゴリまたはスタイルであり得る。システム１００は、特定のＡＰＩがＡＰＩ鍵を必要とするか、または必要としないかにかかわらず、ＡＰＩ２１２に対する単一チャネルアクセスを提供するこの単一チャネルアクセスは、コールされているＡＰＩがＡＰＩ鍵を有する場合と有さない場合とがある集約サービスの使用に関して単一のビューを可能にする。追加的に、サービスのための単一の請求／支払いなどの選択サービスは、ＡＰＩ鍵を必要とする場合があるか、または必要としない場合があるＡＰＩにアクセスするために、同じ単一のチャネルを通じて呼び出され得る。さらに、アプリケーションがアプリケーションへのユーザ入力に基づいて特定のＡＰＩに関するサービス要求を行う場合、システムは、ＡＰＩ鍵が必要とされる場合、自動的にＡＰＩ鍵を取り出して要求に適用し、特定のサービスのための適切なＡＰＩ鍵の取り出しおよび提出に関連する複雑性からユーザを保護し得る。
【００３２】
様々な異なるＡＰＩへの単一チャネルユーザアクセスは、任意のサードパーティＡＰＩ２１２の単一の開発者ＡＰＩセキュリティ鍵を使用して達成され得る。一意的な開発者ＡＰＩセキュリティ鍵は、システム１００のユーザである各開発者に関連付けられている。システム１００は、サードパーティＡＰＩ２１２が開発者のアプリケーションに関連付けられているとき、このようなサードパーティＡＰＩ２１２の任意の数の異なるセキュリティトークンまたはＡＰＩ鍵を動的に取得し得る。次いで、たとえ異なるサービスプロバイダ２１４のＡＰＩ２１２の各々がそれら自体の別々のＡＰＩ鍵を必要とするとしても、システム１００は、単一の開発者ＡＰＩ鍵を使用して異なるサービスプロバイダ２１４のＡＰＩ２１２をコールし得る。このことは、広範なＡＰＩを使用して消費、監視、および支払を行う機構を大いに単純化することにより、相当の価値をＡＰＩの消費者に加える。例としては、以下のものが挙げられる。
ａ．ソーシャルメディアＡＰＩ（例えば、Ｆａｃｅｂｏｏｋ、Ｔｗｉｔｔｅｒ）。
ｂ．マッピングＡＰＩ（例えば、Ｇｏｏｇｌｅ  Ｍａｐｓ、Ａｐｐｌｅ  Ｍａｐｓ）。
ｃ．通信ＡＰＩ（テキストメッセージ、通話、電子メール）。
【００３３】
図３は、コンテキスト層３０２とコアサービス層３０４とを含む、拡張可能な鍵管理システム１００内の例示的なカスタムサービス層１１２を例示するブロック図である。ＡＰＩゲートウェイプラットフォーム１１０およびサードパーティプロバイダサービス１０４も、それぞれの外部ＡＰＩ２１２と共に例示されている。
【００３４】
カスタムサービス層１１２の能力を提供する際に必要とされる技術的機構は、コンテキストサービス層３０２により提供されるコンテキストサービスと、コアサービス層３０４により提供されるコアサービスとの間のきれいな隔離を提供することによりそれ自体を分化させる。これは、集約、選択、鍵作成／管理、および他のユーティリティサービスが、システム１００のコアサービス層３０４により一元的かつステートレスに取り扱われることを可能にする一方、提供されているサービスの知識およびコンテキストは、サービスコンテキスト層３０２により渡される。
【００３５】
任意の数のコア能力サービス３０８が、コアサービス層３０４内でサービスの種類として、独立してステートレスかつ汎用的に動作し得る。図３の例では、第１のコア能力サービス３０８Ａ、第２のコア能力サービス３０８Ｂ、および第３のコア能力サービス３０８Ｃが図示されている。第１のコア能力サービス３０８Ａは、例えば、集約サービス３１０の機能を提供し得、第２のコア能力サービス３０８Ｂは、例えば、選択サービス３１２の機能を提供し得る。追加的に、第３のコア能力サービス３０８Ｃは、例えば、鍵管理サービス３０８Ｃの機能を提供し得る。他の例では、他の任意の機能が、第１、第２、第３などのコア能力サービス内で具現化され得、または機能は、異なるコア能力サービスもしくは複数のコア能力サービス内で具現化され得る。コア能力サービス３０８のステートレスかつ汎用の機能は、コア能力サービス３０８の各々が、構成エンティティにより適合されるとき、ただ１つの特定の種類の動作を効率的かつ確実に遂行することを可能にする。よって、コア能力サービス３０８Ａ、３０８Ｂ、３０８Ｃ、・・・の各々の動作は、数学的な意味での「純粋関数」のプロファイルと共に振る舞う  −  すなわち、返り値は、提供される入力値のみにより決定され、観察可能な副作用を有さない。このことは、コアサービス層３０４内のコア能力サービスが、コア能力サービスが遂行している動作のコンテキストと、入力または出力のいずれかとしてコア能力サービスを通過するデータの意味との両方に気づかないままの状態にとどまり得ることを意味する。このコア能力サービス３０８Ａ、３０８Ｂ、および３０８Ｃ内における認知度の必要性がないことは、サービスの設計を大いに単純化し、システムの保守容易性、試験可能性、およびスケーラビリティを増大させる。
【００３６】
コア能力サービス３０８の各々はステートレスかつ汎用の機能であるので、任意の数の異なる構成エンティティのうちの１つを、コア能力サービス３０８の各々に選択的に適用または渡して、それぞれのコア能力サービス３０８を、様々な異なるサービスプロバイダのうちの任意のものおよびそれらの対応するＡＰＩ（複数可）と通信するように、独立して動的に適合させ得る。よって、単一のコア能力サービス３０８の機能は、第１の特定のＡＰＩとのＡＰＩ固有の通信のための特定の記憶された構成エンティティを渡すことにより動的に適合され、次いで、第２の特定のＡＰＩとのＡＰＩ固有の通信のための異なる記憶された構成エンティティを、第１の特定のＡＰＩとは異なる通信プロトコルおよび／またはフォーマットで渡すことにより別様に動的に適合され得る。
【００３７】
鍵管理サービス３１４は、アプリケーションの開発者が初めて外部ＡＰＩをアプリケーションに関連付けるとき、外部ＡＰＩ２１２のＡＰＩ鍵をアプリケーションとシームレスかつ自動的に関連付ける能力を提供する。追加的に、サードパーティプロバイダサービス１０４のＡＰＩ２１２が、それぞれの外部ＡＰＩ２１２をコールするアプリケーションを識別するためにＡＰＩ鍵を必要とする場合、鍵管理サービス３１４は、ＡＰＩ鍵をＡＰＩゲートウェイ１１０とサードパーティプロバイダサービス１０４のＡＰＩ２１２との間の通信に注入し得る。鍵管理サービス３１４は、独立して、または集約サービス３１０もしくは選択サービス３１４と共に、呼び出され得る。鍵管理サービス３１４は、それぞれのアプリケーションがサードパーティプロバイダサービス１０４のＡＰＩ２１２と通信することを可能にするセキュリティ関連情報の記憶、振り当て、および管理も提供する。
【００３８】
鍵管理サービス３１４は、ＡＰＩ鍵記憶装置３１８を含み得、ＡＰＩ鍵記憶装置３１８は、メモリ内に記憶されたデータベース、データファイル、または何らかの他のデータ記憶システムであり得る。ＡＰＩ鍵記憶装置３１８内には、マスター鍵３１９および任意の数の開発者鍵３２１が記憶され得る。ＡＰＩ鍵に関連付けられた秘密、トークン、および／または他の任意のセキュリティ関連データも、ＡＰＩ鍵記憶装置３１８内に記憶され得る。
【００３９】
マスター鍵３１９の各々は、それぞれのサードパーティプロバイダサービス１０４の外部ＡＰＩ２１２に対して、拡張可能な鍵管理システムを識別するために使用されるＡＰＩ鍵であり得る。よって、システムによりコールされる各外部ＡＰＩ２１２のためのマスター鍵３１９が存在し得る。マスター鍵３１９は、サードパーティプロバイダサービス１０４からサブ鍵３２３を取得するために、鍵管理サービス３１４により使用され得る。マスター鍵３１９は、拡張可能な鍵管理システムがそれぞれのアカウントを作成するとき、かつ／またはＡＰＩ鍵を必要とするサードパーティプロバイダサービス１０４の外部ＡＰＩ２１２と別の方法で関係を形成するとき、取得および記憶され得る。例えば、マスター鍵３１９は、それぞれの公開外部ＡＰＩ２１２をコールするための拡張可能な鍵管理システムの認可／オリエンテーションの際に、公開されているサードパーティプロバイダサービス１０４の外部ＡＰＩ２１２のために作成および記憶され得る。サードパーティプロバイダサービス１０４がプライベートである別の例では、マスター鍵３１９を取得するための拡張可能な鍵管理システムのオリエンテーションは、拡張可能な鍵管理システムがそれぞれのマスター鍵３１９を使用してそれぞれのプライベートサードパーティプロバイダサービス１０４のプライベート外部ＡＰＩ２１２をコールすることができるように、合意または他の契約ベースの取り決めを介してであり得る。
【００４０】
開発者鍵３２１は、拡張可能な鍵管理システムに関連付けられたそれぞれの開発者ごとに一意的に割り当てられた単一のシステムＡＰＩ鍵であり得る。開発者の開発者ＡＰＩ鍵３２１は、開発者により開発されているアプリケーション内で、ＡＰＩ鍵を必要とする全ての外部ＡＰＩ２１２をコールするためにその開発者により使用される単一のＡＰＩ鍵であり得る。よって、同じ開発者ＡＰＩ鍵３２１は、開発者のアプリケーション内で、任意の数の異なる、かつ全く無関係な外部ＡＰＩ２１２をコールするために開発者により使用され得る。開発者鍵３２１は、実際は、いずれの外部ＡＰＩ２１２をコールする際にも使用されない。そうではなくて、開発者の開発者鍵３２１は、ＡＰＩ鍵記憶装置３１８内に、開発者により開発されたアプリケーションと、開発者のアプリケーションからコール可能な外部ＡＰＩ２１２の任意の数のサブ鍵とに関連付けて記憶される。
【００４１】
サブ鍵３２３は、鍵管理サービス３１４により要求され得る。鍵管理サービス３１４は、サードパーティプロバイダサービス１０４のＡＰＩ２１２を初めて有効化する開発者に代わって、対応するアプリケーションのための新しいＡＰＩ鍵を自動的かつ動的に作成および管理するために呼び出され得る。ある例では、鍵管理サービス３１４は、ＡＰＩゲートウェイプラットフォーム１１０内のＡＰＩプロキシの作成を監視し得る。開発者のアプリケーション内で新しいＡＰＩが有効化されたために新しいＡＰＩプロキシが作成されると、鍵管理サービス３１４は、新しい対応するサブ鍵を動的かつ自動的に取得し得る。
【００４２】
アプリケーションのための新しいＡＰＩ鍵の作成は、マスター鍵１１８に基づき得る。鍵管理サービス３１４により作成されるマスター鍵およびＡＰＩ鍵は、ＡＰＩ鍵記憶装置３１８内に記憶され得る。ＡＰＩ鍵は、それぞれのアプリケーションと、それと共にＡＰＩ鍵が使用されるＡＰＩ製品の識別子とに関連付けて記憶され得る。ＡＰＩ鍵は、ＡＰＩ製品を提供するサードパーティプロバイダサービス１０４からマスター鍵を使用して取得されたサブ鍵であり得る。鍵管理サービス３１４は、マスター鍵をシステムの認証および識別情報として使用して、アプリケーションのためのサブ鍵を自動的に要求し得る。ＡＰＩ鍵を求める要求を鍵管理サービス３１４から受信すると、ＡＰＩ製品のサードパーティプロバイダサービス１０４は、鍵管理サービス３１４がマスター鍵を介してサブ鍵を受信する認可を受けていることを確認し得る。マスター鍵に基づいてアプリケーション用に生成されたサブ鍵を受信すると、サブ鍵は、鍵管理サービス３１４により、アプリケーションと、ＡＰＩ鍵記憶装置３１８内に記憶された対応する関連付けとに自動的にマッピングされ得る。
【００４３】
カスタムサービス層１１２内には、一組のユーティリティサービス３１６も含まれている。ユーティリティサービス３１６は、コアサービス層３０４内の他のサービスをサポートし、またはキャッシング、要求管理などの、追加の共通能力を提供し得る。
【００４４】
コアサービス層３０４内のコア能力サービス３０８Ａ、３０８Ｂ、および３０８Ｃを補足するのが、ユーザ対面機能を提供し得るサービスコンテキスト層３０２内のコンテキストサービス３２０である。図３の例では、第１のコンテキストサービス３２０Ａ、第２のコンテキストサービス３２０Ｂ、第３のコンテキストサービス３２０Ｃ、および第４のコンテキストサービス３２０Ｄが、示されている。他の例では、任意の数のコンテキストサービス３２０が、カスタムサービス層１１２内に存在し得る。コンテキストサービス３２０は、ＡＰＩゲートウェイプラットフォーム１１０により選択されて、ＡＰＩゲートウェイプラットフォーム１１０により受信された要求に作用し得る。
【００４５】
ＡＰＩゲートウェイ１１０は、ＡＰＩエンドポイント（ＵＲＬ）、ロジック、および／または引数に基づいて、到着する要求を適切なＡＰＩプロキシにルーティングするためのロジックを提供し得る。ＡＰＩゲートウェイプラットフォーム１１０内に記憶されたＡＰＩプロキシ２０６は、特定のコンテキストサービスに向く（もしくはそれとリンクされる）ように構成され得るか、または代替的に、複数のＡＰＩプロキシ２０６が、特定のそれぞれのコンテキストサービスとリンクされ、もしくは関連付けられ得る。よって、ＡＰＩプロキシがコールされるとき、対応するコンテキストサービスが選択される。例えば、あるＡＰＩプロキシは、サービス種類を集約サービスとして識別し得るコンテキストサービスにリンクされ得、別のＡＰＩプロキシは、サービス種類を選択サービスとして識別し得るコンテキストサービスにリンクされ得、さらに別のＡＰＩプロキシは、サービス種類を鍵管理サービスとして識別し得るコンテキストサービスにリンクされ得る。ある例では、各ＡＰＩプロキシは、特定のそれぞれのコンテキストサービスに向くように構成され得る。しかしながら、他の例では、識別されたコンテキストサービスがＡＰＩプロキシのうちの１つ以上に関連付けられた引数に基づいて選択され得るように、複数のＡＰＩプロキシは、同じコンテキストサービスにリンクするように構成され得る。代替的な例では、複数のＡＰＩプロキシが、変形パラメータに基づいて対応するコンテキストサービスを選択するロジックにより、複数のコンテキストサービスにリンクされ得る。
【００４６】
サービスコンテキスト層３２０内の選択されたコンテキストサービスは、遂行されている動作のコンテキストを決定および識別または捕捉し、コア能力層３０８内のコア能力サービスを、選択されたコンテキストサービス（複数可）３２０Ａ〜Ｄのための作業を遂行するためのツールとして使用し得る。サービスコンテキスト層３２０内に含まれるコンテキストサービスは、コア能力サービス３０８から戻る相対的に生のデータを受信し得る。それぞれの選択されたコンテキストサービス（複数可）３２０Ａ〜Ｄはそれら自体、サービスのコンテキストを満たすために必要とされるフォーマット（複数可）への出力の必要なフォーマット処理を提供し得る。
【００４７】
コアサービス層３０４内には、構成ルックアップサービス３２４も含まれており、構成ルックアップサービス３２４は、ユーティリティサービス３１６内に含まれ得る。構成ルックアップサービス３２４は、サービスコンテキスト層３０２とコアサービス層３０４との間で、コア命令的な、入力データおよび出力データを渡すために使用され得る。構成ルックアップサービス３２４は、メモリ、データベース、または他のデータ記憶装置などのデータストア３２６と通信して、データストア３２６内に記憶された単純かつ容易に保守可能な構成エンティティ３２８のみに基づいて、汎用コア能力サービス３０８およびコンテキストサービス３２０により必要とされる複雑な命令、入力、および出力の組を記憶および選択する機構を提供するように実装され得る。記憶された構成エンティティ３２８は、コア能力サービス３０８に選択的に適用して、第１のコア能力サービス３０８Ａなどの選択された種類のコア能力サービスを、それぞれのサードパーティプロバイダサービス１０４の外部ＡＰＩと互換性を有するフォーマットおよび／またはプロトコルでＡＰＩ固有の通信を遂行するように、動的に適合させ得る。
【００４８】
よって、集約サービス３１０用として示されている種類の場合、第１のコア能力サービス３０８Ａは、第１のコンテキストサービス３２０Ａまたは第２のコンテキストサービス３２０Ｂなどのコンテキストサービス３２０により識別された記憶された構成エンティティ３２８を使用して動的に構成され得る。記憶された構成エンティティ３２８を使用した動的構成に続いて、コア能力サービス３０８Ａは、コンテキストサービス３２０Ａまたは３２０Ｂにより提供される入力パラメータのうちの少なくとも一部を含む、複数の異なるＡＰＩ固有のサービスコールメッセージを生成し得る。コンテキストサービス３２０Ｃにより選択サービス３１２用として識別された種類の場合、第３のコア能力サービス３０８Ｃなどのコア能力サービス３０８は、入力パラメータのうちの少なくとも一部を含むＡＰＩ固有のサービスコールを生成するように、異なる記憶された構成エンティティ３２８（これは、コンテキストサービス３２０Ｃにより識別される）を使用して動的に適合され得る。ＡＰＩ固有のサービスコールは、対応する構成エンティティ３２８内に記載の構成データと入力パラメータ値との組み合わせに基づいて、複数の異なる外部サードパーティプロバイダサービス１０４のうちの１つのみのただ１つのＡＰＩ２１２に通信され得る。よって、カスタムサービス層１１２は、サービスコールごとに複数の外部ＡＰＩ２１２を必要とする複雑な集約（およびフィルタなどの他の動作）を遂行するサービスを、従来の方法を使用して達成され得るよりもはるかに効率的、安全、試験可能、再利用可能であり、より少ないコードを必要とする様式で管理および保守する能力を提供し得る。
【００４９】
現金自動預け払い機（ＡＴＭ：ａｕｔｏｍａｔｅｄ  ｔｅｌｌｅｒ  ｍａｃｈｉｎｅ）を見つけ出すことに関係する集約サービス３１０の例示的な構成エンティティ３２８の一部分は、サードパーティプロバイダサービス１０４の各々に関して以下のものを含み、これは、この例ではサードパーティプロバイダ「銀行Ａ」に関する。
【００５０】
｛
“ｎａｍｅ”：  “ｂａｎｋ  Ａ”，
“ｐｒｏｄｕｃｔＮａｍｅ”：  “ｂｒａｎｃｈ−ｌｏｃａｔｏｒ”，
“ｐｒｏｄｕｃｔＤｅｆｉｎｉｔｉｏｎ”：  “ｂａｎｋ”，
“ｐｒｏｄｕｃｔ”：｛
“ｂａｓｅＵｒｌ”：  “ｈｔｔｐｓ：／／ｏｐｅｎａｐｉ．ｂａｎｋＡ．ｃｏ．ｕｋ／ｏｐｅｎ−ｂａｎｋｉｎｇ／ｖ１．２／ｂｒａｎｃｈｅｓ”，
“ｉｎｐｕｔＶａｒｉａｎｔｓ”：［“｛？ｐａｒａｍｓ＊｝”］，
“ｒｅｑｕｅｓｔＯｐｔｉｏｎｓ”：  ｛
“ｈｅａｄｅｒＰａｒａｍｓ”：  ｛
“Ｃｏｎｔｅｎｔ−Ｔｙｐｅ”：  “ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ”，
“ａｃｃｅｐｔ”：  “ｔｅｘｔ／ｈｔｍｌ，  ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ；  ｃｈａｒｓｅｔ＝ｕｔｆ−８，ａｐｐｌｉｃａｔｉｏｎ／ｘｈｔｍｌ＋ｘｍｌ，ａｐｐｌｉｃａｔｉｏｎ／ｘｍｌ；ｑ＝０．９，ｉｍａｇｅ／ｗｅｂｐ，＊／＊；ｑ＝０．８”
｝，
“ｍｅｔｈｏｄ”：  “ＧＥＴ”
｝，
“ｏｕｔｐｕｔＦｏｒｍａｔ”：  ｛
“ｄａｔａ”：  “ｄａｔａ”，
“ｂａｎｋＮａｍｅ”：
“ｄａｔａ［ｉ］．Ｏｒｇａｎｉｓａｔｉｏｎ．ＰａｒｅｎｔＯｒｇａｎｉｓａｔｉｏｎ．ＯｒｇａｎｉｓａｔｉｏｎＮａｍｅ．ＬｅｇａｌＮａｍｅ”，
“ｂｒａｎｃｈＮａｍｅ”：  “ｄａｔａ［ｉ］．ＢｒａｎｃｈＩｄｅｎｔｉｆｉｃａｔｉｏｎ”，
“ｓｔｒｅｅｔＡｄｄｒｅｓｓ”：  ［“ｄａｔａ［ｉ］．Ａｄｄｒｅｓｓ．ＢｕｉｌｄｉｎｇＮｕｍｂｅｒＯｒＮａｍｅ”，
“ｄａｔａ［ｉ］．Ａｄｄｒｅｓｓ．ＳｔｒｅｅｔＮａｍｅ”］，
“ｔｏｗｎ”：  “ｄａｔａ［ｉ］．Ａｄｄｒｅｓｓ．ＴｏｗｎＮａｍｅ”，
“ｐｏｓｔＣｏｄｅ”：  “ｄａｔａ［ｉ］．Ａｄｄｒｅｓｓ．ＰｏｓｔＣｏｄｅ”，
“ｃｏｕｎｔｒｙ”：  “ｄａｔａ［ｉ］．Ａｄｄｒｅｓｓ．Ｃｏｕｎｔｒｙ”，
“ｌｏｎｇｉｔｕｄｅ”：  “ｄａｔａ［ｉ］．ＧｅｏｇｒａｐｈｉｃＬｏｃａｔｉｏｎ．Ｌｏｎｇｉｔｕｄｅ”，
“ｌａｔｉｔｕｄｅ”：  “ｄａｔａ［ｉ］．ＧｅｏｇｒａｐｈｉｃＬｏｃａｔｉｏｎ．Ｌａｔｉｔｕｄｅ”，
“ａｔｍＡｔＢｒａｎｃｈ”：  “ｄａｔａ［ｉ］．ＡＴＭＡｔＢｒａｎｃｈ”，
“ｔｅｌｅｐｈｏｎｅＮｕｍｂｅｒ”：  “ｄａｔａ［ｉ］．ＴｅｌｅｐｈｏｎｅＮｕｍｂｅｒ”，
“ａｃｃｅｓｓｉｂｉｌｉｔｙ”：  “ｄａｔａ［ｉ］．ＡｃｃｅｓｓｉｂｉｌｉｔｙＴｙｐｅｓ”，
“ｏｐｅｎｉｎｇＴｉｍｅｓ”：  “ｄａｔａ［ｉ］．ＯｐｅｎｉｎｇＴｉｍｅｓ”
｝
｝
｝
【００５１】
「ｂｌｕｅｂａｎｋ」などの、単一の選択されたサードパーティプロバイダサービス１０４と通信するための、選択サービス３１２の記憶された構成エンティティ３２８の一例は、以下のとおりである。
【００５２】
｛
“ｎａｍｅ”：  “ｂｌｕｅｂａｎｋ”，
“ｐｒｏｄｕｃｔＮａｍｅ”：  “ｉｎｉｔｉａｔｅ−ｐａｙｍｅｎｔ”，
“ｐｒｏｄｕｃｔ”：  ｛
“ｂａｓｅＵｒｌ”：  “ｈｔｔｐｓ：／／ａｐｉ．ｕｓ．ａｐｉｃｏｎｎｅｃｔ．ｉｂｍｃｌｏｕｄ．ｃｏｍ／ａｃｉｔ−ｂｌｕｅｍｉｘ−ｓｔｕｄｉｏ−ｏｐｅｎｂａｎｋｉｎｇｐｓｄ２／ｓｂ／ｐａｙｍｅｎｔａｐｉ／ｐａｙｍｅｎｔ”，
“ｉｎｐｕｔＶａｒｉａｎｔｓ”：  ［“｛？ｐａｒａｍｓ＊｝”］，
“ｒｅｑｕｅｓｔＯｐｔｉｏｎｓ”：  ｛
“ｈｅａｄｅｒＰａｒａｍｓ”：  ｛
“ａｃｃｅｐｔ”：  “ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ”，
“ｋｅｙｓ”：  ［“ｃｌｉｅｎｔｓｅｃｒｅｔ”］
｝，
“ｍｅｔｈｏｄ”：  “ＧＥＴ”
｝，
“ｏｕｔｐｕｔＦｏｒｍａｔ”：  ｛｝，
“ｐｒｏｄｕｃｔＳｐｅｃｉｆｉｃＣｏｎｆｉｇ”：  ｛
“ｃｌａｉｍｓ”：  ｛
“ｐａｙｍｅｎｔｉｎｆｏ”：  ｛
“ｃｈａｌｌｅｎｇｅ＿ｔｙｐｅ”：  “ＳＡＮＤＢＯＸ＿ＴＡＮ”，
“ｖａｌｕｅ”：  ｛
“ａｍｏｕｎｔ”：  “｛｛ａｍｏｕｎｔ｝｝”，
“ｃｕｒｒｅｎｃｙ”：  “｛｛ｃｕｒｒｅｎｃｙ｝｝”
｝，
“ｔｏ”：  ｛
“ｒｅｍｏｔｅ＿ｎａｍｅ”：  “｛｛ｎａｍｅ｝｝”，
“ｒｅｍｏｔｅ＿ＩＢＡＮ”：  “｛｛ＩＢＡＮ｝｝”，
“ａｃｃｏｕｎｔ＿ｎｕｍｂｅｒ”：  “｛｛ａｃｃｏｕｎｔ＿ｎｕｍｂｅｒ｝｝”，
“ｒｅｍｏｔｅ＿ｂｉｃ”：  “｛｛ｂｉｃ｝｝”
｝，
“ａｄｄｉｔｉｏｎａｌ”：  ｛
“ｂｏｏｋｉｎｇ＿ｃｏｄｅ”：  “｛｛ｂｏｏｋｉｎｇ＿ｃｏｄｅ｝｝”，
“ｓｕｂｊｅｃｔ”：  “｛｛ｓｕｂｊｅｃｔ｝｝”，
“ｂｏｏｋｉｎｇ＿ｄａｔｅ”：  “｛｛ｂｏｏｋｉｎｇ＿ｄａｔｅ｝｝”，
“ｖａｌｕｅ＿ｄａｔｅ”：  “｛｛ｖａｌｕｅ＿ｄａｔｅ｝｝”
｝，
“ｔｙｐｅ”：  “｛｛ｔｙｐｅ｝｝”
｝
｝，
“ｉｓｓ”：  “ｈｔｔｐｓ：／／ａｃｃｅｎｔｕｒｅ．ｃｏ．ｕｋ”，
“ｓｃｏｐｅ”：  “ｐａｙｍｅｎｔ”，
“ａｃｒ＿ｖａｌｕｅｓ”：  “３”，
“ａｕｄ”：  “ｈｔｔｐｓ：／／ｓｂ−ａｃｉｔ−ｂｌｕｅｍｉｘ−ｓｔｕｄｉｏ−ｏｐｅｎｂａｎｋｉｎｇｐｓｄ２．ｄｅｖｅｌｏｐｅｒ．ｕｓ．ａｐｉｃｏｎｎｅｃｔ．ｉｂｍｃｌｏｕｄ．ｃｏｍ”，
“ｒｅｄｉｒｅｃｔ＿ｕｒｉ”：  “｛｛ｒｅｄｉｒｅｃｔ＿ｕｒｌ｝｝”，
“ｃｌｉｅｎｔ＿ｉｄ”：  “｛｛ｃｌｉｅｎｔ＿ｉｄ｝｝”，
“ｓｔａｔｅ”：  “２ｏｕＭＣｇＳｑＳ０ｅ”
｝
｝，
“ｐｒｏｄｕｃｔＤｅｆｉｎｉｔｉｏｎ”：  “ｂａｎｋ”
｝
【００５３】
集約サービス３１０により使用されるための構成エンティティ３２８は、選択サービス３１２により使用される構成ファイルとは異なり得る。各異なる集約活動のための構成エンティティ３２８が存在し得る。よって、例えば、集約サービス３１０の場合、様々な銀行サービスプロバイダの銀行ＡＴＭの位置を識別するために使用するための記憶された構成エンティティ３２８と、様々なホテルサービスプロバイダでホテルの部屋を検索する際に使用するための異なる記憶された構成エンティティ３２８とが存在し得る。それぞれのコンテキストサービス３２０Ａ〜Ｄは、特定の要求に関して、該当する記憶された構成エンティティ３２８を識別し得る。集約サービス３１０により使用されるための構成エンティティ３２８の各々は、サードパーティプロバイダサービス１０４のリストと、サービスコールなどのメッセージをそれぞれのサードパーティプロバイダＡＰＩ２１２に通信するためのプロトコルおよび／またはフォーマットと、受信した応答を（適宜）解釈および／または再フォーマットするためのマッピングと、を含み得る。
【００５４】
選択サービス３１２により使用されるための構成エンティティ３２８は、同様に、サードパーティプロバイダサービス１０４のリストと、サービスコールなどのメッセージをそれぞれのサードパーティプロバイダＡＰＩ２１２に通信するためのプロトコルおよび／またはフォーマットと、受信した応答を（適宜）解釈および／または再フォーマットするためのマッピングと、を含み得る。しかしながら、選択サービス３１２は、選択サービス３１２が入力パラメータを解釈し、適切なターゲットサードパーティサービス１０４を選択することを可能にする構成データも、それぞれの構成エンティティ３２８から受信する。したがって、単一のサービスコールメッセージのみが、ターゲットサードパーティプロバイダサービス１０４のそれぞれのＡＰＩ２１２に対するフォーマットで、行われる。
【００５５】
構成ルックアップサービス３２４は、任意の数の異なる外部ＡＰＩ２１２に関して、データストア３２２内に構成エンティティ３２８を含み得る。各外部ＡＰＩ２１２は、異なる構成エンティティ３２８に関連付けられ得る。複数のエンドポイントを同じサービスに対して公開するターゲットＡＰＩ２１２については、複数の異なる記憶された構成エンティティ３２８が、構成ルックアップサービス３２４内に含まれ得る。代替的または追加的に、同じ構成エンティティ３２８は、複数の異なるエンドポイントを公開するために使用され得る。構成エンティティ３２８は、データベース、リレーショナルデータベース、または構成ルックアップサービス３２４を介して集約サービス３１０および選択サービス３１２によりアクセスされ得る他の何らかの形態の記憶装置内に記憶され得る。それぞれの構成エンティティ３２８は、ＡＰＩサービスコール要求の受信に応答して、かつＡＰＩサービスコール要求に応答してのＡＰＩ２１２からの情報の返りに応答して、集約サービス３１０または選択サービス３１２によりアクセスされ得る。
【００５６】
第１の能力サービス３０８Ａおよび第２のコア能力サービス３０８Ｂとしてコアサービス内に含まれる集約サービス３１０および選択サービス３１２は、ＡＰＩ固有ではなく、異なる記憶された構成エンティティ３２８を使用して動的に適合して、サービスコンテキスト層３０２内のコンテキストサービス３２０Ａ〜Ｄから受信された要求をどうすべきかおよびどのようにコンテキストサービス３２０Ａ〜Ｄに応答を送り戻すべきかに関して異なる命令および実行パラメータの組を提供し得る。集約サービス３１０または選択サービス３１２が特定の要求のために使用されるべきかどうかを示すことに加えて、記憶された構成エンティティ３２８は、特定の要求および応答と共に使用するための入力パラメータも含み得る。入力パラメータは、ＡＰＩサービスコールメッセージの引数として提供され得、例えば、所与のターゲットＡＰＩ内のエンドポイントの識別情報、所与のターゲットＡＰＩが必要とする入力パラメータ、および／またはターゲットＡＰＩ出力パラメータとシステム内のパラメータとのマッピングが挙げられる。パラメータ間の１対１のマッピングに加えて、記憶された構成エンティティ３２８内に含まれるマッピングは、パラメータの変換も含み得る。例えば、ターゲットＡＰＩから提供されるアドレスなどの３つのパラメータは、システムにより提供されるアドレスなどの単一の出力パラメータにマッピングされ得る。
【００５７】
ターゲットＡＰＩは、任意の数の異なるエンドポイントを、異なるパラメータを使用する同じサービスに公開し得る。これらの状況においては、入力パラメータが、所望の情報を取り戻すためにコールすべき最も適切なエンドポイントを選択するようにコアサービスにより使用され得るように、情報は、記憶された構成エンティティ３２８内に含まれ得る。
【００５８】
記憶された構成エンティティ３２８は、入力パラメータの、選択された入力変形とのマッピングを含み得る。追加的に、入力が応答内でターゲットＡＰＩから戻されるとき、コア能力サービス３０８は、それぞれの構成エンティティ３２８を使用して、どのパラメータを抽出すべきかをマッピングに基づいて決定し得る。コア能力サービス３０８は、抽出されたパラメータを、それぞれのコンテキストサービス３２０Ａ〜Ｄに対して生の出力データとして提供し得、そこで生の出力データは、フォーマットされ得る。
【００５９】
図４は、図３を参照しながら説明したコンテキストサービス３２０Ａ〜Ｄとコア能力サービス３０８Ａ〜Ｃとの間の通信プロセスの例示的な動作の流れ図である。この例では、コア能力サービス３０８は、第１のコア能力サービス３０８Ａとしての集約サービス３１０の機能と、第２のコア能力サービス３０８Ｂとしての選択サービス３１２の機能と、第３のコア能力サービス３０８Ｃとしての鍵管理サービス３１４の機能と、を含み得る。
【００６０】
動作中、ＡＰＩゲートウェイ１１０は、ユーザにより実行されているアプリケーションから要求を受信し得る（４０２）。ＡＰＩゲートウェイ１１０は、要求に作用するコンテキストサービス３２０のうちの１つを選択し、要求を第１のコンテキストサービス３２０Ａなどの、コンテキストサービス３２０のうちの選択された１つに振り当てる。（４０４）第１のコンテキストサービス３２０Ａは、要求を構文解析し、要求を取り扱いまたは処理することができるコアサービス層３０４内のコア能力サービス３０８の種類を識別し得る。（４０６）コア能力サービス３０８の各々は、ただ１つの特定の種類の動作を遂行するので、第１のコンテキストサービス３２０Ａは、要求を満たすことができる１つの特定の種類の動作を識別するために、要求のコンテキストを決定し得る。第１のコンテキストサービス３２０Ａは、要求のコンテキストを決定するために、要求からパラメータを抽出し得る。例えば、第１のコンテキストサービス３２０Ａは、要求の性質は集約サービス３１０が必要とされるようなものであると決定し得、第１のコア能力サービス３０８Ａが選択され得る。
【００６１】
第１のコンテキストサービス３２０Ａは、要求を構文解析し、複数の記憶された構成エンティティ３２８のうちの１つの識別子、複数のパラメータ、およびサービス種類表示をコアサービス層３０４に渡し得る。（４０８）識別子は、データストア３２６内に記憶された構成エンティティ３２８の一意的な識別子であり得る。パラメータは、入力値であり得、入力値は、要求から抽出され、コアサービス層３０４に提供される。代替的または追加的に、パラメータは、第１のコンテキストサービス３２０Ａにより導出された入力値であり得る。例えば、コンテキストサービス層３２０Ａは、要求内に含まれる異なる変形を集約し、要求内に含まれる変形を所望のフォーマットに変換し、かつ／または要求から抽出された変形に基づいて入力パラメータを論理的に作成し得る。コアサービス層３０４に渡される要求は、要求からの任意のソース入力パラメータと共に、一組の必要な命令を通過し得る。追加的に、サービス種類表示は、第１のコンテキストサービス３２０Ａにより生成され、要求をさらに処理する特定のコア能力サービス、例えば集約サービス３１０もしくは選択サービス３１２、および／または鍵管理サービス３１４を識別するように渡され得る。第１のコンテキストサービス３２０Ａは、コア能力サービス層３０４から１つ以上のコア能力サービスを選び得る。ある例では、コア能力サービスは、第１のコンテキストサービス３２０Ａにより公開されている機能と内在的にリンクされ得る。よって、例えば、第１のコンテキストサービス３２０Ａにより公開される機能が集約サービス３１０および鍵管理サービス３１４のためのものである場合、第１のコア能力サービス３０８Ａは集約サービス３１０および鍵管理サービス３１４を遂行する機能を内在的に含むので、第１のコア能力サービス３０８Ａは、それに応じて、第１のコンテキストサービス３２０Ａにより識別されたそれぞれの構成エンティティ３２８を使用して動的に適合され得る。追加的または代替的に、第１のコンテキストサービス３２０Ａは、要求を評価して、求められている応答の種類を決定または予期し、それに応じてコア能力サービス（複数可）３０４および対応する構成エンティティ（複数可）を選ぶことにより、コア能力サービスのうちの１つ以上を選び得る。（４１０）この例示的な動作では、サービス種類表示は、コア能力サービス３０８Ａである集約サービス３１０を表示し得、結果的に集約サービス３１０がコールされる。（４１２）
【００６２】
集約サービス３１０は、複数のターゲット（サードパーティＡＰＩ２１２）に対して複数の並列要求を行い、サードパーティ１０４が返す出力から共通のデータ要件の組を抽出する能力を提供し得る。集約サービス３１０は、入力として構成エンティティ３２８のデータストア３２６内の位置を取り得、集約サービス３１０は、これを構成ルックアップサービス３２４を使用して取り出し得る。（４１４）構成エンティティ３２８は、以下のものを含み得る。
・集約サービスがその全てを集約すべき外部サードパーティサービスのリスト、
・第１のコンテキストサービス３２０Ａが公開するサポートされている入力のリスト、
・ユーザ／クライアントのアプリケーションに戻すべき必要とされる出力フィールドのリスト、ならびに
・各外部サードパーティサービスターゲットに関して：
○第１のコア能力サービス３０８Ａがサポートしている外部サービスプロバイダの各々により提供される、異なる有効なＵＲＬプロトコル変形、
○拡張可能な鍵管理システムの入力と外部サービスプロバイダの入力とのマッピング情報、および
○外部サービスプロバイダの応答から必要とされる出力の各々を抽出するための機構。
【００６３】
集約サービス３１０は、構成エンティティ３２８を使用して、各サービスに関してコールすることが可能なメッセージであり得るＵＲＬのリストを決定し得、第１のコンテキストサービス３２０Ａをコールすることにより提供される入力パラメータに基づいて最も適切なものを動的に選択する。（４１６）構成エンティティ３２８は、事実上静的かつ大いにキャッシュ可能であり得、集約されるＡＰＩコールメッセージの全体的性能に対するオーバーヘッドを最小にすることを可能にする。
【００６４】
外部サービスは、並列ＡＰＩコールメッセージによりコールされ得、応答メッセージ内の情報は、結果が第１のコア能力サービス３０８Ａに戻って到着するにつれて、集約され得る（構成可能なタイムアウトを条件とする）。（４１８）集約サービス３１０は、必要とされるデータを各データから抽出し、抽出されたデータを統一された生のデータ構造の一部としてコール元の第１のコンテキストサービス３２０Ａに返し得る。（４２０）第１のコンテキストサービス３２０Ａは、必要に応じて出力データをマージおよびフォーマットし得る。（４２２）追加的に、第１のコンテキストサービス３２０Ａは、要求に対する応答としてフォーマットされた出力データを返し得る。（４２４）
【００６５】
コンテキストサービス３２０により選ばれ、コールされるコア能力サービスはまた、サービス種類表示を選択サービスとして識別することにより、選択サービス３１２（例えば、第２のコア能力サービス３０８Ｂ）であり得る。（４２６）選択サービス３１２は、集約サービス３１０と概して類似した方法で働いて、コンテキストサービス３２０により識別された構成エンティティ３２８、この例では第３のコンテキストサービス３２０Ｃを、構成ルックアップサービス３２４を介して取り出し得る。（４２８）追加的に、選択サービス３１２は、可能なサードパーティプロバイダサービス１０４のターゲットリストを、要求を満たすことができ得る構成エンティティ３２８から決定し得る。（４３０）
【００６６】
可能なサードパーティプロバイダサービス１０４のリストから、選択サービス３１２は、ターゲットサードパーティプロバイダサービス１０４を識別し得る。（４３２）ターゲットサードパーティプロバイダサービス１０４は、ＡＰＩサービスコールメッセージが差し向けられている唯一のＡＰＩ２１２として識別され得る。ターゲットサードパーティプロバイダサービス１０４は、例えば、アプリケーションから受信した入力パラメータと評価を行うための基礎を提供する構成エンティティ３２８とに基づいて、選択サービス３１２により選ばれ得る。例えば、構成エンティティ３２８は、ターゲットサードパーティプロバイダサービスの選択を行うために使用すべき特定のパラメータ（複数可）と、選択サービス３１２は提供された入力パラメータをどのように解釈して選択を行うべきかとを示し得る。提供されるパラメータとしては、アカウント番号、ターゲットサードパーティプロバイダサービスの名称、ターゲットサードパーティプロバイダのセキュリティ情報、ターゲットサードパーティプロバイダサービス１０４の外部ＡＰＩ２１２の識別子、または選択サービス３１２が可能なサードパーティプロバイダサービス１０４のリストの中からターゲットサードパーティプロバイダサービス１０４を識別するために使用し得る他の何らかの情報アイテムが挙げられる。別の例では、第３のコンテキストサービス３２０Ｃは、利用可能な選択肢のリストからどのサービスプロバイダをターゲットサードパーティプロバイダサービスとして選択すべきかを識別し得る。この例では、コンテキストサービス３２０によるターゲットサードパーティプロバイダサービス１０４の識別／選択は、アプリケーションから受信した入力パラメータおよび構成エンティティ３２８に基づき得る。
【００６７】
集約サービス３１０により遂行されるように多くの並列要求を一群の外部サードパーティサービス１０４に対して送出するのではなく、ただ１つのサードパーティプロバイダサービス１０４を選ぶことの結果として、選択サービス３１２は、ただ１つのＡＰＩサービスコールメッセージをただ１つのＡＰＩ２１２に送出し得る。集約サービス３１０と同様に、構成ルックアップサービス３２４は、第３のコンテキストサービス３２０Ｃが、選択サービス３１２に情報を注入し、選択サービス３１２を、ＡＰＩサービスコールメッセージの特定のＡＰＩ２１２への特定のフォーマット処理を遂行しながら完全に汎用的に振る舞うように動的に適合させることができる機構を、構成エンティティ３２８の形で提供し得る。選択サービス３１２の構成エンティティ３２８は、以下のものを提供し得る。
・ターゲットサードパーティプロバイダサービス１０４を選択するために使用されるべき入力パラメータのフィールドまたはフィールドの組み合わせ、
・選択のための、可能なサードパーティプロバイダサービスターゲットのリスト、
・コンテキストサービスが公開するサポートされている入力のリスト、
・ユーザ／クライアントに戻すべき必要とされる出力フィールドのリスト、
・各外部サードパーティサービスターゲットに関して：
○選択サービス３１２によりサポートされている外部サービスの各々により提供される、異なる有効なＵＲＬプロトコル変形、
○拡張可能な鍵管理システムの入力と外部サードパーティサービスの入力とのマッピング情報、および
○選択されたターゲットサードパーティプロバイダからの外部サービス応答から、必要とされる出力の各々を抽出するための機構。
【００６８】
集約サービス３１０と同様に、選択サービス３１２は、それぞれの第３のコンテキストサービス３２０Ｃに依拠して、必要な入力および使用する記憶された構成エンティティ３２８への参照を提供し得、選択サービス３１２が集めた生のデータを返す。第３のコンテキストサービス３２０Ｃは、そのデータを取ること、およびデータを返すための適切な出力フォーマットを定義することを担当し得る。（４２２）追加的に、第３のコンテキストサービス３２０Ｃは、要求に対する応答としてフォーマットされた出力データを返し得る。（４２４）
【００６９】
コンテキストサービス３２０により選ばれ、コールされるコア能力サービスはまた、サービス種類表示を鍵管理サービスとして識別することにより、鍵管理サービス３１４であり得る。（４４０）鍵管理サービス３１４は、サードパーティプロバイダサービス１０４のためのプロキシサービスとして動作し得る。この役割において、鍵管理サービス３１４は、サードパーティプロバイダサービス１０４の外部ＡＰＩ２１２と、図１に例示する消費者デバイス１３２により実行されているアプリケーション１３６と連通しているＡＰＩゲートウェイプラットフォーム１１０との間で情報を渡し得る。鍵管理サービス３１４は、サードパーティＡＰＩが要求に応答するためにセキュリティ鍵（または公開鍵）を必要とするとき、カスタムサービス層１１２を通じてサードパーティＡＰＩのプロキシ送信を可能にするコア能力を提供し得る。
【００７０】
図１〜３を参照すると、複数のサービスプロバイダサービス１０４から公開された外部ＡＰＩ２１２をアプリケーション１３６内で使用することの欠点の１つは、アプリケーション１３６が使用することになる各サードパーティプロバイダサービス１０４および／または外部ＡＰＩ２１２との間でアカウントおよび開発者ＡＰＩ鍵を作成する必要性であり得る。追加的に、開発または実行されているアプリケーション内でのこれらのアカウントおよび対応する鍵の管理は、開発者にとって難題となり得る。よって、鍵管理サービス３１４の第１の能力は、それぞれのサードパーティプロバイダサービス１０４のサードパーティ外部ＡＰＩ２１２のための新しい鍵の自動的かつ動的な作成および管理を可能にすることであり得る。新しい鍵は、アプリケーション１３６の開発者がサードパーティ外部ＡＰＩ２１２と開発されているアプリケーション１３６とを開発者サービスポータル１０８により初めて関連付けるときに作成され得る（図１）。鍵に加えて、鍵管理サービス３１４に関して説明した機能は、同様に、アプリケーション１３６による外部ＡＰＩ２１２へのＡＰＩサービスコールに関係するパスワード、トークン、または他の任意の認証もしくはセキュリティ機構のために使用され得る。
【００７１】
図５は、鍵管理を遂行するための、拡張可能な鍵管理システムの例示的な動作である。図５の例示的な動作では、アプリケーションの新しいＡＰＩ鍵は、図１〜３を参照しながら記載したように、まず拡張可能な鍵管理システム１００を使用して追加され得る。開発者は、システムと共に使用するために開発されているアプリケーション１３６と共に動作するように、サードパーティ外部ＡＰＩ２１２を有効化し得る。（５０２）例えば、開発者は、マッピングプロバイダサービス１２４の地図位置ＡＰＩを、開発者により開発されている銀行アプリケーション（アプリケーション１３６）に新たに関連付けることを希望し得る。開発者サービスポータル１０８は、外部ＡＰＩ２１２（地図位置ＡＰＩ）がアプリケーション１３６（開発者の銀行アプリケーション）に新たに関連付けられていることを判定し得る。（５０４）鍵管理サービス３１８は、ＡＰＩプロキシ２０６がＡＰＩゲートウェイプラットフォーム１１０に追加されるときなど、新しい関連付けが認識されるとき、開発者サービスポータル１０８によりコールされ得る。（５０６）鍵管理サービス３１８は、アプリケーション１３６（開発者の銀行システム）の開発者が、外部ＡＰＩ２１２（地図位置ＡＰＩ）に関して、システム１００内に割り当てられた鍵をすでに有するかどうかを判定する。（５０８）もしなければ、鍵管理サービス３１８は、マスター鍵をシステム１００内の記憶装置から取り出し得る。（５１０）マスター鍵は、外部ＡＰＩ２１２（地図位置ＡＰＩ）へのアクセスを可能にするためにサードパーティプロバイダサービス１０４（マッピングプロバイダサービス１２４）との間で以前確立された、システム１００のマスターアカウントに関連付けられた公開鍵であり得る。
【００７２】
マスター鍵を使用することで、鍵管理サービス３１８は、開発者に代わって新しいサブ鍵をサードパーティプロバイダサービス１０４から要求し得る。（５１２）サードパーティプロバイダサービス１０４は、新しいサブ鍵を授与および提供し得る。（５１２）新しいサブ鍵は、マスター鍵を介してシステム１００のマスターアカウントに、かつシステム１００内の開発者のアカウントに、関連付けられ得る。（５１６）追加的に、コンテキストサービス３２０は、新たに追加されたＡＰＩプロキシ２０６にリンクされ得る。（５１８）新たに追加されたＡＰＩプロキシ２０６は、開発者の開発者鍵３２１を含むサービスコールメッセージをアプリケーションから受信し得、リンクされたコンテキストサービス３２０は、サービス種類を鍵管理サービスとして識別し、鍵管理サービス３１４をコールし得る。よって、開発者は、サードパーティプロバイダサービス１０４との間で新しいアカウントまたはＡＰＩ鍵を確立する必要がない。そうではなくて、鍵管理サービス３１８は、開発者に新しい外部ＡＰＩ２１２のための新しいアカウントと新しいＡＰＩ鍵（新しいサブ鍵）とを透過的かつ自動的に提供し、新しいＡＰＩ鍵（新しいサブ鍵）は、開発されているアプリケーション１３６とシステム１００内の開発者のアカウントとにシームレスに関連付けられる。このようにして、システム１００は、マスター鍵を介して、事実上、サードパーティプロバイダサービス１０４の外部ＡＰＩ２１２により提供されるサービスのユーザとして機能する。
【００７３】
鍵管理サービス３１４は、システム１００を使用するアプリケーション１００を有する開発者のためのＡＰＩ鍵記憶装置３１８も含み得る。ＡＰＩ鍵記憶装置３１８は、登録情報の記憶、保守、および検証を含み得る。登録情報は、対応するＡＰＩマスター鍵に関連付けられたＡＰＩサブ鍵と、サブ鍵が割り当てられている開発者、それぞれの外部ＡＰＩ、およびそれぞれのアプリケーションと、の記憶された記録を含み得る。追加的に、外部ＡＰＩの使用に関する条件は、鍵管理サービス３１４により開発者に提供され得る。それゆえに、システムを使用するアプリケーションを有する開発者は、それに対するサービスコールが開発者のアプリケーションに代わってシステムにより行われる異なる外部ＡＰＩに関連付けられたいくつかの異なるＡＰＩ鍵、パスワード、および他の秘密を管理しなくてもよい。そうではなくて、鍵は、システムにより透過的に管理され、開発者のアカウント、それぞれのアプリケーション、およびサードパーティプロバイダサービスのそれぞれの外部ＡＰＩに自動的に関連付けられる。
【００７４】
鍵管理サービス３１４は、アプリケーション３１６を使用するユーザまたは銀行アカウントなどのユーザアカウントの認証のためには使用されないことに留意されたい。サードパーティプロバイダサービス１０４に記憶されたユーザの個人情報へのアクセスのためのユーザ認証および検証は、ユーザとサードパーティプロバイダサービス１０４との間の通信の責任である。システム１００は、ユーザの検証を、サードパーティプロバイダサービスにより提供されるトークンまたは他のセキュリティ識別などを介して、システム１００の外側で発生する認証／検証の一環として含み得る。
【００７５】
システム１００、より具体的には鍵管理サービス３１４は、開発者と開発者のアプリケーション１３６により使用される外部ＡＰＩ２１２のための開発者のアプリケーションとに代わって、鍵の実装および管理を提供する。このようにして、アプリケーション１３６が開発者サービスポータル１０８を使用してサードパーティプロバイダサービス１０４の外部ＡＰＩ２１２に新たに関連付けられるときはいつでも、図５に例示する動作が発生し得る。新しいサードパーティＡＰＩ鍵（サブ鍵）が自動的にセットアップされ、サードパーティＡＰＩ２１２のために開発者のアプリケーション１３６に関連付けられた後、鍵管理サービス３１４は、アプリケーションからそのサードパーティＡＰＩに渡される全ての要求に関して、その鍵を自動的に使用し得る。
【００７６】
図４を再び参照すると、サービス種類表示が鍵管理サービス３１４（４４０）として識別されるとき、鍵管理サービス３１４は、外部ＡＰＩがＡＰＩゲートウェイプラットフォーム１１０によりコールされるためにサードパーティ鍵が必要とされるかどうかを判定し得る。（４４２）ＡＰＩ鍵がプロキシサービスのために必要とされる場合、鍵管理サービス３１８は、ＡＰＩ鍵記憶装置にアクセスして、アプリケーションおよびアプリケーションの開発者に関連付けられたサブ鍵を識別および取り出し得る。（４４４）鍵管理サービス３１８は、サブ鍵をＡＰＩゲートウェイプラットフォーム１１０からのＡＰＩサービスコールメッセージ内に注入し得る。（４４６）
【００７７】
鍵管理サービス３１４は、ＡＰＩサービスコールメッセージのＵＲＬプロトコルをＡＰＩゲートウェイプラットフォーム１１０から取り出し、外部ＡＰＩ２１２に対してＡＰＩサービスコールを行い得る。（４４８）鍵管理サービス３１４は、サードパーティＡＰＩをコールするためにサードパーティＡＰＩ鍵が必要とされない場合、ＡＰＩサービスコールメッセージのＵＲＬをＡＰＩゲートウェイプラットフォーム１１０から取り出し、サブ鍵の注入なしに直接、外部ＡＰＩ２１２に対してサービスコールを行い得る。鍵管理サービス３１４は、コール元への応答の配信のために、サードパーティプロバイダサービス１０４の外部ＡＰＩ２１２からＡＰＩゲートウェイプラットフォーム１１０への応答をプロキシ送信し得る。（４５０）
【００７８】
構成ルックアップサービス３２４は、異なるサービスにより必要とされる異なる情報が容易に記憶され、取り出され、かつ共有されるための単一のリポジトリをデータストア３２６内に提供し得る。よって、鍵管理サービス３１４によりアクセスされるＡＰＩ鍵記憶装置３１８の記憶装置は、データストア３２６および構成エンティティ３２８、ならびにシステム１００の動作に関係する他の任意の情報内に記憶され得る。記述的かつリッチな文書ベースの（ＪＳＯＮ）構成エンティティなどの、構成エンティティ３２８の使用は、容易な保守および追加も可能にし得る。構成ルックアップサービス３２４は、他のサービスが、構成がどのように構造化または位置付けられているのかについて理解または配慮する必要性を取り除くだけでなく、作成時に異なる種類の構成エンティティの妥当性確認を行う能力を提供し、システム内において構成が必ず依拠され得るようにする。
【００７９】
このシステムは、接続され、ＡＰＩが有効化されている体験を構築しようとするいずれの企業にとってもインパクトがある。顧客は、顧客の行程の全体にわたって接続体験を求めており、多数の異なるサードパーティ組織により提供されるＡＰＩ間をシームレスに切り替えている。現在、こうしたサービスを構築するには相当の複雑性および開発オーバーヘッドが必要とされるが、今や、拡張可能な鍵管理システム１００を使用してこれを無効化することが可能である。
【００８０】
図６は、複数のサービスプロバイダからの応答を集約するアプリケーションにおける、拡張可能な鍵管理システム１００の動作の一例を示す例示的なブロック図である。図６の例では、システム１００は、サードパーティプロバイダサービスの複数の外部ＡＰＩをコールするように構成されたアプリケーション６０２と共に使用される。図６の例では、アプリケーション６０４に関連付けられたサービス１０４のサードパーティプロバイダは、現金自動預け払い機（ＡＴＭ）の位置をアプリケーション６０４に表示する外部ＡＰＩ２１２を提供する。アプリケーション６０２（ＡＴＭロケータ）は、ユーザ指定半径内のＡＴＭの要求に関して、ユーザ入力を受け取り得る。ユーザ入力内に含まれるか、またはユーザ入力の時点で利用可能でありシステムにより使用される他のパラメータとしては、例えば、そこからユーザ要求が行われた位置、時刻、または近くのＡＴＭを見つけ出すことに関連する他の任意の情報が挙げられる。アプリケーション６０２は、ユーザ入力に応答して、パラメータ（複数可）を入力パラメータとして使用してサービス要求を生成し得る。
【００８１】
アプリケーション６０２により生成されたサービス要求は、ＡＰＩゲートウェイ１１０に提供され得、ＡＰＩゲートウェイ１１０は、「ＡＴＭロケータ」ＡＰＩサービスコールをプロキシ送信し、ユーザの本人確認を行い、関連する監視、監査、ログ記録、およびセキュリティを遂行してから、サービス要求を取り扱うコンテキストサービスをコンテキストサービス層３０２から選択し得る。例えば、アプリケーション６０２は、システム１００の使用のための検証および認証として、システムＡＰＩ鍵をＡＰＩゲートウェイ１１０に渡し得る。システムＡＰＩ鍵は、アプリケーション６０２の開発者に一意的に割り当てられた開発者ＡＰＩ鍵であり得る。ユーザの本人確認としては、セキュリティ鍵、ＡＰＩ鍵、ログイン資格証明書、または他の任意の認証形態が挙げられる。
【００８２】
ＡＰＩゲートウェイ１１０は、サービスコンテキスト層３０２から第１のコンテキストサービス３２０Ａなどのコンテキストサービスを選択して、ＡＰＩゲートウェイ１１０から提供される情報を処理し得る。第１のコンテキストサービス３２０Ａは、分析に基づいて、複数の記憶された構成エンティティのうちの１つの識別子、複数のパラメータ、ならびに集約サービス種類、選択サービス種類、および／または鍵管理サービス種類などのサービス種類表示を、コア能力サービス層３０４に提供し得る。アプリケーション６０２からのサービス要求が第１のコンテキストサービス３２０Ａにより複数の外部ＡＰＩ２１２をターゲットとするとして判定されたので、この例では、コンテキストサービス３２０Ａは、集約サービス種類を選んだ。
【００８３】
この例では、サービス種類表示が集約サービス３１０であるので、第１のコンテキストサービス３２０Ａは、第１のコア能力サービス３０８Ａをコールし得る。集約サービス３１０は、構成ルックアップサービス３２４を使用して、第１のコンテキストサービス３２０Ａにより識別された記憶された構成エンティティ３２８を抽出し得る。この例では、識別子は、構成エンティティへの言及、すなわち「ＡＴＭロケータ構成」である。集約サービス３１０は、それぞれの識別された複数のサードパーティプロバイダサービス１０４の各々に対するサービスコールメッセージの並列データ送信のためにそれぞれの適切なメッセージフォーマットを設定するように、「ＡＴＭロケータ構成」を使用して、その他の点では汎用の第１のコア能力サービス３０８Ａを動的に適合させ得る。追加的に、集約サービス３１０は、それぞれのＡＰＩサービスコールメッセージを、それぞれの所定のフォーマットで、「ＡＴＭロケータ構成」内にリストされた複数の銀行ＡＰＩ６０４の各々に通信する。サービスコールメッセージは、サードパーティプロバイダサービス１０４の各々のそれぞれの外部銀行ＡＰＩ６０４に、それぞれの適切なメッセージフォーマットで送信され得る。適切なメッセージフォーマットは、サードパーティプロバイダサービスの各々のそれぞれの外部ＡＰＩ６０４と互換性を有する。
【００８４】
集約サービス３１０は、銀行ＡＰＩ６０４の各々から応答を受信し、「ＡＴＭロケータ構成」内で指定されたデータを抽出し得る。第１のコンテキストサービス３２０Ａは、コール元の開発者アプリケーションによりＡＰＩゲートウェイ１１０に提供された要求パラメータに従って、応答データを所定の形式にソート、フィルタ処理、および／またはフォーマットし得る。追加的に、サードパーティプロバイダサービス１０４の各々の外部銀行ＡＰＩ６０４の各々からの応答は、「ＡＴＭロケータ構成」から抽出された構成値に従って集約サービス３１０により集約され得る。所定の形式の最終的な集約応答データは、ＡＰＩゲートウェイ１１０を介して開発者アプリケーション６０２に提供され得る。
【００８５】
図７は、ユーザが特定の一サービスプロバイダをターゲットとする支払取引をアプリケーションを介して開始するアプリケーションにおける、拡張可能な鍵管理システムの動作の一例である。図７の例では、ユーザは、ユーザの銀行口座からの支払いの形で金融取引を開始するためにアプリケーション７０２を使用している。他の例では、他の種類の種類の取引が、拡張可能な鍵管理システムを使用するアプリケーションを介してユーザにより開始され得る。
【００８６】
認可ユーザから指図されているアプリケーション７０２は、ユーザから、銀行アカウントなどのユーザの顧客アカウントから支払いを行うためのユーザ入力要求を受信し得る。ＡＰＩゲートウェイ１１０は、サービス要求をアプリケーション７０２から受信する。要求内に含まれるパラメータとしては、ユーザの識別情報、消費者アカウントの識別情報、そこからの支払いが要求されている銀行もしくは他の金融機関の識別情報、要求された支払日、ならびに／または支払要求に関係する他の任意の情報が挙げられる。
【００８７】
ＡＰＩゲートウェイ１１０は、「支払開始」ＡＰＩサービスコールをＡＰＩプロキシによりプロキシ送信し、ユーザの本人確認を行い、関係する監視、監査、ログ記録、およびセキュリティを遂行してから、要求を取り扱うコンテキストサービス３２０をサービスコンテキスト層３０２から選択し得る。このような本人確認としては、セキュリティ鍵、ＡＰＩ鍵、ログイン資格証明書、または他の任意の認証形態が挙げられる。例えば、アプリケーション７０２は、システム１００の使用のための検証および認証として、システムＡＰＩ鍵をＡＰＩゲートウェイ１１０に渡し得る。
【００８８】
サービス要求は、この例では、サードパーティプロバイダサービスにより提供される複数の類似のサービスのうちの単一のサードパーティプロバイダサービスの単一の外部ＡＰＩをターゲットとしているので、第３のコンテキストサービス３２０Ｃなどの選択されたコンテキストサービス３２０は、複数の記憶された構成エンティティのうちの１つの識別子、複数のパラメータ、および選択サービス種類のサービス種類表示を、コアサービス層３０４内のコア能力サービス３０８Ａ〜Ｄに提供し得る。追加的に、コンテキストサービス３２０Ｃは、１つ以上のパラメータとして、そこから支払いが開始されているサードパーティプロバイダサービスを、ターゲットにすべき正しいサードパーティプロバイダサービスを決定するために使用され得るサービス要求により指定し得る。
【００８９】
コア能力サービス３０４は、選択サービス３１２をコールし得る。選択サービス３１２は、構成ルックアップサービス３２４を使用して、記憶された構成エンティティ３２８を抽出し得る。この例では、識別子は、記憶された構成データファイルの名称、すなわち「支払開始構成」データファイルである。選択サービス３１２は、データ送信のために適切なメッセージフォーマットを設定するように、記憶された「支払開始構成」エンティティを使用して、その他の点では汎用の選択サービス３１２を動的に適合させ得る。追加的に、選択サービス３１２は、サービスコールメッセージを適切なメッセージフォーマットで識別された単一のサードパーティプロバイダサービス１０４の外部ＡＰＩ７０４に送信し得る。「支払開始構成」として識別された記憶された構成エンティティを使用した選択サービス３１２の動的適合のため、適切なメッセージフォーマットは、識別された単一のサードパーティプロバイダ１０４の外部ＡＰＩ７０４と互換性を有することになる。外部ＡＰＩ７０４は、複数の利用可能な銀行ＡＰＩ６０４の中から、サービス要求内に含まれるパラメータに基づいて選ばれ得る。
【００９０】
選択サービス３１２は、外部ＡＰＩ７０４から応答を受信し、記憶された「支払開始構成」データファイル内の指定されたデータを抽出し得る。第３のコンテキストサービス３２０Ｃは、ＡＰＩゲートウェイ１１０により提供された要求パラメータに従って、応答データを所定の形式にソート、フィルタ処理、および／またはフォーマットし得る。所定の形式のデータは、ＡＰＩゲートウェイ１１０を介してアプリケーション７０２に提供される。
【００９１】
図８は、鍵管理サービスがサードパーティ通信サービスにアクセスするアプリケーションにおける、拡張可能な鍵管理システムの動作の一例である。鍵管理サービスは、アプリケーションが、集約サービス３１０または選択サービス３１２のいずれかを開始するであろうサービス要求メッセージを提供するのではなくて、ＡＰＩゲートウェイ１１０がアプリケーション８０２によりＡＰＩサービスコールメッセージを提供されるとき、システムにより開始され得る。アプリケーションは、コールが差し向けられる特定の外部ＡＰＩをすでに知っており、特定の外部ＡＰＩをＡＰＩサービスコールメッセージにより識別しているので、鍵管理サービスは、システム内で開始され得る。しかしながら、外部ＡＰＩがＡＰＩサービスコールメッセージに応答するためにＡＰＩ鍵を必要とする場合、ユーザがターゲット外部ＡＰＩの適切なＡＰＩ鍵を管理および適用するように強制されることを防止するために、鍵管理サービス３１８を使用して、適切なサブ鍵を供給し得る。適切なＡＰＩ鍵がＡＰＩサービスコールメッセージ内に含まれていなければ、外部ＡＰＩは、応答しないことになる。
【００９２】
図８の例では、記載の例示的な通信サービスは、サードパーティプロバイダサービス１０４により提供される外部ＡＰＩを介したＳＭＳサービスの動作である。この例では、サードパーティプロバイダサービスは、複数の利用可能なサービス８０６のうちの１つとしてＴｗｉｌｌｉｏ外部ＡＰＩ８０４を提供するＴｗｉｌｌｉｏである。またこの例では、二要素認証チャレンジの第２のものに対するＳＭＳテキスト応答が望ましく、ユーザは、アプリケーション８０２を介して、二要素認証の一環としてＴｗｉｌｌｉｏ  ＡＰＩを介してＳＭＳの発行を要求する要求メッセージを提供している。他の例では、他の種類の通信サービスが、によるアプリケーション／ユーザにより開始され得る。
【００９３】
認可ユーザから指図されているアプリケーション８０２は、ユーザ入力として、ユーザから要求を受信し得る。ＡＰＩゲートウェイ１１０は、サービスコールメッセージをアプリケーションから受信し得る。サービスコールメッセージに含まれるパラメータとしては、開発者ＡＰＩ鍵、外部ＡＰＩ８０４のＵＲＬ、ならびにサービスコールの一環として渡されている他の変形およびパラメータ値が挙げられる。この例では、パラメータとしては、ＳＭＳテキストが差し向けられるべきＳＭＳプロバイダの識別情報（外部ＡＰＩ８０４のＵＲＬの代わりに、またはそれに加えて）、および第２の要素認証のための情報が挙げられる。
【００９４】
ＡＰＩゲートウェイ１１０において、「Ｔｗｉｌｌｉｏ」プロキシが、ユーザ入力に従ってアプリケーション８０２によりコールされる。アプリケーション８０２は、システムＡＰＩ鍵または開発者ＡＰＩ鍵も、サービスコールメッセージの一環としてＡＰＩゲートウェイ１１０に渡し得る。アプリケーション８０２はＡＰＩ鍵を必要とする特定の外部ＡＰＩのためのものであるので、第４のコンテキストサービス３２０Ｄなどの選択されたコンテキストサービス３２０は、コアサービス層３０４内のコア能力サービスのうちの１つに対して、アプリケーション８０２の鍵管理の詳細のＡＰＩ鍵記憶装置３１８内における記憶位置の識別子またはインジケータと、複数のパラメータと、選択サービス種類および鍵管理サービス種類のサービス種類表示とを提供し得る。
【００９５】
コアサービス層３０４内のコア能力サービス３０８のうちの１つ以上、例えば、第２のコア能力サービス３０８Ｂは、特定のアプリケーションのための選択サービスとして働くように構成エンティティにより適合され得、第３のコア能力サービス３０８Ｃは、特定のアプリケーションのための鍵管理サービスとして働くように適合され得る。他の例では、コア能力サービス３０８Ｃなどのコア能力サービスのうちの１つは、選択サービス３１２と鍵管理サービス３１４との両方などの、複数のサービスの機能を提供し得る。鍵管理サービスは、アプリケーション８０２の鍵管理の詳細の記憶位置の識別子またはインジケータに基づいてデータストアにアクセスするように、構成ルックアップサービス３２４をコールし得る。データストア内に記憶され得るＡＰＩ鍵記憶装置内に、鍵管理の詳細は存在する。鍵管理の詳細は、サブ鍵を含み得る。サブ鍵は、アプリケーション８０２および外部ＡＰＩ（Ｔｗｉｌｌｉｏ  ＡＰＩ）８０４に関連付けられた状態で記憶され得る。サブ鍵は、Ｔｗｉｌｌｉｏ  ＡＰＩのためのＡＰＩプロキシが開発者によりアプリケーション８０２に新たに関連付けられたとき、開発者に代わってシステム１００によりサードパーティプロバイダサービスから自動的に取得された。（図５および関連する議論を参照されたい）この例では選択サービス３１２である第２のコア能力サービス３０８Ｂは、ＡＰＩサービスコールメッセージのＵＲＬを、アプリケーション８０２から提供されたパラメータから識別し得る。鍵管理サービス３１４は、サブ鍵とアプリケーション８０２との間の記憶された関連付けに基づいてサブ鍵を取り出し得る。次いで、鍵管理サービス３１４は、サービス要求内でアプリケーションにより提供される開発者ＡＰＩ鍵を置き換えることにより、ＡＰＩサービスコールメッセージ内にサブ鍵を動的に注入し得る。次いで、選択サービス３１２は、ＡＰＩサービスコールメッセージを注入されたサブ鍵と共に、この例ではＴｗｉｌｌｉｏ  ＡＰＩ８０４であるサードパーティプロバイダサービス１０４の外部ＡＰＩ８０４にプロキシ送信し得る。
【００９６】
鍵管理サービス３１８により注入されたサブ鍵を含むＡＰＩサービスコールメッセージを受信すると、Ｔｗｉｌｌｉｏ  ＡＰＩ８０４は、ＳＭＳテキストメッセージを生成および送付し得る。ＳＭＳテキストメッセージは、パラメータにより識別されたＳＭＳプロバイダ８０８に差し向けられ、ＡＰＩゲートウェイ１１０により提供されたパラメータの中に含まれる第２の要素認証情報を含み得る。
【００９７】
選択サービス３１２は、応答を外部ＡＰＩ８０４から受信し得る。この例では、Ｔｗｉｌｌｉｏ  外部ＡＰＩ８０４からの応答は、ＳＭＳテキストメッセージが送付されたことのしるしであり得る。データは、応答から抽出され、第３のコンテキストサービス３２０Ｃに渡され得る。第３のコンテキストサービス３２０Ｃは、ＡＰＩゲートウェイ１１０に提供されたパラメータに従って、応答データを所定の形式にソート、フィルタ処理、および／またはフォーマットし得る。所定の形式のデータが、ＳＭＳメッセージが送付されたことを示すために、ＡＰＩゲートウェイ１１０を介してアプリケーション８０２に提供される。
【００９８】
他の例では、アプリケーションプログラミングインターフェース（ＡＰＩ）のための拡張可能な鍵管理システムの他の多くの応用が可能である。
【００９９】
上述の方法、デバイス、処理、回路、およびロジックは、多くの異なる方法で、かつハードウェアとソフトウェアとの多くの異なる組み合わせで実装され得る。例えば、実装の全部または一部は、中央演算処理装置（ＣＰＵ：Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、マイクロコントローラ、もしくはマイクロプロセッサ；または特定用途向け集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、プログラマブル論理デバイス（ＰＬＤ：Ｐｒｏｇｒａｍｍａｂｌｅ  Ｌｏｇｉｃ  Ｄｅｖｉｃｅ）、もしくはフィールドプログラマブルゲートアレイ（ＦＰＧＡ：Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）；またはディスクリートロジック、もしくはアナログ回路コンポーネント、デジタル回路コンポーネント、もしくは両方を含む他の回路コンポーネントを含む回路；またはこれらの任意の組み合わせ、などの命令プロセッサを含む回路であり得る。回路は、相互接続されたディスクリートハードウェアコンポーネントを含み得、または例として、単一の集積回路ダイ上で組み合わされ、複数の集積回路ダイの間で分散され、もしくは共通パッケージ内の複数の集積回路ダイの複数チップモジュール（ＭＣＭ：Ｍｕｌｔｉｐｌｅ  Ｃｈｉｐ  Ｍｏｄｕｌｅ）内に実装され得る。
【０１００】
それゆえに、回路は、実行のために命令を記憶もしくはアクセスし得、またはその機能をハードウェアのみで実装し得る。命令は、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、読み出し専用メモリ（ＲＯＭ：Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、消去可能なプログラマブル読み出し専用メモリ（ＥＰＲＯＭ：Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）などの一時的信号以外の有形記憶媒体内に；またはコンパクトディスク読み出し専用メモリ（ＣＤＲＯＭ：Ｃｏｍｐａｃｔ  Ｄｉｓｃ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ハードディスク装置（ＨＤＤ：Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、もしくは他の磁気もしくは光学ディスクなどの磁気もしくは光学ディスク上に；または別の機械可読媒体内もしくはその上に、記憶され得る。コンピュータプログラム製品などの製品は、記憶媒体と媒体内またはその上に記憶された命令とを含み得、命令は、デバイス内の回路により実行されるとき、デバイスに、上述の、または図面で例示した処理のうちの任意のものを実装させ得る。
【０１０１】
実装は、分散され得る。例えば、回路は、複数のプロセッサおよびメモリなどの、複数のはっきり異なるシステムコンポーネントを含み得、複数の分散処理システムに広がり得る。パラメータ、データベース、および他のデータ構造は、別々に記憶および管理され得、単一のメモリまたはデータベース内に組み込まれ得、多くの異なる方法で論理的および物理的に組織化され得、多くの異なる方法で実装され得る。例示的な実装としては、連結リスト、プログラム変数、ハッシュテーブル、配列、レコード（例えば、データベースレコード）、オブジェクト、文書、および暗黙の記憶機構が挙げられる。命令は、単一のプログラムの部分（例えば、サブルーチンまたは他のコード断片）を形成し得、複数の別々のプログラムを形成し得、複数のメモリおよびプロセッサを横断して分散され得、多くの異なる方法で実装され得る。例示的な実装としては、スタンドアローンのプログラム、およびダイナミックリンクライブラリ（ＤＬＬ：Ｄｙｎａｍｉｃ  Ｌｉｎｋ  Ｌｉｂｒａｒｙ）のような共有ライブラリなどのライブラリの一部として、が挙げられる。ライブラリは、例えば、共有データと、回路により実行されるとき、上述の、または図面に例示した処理のうちのいずれかを遂行する命令を含む１つ以上の共有プログラムと、を含み得る。
【０１０２】
用法を明らかにし、ここに公衆に通知を提供するために、「＜Ａ＞、＜Ｂ＞、Ｉ、および＜Ｎ＞のうちの少なくとも１つ」または「＜Ａ＞、＜Ｂ＞、Ｉ＜Ｎ＞、もしくはこれらの組み合わせのうちの少なくとも１つ」、または「＜Ａ＞、＜Ｂ＞、Ｉ、および／または＜Ｎ＞」という文言は、Ａ、Ｂ、Ｉ、およびＮを含む群から選択される１つ以上の要素を意味するように出願人により最も広い意味で定義され、出願人により明示的に反対の主張がなされない限り上記または下記の任意の他の暗黙の定義に取って代わる。言い換えれば、これらの文言は、任意の１つの要素のみ、またはその１つの要素と他の要素のうちの１つ以上との組み合わせを含み、リストされていない追加の要素も組み合わせの中に含み得る、要素Ａ、Ｂ、Ｉ、またはＮのうちの１つ以上の任意の組み合わせを意味する。追加的に、請求項内で使用するとき、冠詞「ａ」は、「少なくとも１つ」と交換可能であると解釈されるべきである。
【０１０３】
様々な実施形態を説明してきたが、より多くの実施形態および実装が可能であることが当業者には明らかであろう。それゆえに、本明細書に記載の実施形態は、例であり、唯一の可能な実施形態および実装ではない。
【図１】
2018186492.tif 000003
【図２】
2018186492.tif 000004
【図３】
2018186492.tif 000005
【図４】
2018186492.tif 000006
【図５】
2018186492.tif 000007
【図６】
2018186492.tif 000008
【図７】
2018186492.tif 000009
【図８】
2018186492.tif 000010
【外国語明細書】
2018186492000001.pdf
2018186492000002.pdf
2018186492000003.pdf
2018186492000004.pdf