JP2013531295A - オープン・アプリケーション・プログラミング・インターフェースに基づくオンライン・ビジネス法、システム、並びに、装置 - Google Patents

Abstract

本開示は、オープンＡＰＩに基づくオンライン取引を実現する方法、システム、並びに装置を紹介している。一態様における方法は、利用者の取引要求にしたがって、サード・パーティ開発サーバから、オープンＡＰＩを呼び出すための第１呼び出し要求を受信するステップと、上記呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰサーバを判定するステップと、判定されたＩＳＰサーバへ第１呼び出し要求を送信するステップと、第１呼び出し要求にしたがって、ＩＳＰサーバから戻されたサービス・ページを受信するステップと、サービス・ページを処理して、処理済のサービス・ページを利用者に送信するために、サービス・ページをサード・パーティ開発サーバへ送信するステップを含み、サービス・ページの処理には、サービス・ぺージを、取引要求に対応するページに埋め込む処理が含まれる。

Description

関連特許出願の相互参照
本願は、参照によりその全体が本明細書に援用される「オープン・アプリケーション・プログラミング・インターフェースに基づくオンライン・ビジネス法、システム、並びに、装置」と題され、２０１０年６月１０日に出願された中国特許出願第２０１０１０２００８２１．１号の優先権を主張する。

本発明は、ネットワーク通信技術分野に関し、具体的には、オープン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）に基づくネットワーク取引を実現する方法、並びに、そのシステムと装置に関する。

オープンＡＰＩは、サービスとしてのソフトウェア（ＳａａＳ）モデルの下での共通アプリケーション・インターフェースである。インターネット・サービス・プロバイダー（ＩＳＰ）は、利用可能なウェブサイトサービスを一連のＡＰＩとして組み込み、サード・パーティ開発者、例えば、独立系ソフトウェアベンダ（ＩＳＶ）に公開し、ＩＳＶは、ＩＳＶサーバを介して、関連ビジネス・ロジックを使用する。このような手法は、公開型ウェブサイトＡＰＩと呼ばれ、公開されたＡＰＩを、オープンＡＰＩと呼ぶ。

今後ますます、ＩＳＶは、ＩＳＰから提供されるオープンＡＰＩに基づくアプリケーションの開発を目指し、ＩＳＰは、より多くのネットワーク・フロー、及び、市場占有率を受容する。ＩＳＶの場合、業務要件を満たすために、ハードウェア、及び、技術に膨大な投資をする必要がないので、投資コストは減少する。このため、インターネット・オンライン・サービスを開発基盤とするオープンＡＰＩは、より多くのインターネット関連企業にとってサービスを開発する上で有望な選択肢の一つとなり、新たな開発の可能性を備えている。

オープンＡＰＩによるアプリケーションの可能性から、外国、及び、自国のウェブサイトのＩＳＰは、独自のオープンＡＰＩウェブサイトを公開している（すなわち、オープンＡＰＩに基づくオンライン・ビジネスのウェブサイト）。現状、一般的なオープンＡＰＩは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）インターフェースに基づくＲＥＳＴ ＡＰＩである。ＲＥＳＴ ＡＰＩによるオンライン・ビジネスの実行中、ＲＥＳＴサービスは、インターネットを介したＨＴＴＰ ＧＥＴを用いて、業務実行サーバへ送られる。業務実行サーバは、ＰＯＳＴを用いて、ＲＥＳＴサービスに応答する。業務実行サーバは、ＲＥＳＴサービスに応答する結果として、構造データ、例えば、ＸＭＬ，Ｊａｓｏｎ等を用いる。

ＲＥＳＴ ＡＰＩに基づくオンライン・ビジネスを実行するための上記手法には、幾つかの欠点がある。第１の欠点は、応答結果である構造データは、ＩＳＶから読み取られ易いということである。一般的な業務実行サーバから提供される業務データが、利用者以外のサード・パーティ（例えば、ＩＳＶ）によって取得されることは望ましくない。したがって、業務実行サーバの観点から、上記手法によって実行されるオンライン・ビジネスに関するデータのセキュリティは低い。第２の欠点は、現在のオンライン・ビジネスのほとんどに、利用者とサービス・プロバイダー間に複数の対話を必要とする複雑な業務ロジック操作が伴われるということである。従来のオンライン・ビジネス実行法では、ＲＥＳＴ ＡＰＩは、利用者とサービス・プロバイダー間の問い合わせ、データ更新等の対話を一度しか実行できない。複雑なオンライン・ビジネスの場合、ＩＳＶは、完璧なフローを実現するために、複数のＲＥＳＴ ＡＰＩを構築する必要があるが、これには、ＩＳＶが、複数のＡＰＩ呼び出しにビジネス・ロジックを解析することが求められる。これによって、（ＲＥＳＴ ＡＰＩに基づくオンライン・ビジネスの実行）法の使い勝手が悪くなる。種々のＩＳＶの解析能力の違いを併せて考えると、業務の一貫性を保証することが難しくなることは明らかである。この結果、業務実行サーバによる業務の管理能力が、不十分となる。

以上のことから、既存のＡＰＩに基づくオンライン・ビジネスでは、業務データのセキュリティは、保証されず、且つ、業務の管理能力も不十分である。

本開示は、オープンＡＰＩに基づくネットワーク取引を実現する方法を紹介し、更に、この方法によるシステム、並びに、装置も紹介している。従来技術の欠点の一部、例えば、業務データのセキュリティの低さや、業務の不十分な管理能力は、本開示の導入により解消される。

一態様では、オープンＡＰＩに基づくネットワーク取引を実現する方法は、利用者からの取引要求にしたがって、サード・パーティ開発サーバから、オープンＡＰＩを呼び出すための第１呼び出し要求を受信するステップと、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰサーバを判定するステップと、判定されたＩＳＰサーバに第１呼び出し要求を送信するステップと、第１呼び出し要求にしたがって、ＩＳＰサーバから戻されるサービス・ページを受信するステップと、更に、サービス・ページを処理して、処理済のサービス・ページを利用者へと送信するために、サービス・ページをサード・パーティ開発サーバへ送信するステップを含むことが可能であり、サービス・ページの処理には、サービス・ページを取引要求に対応するページに埋め込む処理が含まれる。取引要求は、実装形態によっては、業務要求に関連してもよい。

呼び出しを要求されたオープンＡＰＩが複数のオープンＡＰＩを含む場合、第１呼び出し要求を判定されたＩＳＰサーバに送信する前に、上記方法は、複数のオープンＡＰＩの呼び出し関係を判定するステップと、更に、第１呼び出し要求を判定されたＩＳＰサーバへ送信するステップを含んでもよい。第１呼び出し要求を送信する処理は、呼び出し関係にしたがって、呼び出し順序が、複数のオープンＡＰＩに存在する場合、第１呼び出し要求を、複数のオープンＡＰＩの呼び出し順序の中で先頭にある第１オープンＡＰＩに対応するＩＳＰサーバへ送信するステップと、更に、呼び出し関係に準じた呼び出し順序が、複数のオープンＡＰＩの中に存在しない場合、第１呼び出し要求を、複数のオープンＡＰＩのそれぞれに対応する複数のＩＳＰサーバのそれぞれへ送信するステップを更に含むことができる。

呼び出し関係にしたがって、呼び出し順序が、複数のオープンＡＰＩの中に存在する場合、サービス・ページをサード・パーティ開発サーバへ送信する前に、上記方法は、サービス・ページの中に、複数のオープンＡＰＩの呼び出し順序を埋め込むステップを、更に含んでもよい。

上記方法は、呼び出し順序にしたがって、第１オープンＡＰＩの次に、且つ、サービス・ページの中に埋め込まれた第２オープンＡＰＩを呼び出すための第２呼び出し要求を受信するステップと、第２呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信するステップと、第２呼び出し要求にしたがって、第２オープンＡＰＩに対応するＩＳＰサーバから、サービス・ページを受信するステップと、サード・パーティ開発サーバによってサービス・ページを処理し、処理済のサービス・ページを利用者へ送信するために、サービス・ページをサード・パーティ開発サーバに送信するステップを更に含んでもよい。

第２呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信する前に、上記方法は、複数のオープンＡＰＩの呼び出し関係にしたがって、第２オープンＡＰＩを、第１オープンＡＰＩを介して呼び出す必要があるかどうかを判定するステップと、第２呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信するステップと、第２呼び出し要求に応答して、第２オープンＡＰＩに対応するＩＳＰサーバから、サービス・ページを受信するステップを更に含んでもよい。サービス・ページの受信は、例えば、送信呼び出し要求を、第１オープンＡＰＩに対応するＩＳＰサーバから、第２オープンＡＰＩに対応するＩＳＰサーバへ送信するステップと、第１オープンＡＰＩに対応するＩＳＰサーバから、処理済のサービス・ページを受信するステップによって実現可能であり、サービス・ページは、第２オープンＡＰＩに対応するＩＳＰサーバから、第１オープンＡＰＩに対応するＩＳＰサーバによって受信され、このサービス・ページは、第２オープンＡＰＩに対応するＩＳＰサーバのサービス・ページへと埋め込まれる。

サービス・ページを取引要求に対応するページに埋め込むステップは、サービス・ページを、取引要求に対応するページにＩｆｒａｍｅ（インライン・フレーム）形式で埋め込むステップを含むことができる。

呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰを判定する前に、上記方法は、取引要求を送信する利用者を認証するステップを更に含んでもよい。

取引要求を送信する利用者を認証するステップは、利用者がログインできた際に、利用者ログイン識別情報を作成するステップと、利用者が、それぞれの取引要求を送信する度に、利用者ログイン識別情報が更新される際、この利用者ログイン識別情報が有効であるかどうかを判定するステップを含むことが可能である。

呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応する判定されたＩＳＰサーバが、複数のＩＳＰサーバを含む場合、第１呼び出し要求を、判定されたＩＳＰサーバへと送信するステップは、ランダム・ルート・アルゴリズムを用いて、判定されたＩＳＰサーバの１つを見つけるステップと、第１呼び出し要求を、判定されたＩＳＰサーバのうち見つけたＩＳＰサーバの１つへ送信するステップを含むことができる。

別の態様では、オープンＡＰＩに基づくネットワーク取引を実現する装置は、利用者からの取引要求にしたがって、サード・パーティ開発サーバから送られたオープンＡＰＩを呼び出すための呼び出し要求を受信する第１受信部と、第１受信部によって受信された呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰサーバを判定して、判定されたＩＳＰサーバに呼び出し要求を送信する第１ＩＳＰ呼び出し部と、並びに、第１呼び出し結果フィードバック部であって、第１ＩＳＰ呼び出し部から送られた呼び出し要求にしたがって、ＩＳＰサーバから戻されたサービス・ページを受信して、サービス・ページを処理し、処理済のページを利用者へ送信するために、サービス・ページをサード・パーティ開発サーバへ送信し、サービス・ページの処理は、サービス・ページを取引要求に対応するページに埋め込む処理を含む第１呼び出し結果フィードバック部とを含むことが可能である。

第１ＩＳＰ呼び出し部は、第１受信部が受信した呼び出し要求の中で呼び出し要求されるオープンＡＰＩが、複数のオープンＡＰＩを含む場合、複数のオープンＡＰＩの呼び出し関係を判定する呼び出し関係判定モジュールと、呼び出し関係判定モジュールにより判定された呼び出し関係にしたがって、呼び出し順序が複数のオープンＡＰＩに存在すると判定された場合、複数のオープンＡＰＩの呼び出し順序の先頭にある第１オープンＡＰＩに対応するＩＳＰサーバへ、呼び出し要求を送信する第１呼び出し実行モジュールと、並びに、呼び出し関係判定モジュールにより判定された呼び出し関係にしたがって、呼び出し順序が複数のオープンＡＰＩに存在しないと判定された場合、複数のオープンＡＰＩに個々に対応する複数のＩＳＰサーバへ、呼び出し要求を送信する第２呼び出し実行モジュールを含んでもよい。

上記装置は、呼び出し関係にしたがって、呼び出し順序が複数のオープンＡＰＩ間に存在すると判定された場合、複数のオープンＡＰＩの呼び出し関係をサービス・ページに埋め込み、埋め込み処理されたサービス・ページを、第１呼び出し結果フィードバック部へ提供する呼び出し関係埋め込み部を、更に含む場合もある。

上記装置は、第１オープンＡＰＩの次にあり、且つ、第１呼び出し結果フィードバック部から戻されたサービス・ページに埋め込まれた呼び出し順序にしたがって始動する第２オープンＡＰＩを呼び出すための呼び出し要求を受信する第２受信部と、第２受信部によって受信された呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信する第２ＩＳＰ呼び出し部と、並びに、第２ＩＳＰ呼び出し部にしたがって、呼び出し要求に対応する第２オープンＡＰＩに関連するＩＳＰサーバから戻されたサービス・ページを受信し、これを処理して、処理済のサービス・ページを利用者へ送信するため、サービス・ページをサード・パーティ開発サーバへ送信する第２呼び出し結果フィードバック部を含んでもよい。

第２ＩＳＰ呼び出し部は、第２受信部によって受信された呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバに送信する前に、第２オープンＡＰＩを、複数のオープンＡＰＩ間の呼び出し関係にしたがって、第１オープンＡＰＩを介し、呼び出すべきかどうかを判定する呼び出し関係解析モジュールと、呼び出し関係解析モジュールの解析結果が第２オープンＡＰＩを呼び出す必要があると判定した場合、呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信する呼び出し要求送信モジュールを含んでもよい。第２呼び出し結果フィードバック部は、第１オープンＡＰＩに対応するＩＳＰサーバによって戻される処理済のサービス・ページを受信する受信モジュールを含むことができる。このサービス・ページは、第２オープンＡＰＩに対応するＩＳＰサーバによって戻されて、第１オープンＡＰＩに対応するＩＳＰサーバにより受信され、第１オープンＡＰＩから供給されるサービス・ページに埋め込まれるサービス・ページである。更に、第２呼び出し結果フィードバック部は、サービス・ページを処理し、処理済みのページを利用者に送信するため、受信モジュールが受信したサービス・ページをサード・パーティ開発サーバへ送信するフィードバック・モジュールも含んでもよい。

上記装置は、取引要求を送信する利用者を認証して、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰを判定することを、第１ＩＳＰ呼び出し部に命令する認証部を、更に含むこともある。

上記認証部は、利用者が設定条件を満たす場合、利用者認証を判定する認証モジュールと、並びに、利用者が承認されたということが認証モジュールにより判定された場合、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰを判定することを、第１ＩＳＰ呼び出し部に命令する命令モジュールを含むことが可能である。設定条件には、利用者がログインに成功した場合の利用者ログイン証明を作成するステップと、利用者ログイン証明が有効であるかどうかを判定するステップを含んでもよい。利用者ログイン証明は、利用者から取引要求が送信される度に更新できる。

第１ＩＳＰ呼び出し部は、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰの数を判定するＩＳＰサーバ判定モジュールと、並びに、ＩＳＰサーバ判定モジュールにより判定されたＩＳＰが複数のＩＳＰを含む場合、ランダム・ルート・アルゴリズムを用いて、複数のＩＳＰサーバから１つを見つけ、呼び出し要求を見つけたＩＳＰサーバに送信するＩＳＰサーバ選択モジュールを含んでもよい。

別の態様ではさらに、オープンＡＰＩに基づくネットワーク取引を実現するシステムは、サード・パーティ開発サーバと、取引実行サーバと、並びに、ＩＳＰサーバとを含むことができる。サード・パーティ開発サーバは、利用者からの取引要求にしたがって、オープンＡＰＩの呼び出し要求を、取引実行サーバへ送信して、取引実行サーバから戻されたサービス・ページを受信し、更に、サービス・ページを、取引要求に対応するページに埋め込んでから、利用者へ送信できる。取引実行サーバは、呼び出し要求に応答して、呼び出し要求内で要求されるオープンＡＰＩに対応するＩＳＰサーバを判定して、判定されたサーバに呼び出し要求を送信し、ＩＳＰサーバから戻されたサービス・ページを受信し、更に、サービス・ページをサード・パーティ開発サーバへ送信することが可能である。ＩＳＰサーバは、取引実行サーバから送られた呼び出し要求にしたがって、対応するサービス・ページを取引実行サーバへ戻すことができる。

本開示によれば、データ・セキュリティの観点から、サービス・ページを介して、サービス・データをサード・パーティ開発サーバへ送るほうが、従来方式のように構造形式データをサード・パーティ開発サーバへ直接戻すより安全である。更に、サード・パーティ（開発）サーバとＩＳＰ間のサーバによって、業務全体の管理機能が実装されるため、サード・パーティ開発サーバは、業務ロジックを解析する必要がなく、結果として、管理能力が向上する。

本開示の実施形態に係るオープンＡＰＩに基づくオンライン・ビジネスを実現する方法の流れ図１である。 本開示の実施形態に係る呼び出し要求をＩＳＰサーバに送信するプロセスの流れ図である。 本開示の実施形態に係る次オープンＡＰＩを始動する呼び出しプロセスの流れ図１である。 本開示の実施形態に係る次オープンＡＰＩを始動する呼び出しプロセスの流れ図２である。 本開示の実施形態に係るオンライン・ビジネスを実現するシステムの相互作用を示す図である。 本開示の実施形態に係るオープンＡＰＩに基づくオンライン・ビジネスを実現する方法の流れ図２である。 本開示の実施形態に係る認証するために認証コンポーネントを用いる流れ図である。 本開示の実施形態に係るオープンＡＰＩに基づくオンライン・ビジネスを実現するシステムの図である。 本開示の実施形態に係るオープンＡＰＩに基づくオンライン・ビジネスを実現する装置１の図である。 本開示の実施形態に係る第１ＩＳＰ呼び出し部の構造１の図である。 本開示の実施形態に係るオープンＡＰＩに基づくオンライン・ビジネスを実現する装置２の図である。 本開示の実施形態に係るオープンＡＰＩに基づくオンライン・ビジネスを実現する装置３の図である。 本開示の実施形態に係る第２ＩＳＰ呼び出し部、及び、第２呼び出し結果フィードバック部の構造の図である。 本開示の実施形態に係るオープンＡＰＩに基づくオンライン・ビジネスを実現する装置４の図である。 本開示の実施形態に係る認証部の構造の図である。 本開示の実施形態に係る第１ＩＳＰ呼び出し部の構造２の図である。

業務のデータ・セキュリティと管理能力の双方を高める手法を提供するため、本開示では、オープンＡＰＩに基づくオンライン・ビジネスの実行法、システム、並びに、装置を提供している。以下で説明する技術は、方法、または、装置の形態でオンライン取引を実現するのに使用できる。この取引は、本来、オンライン電子商取引で使用されるような業務取引である。好ましい実施形態を、本開示の範囲を制限せずに説明をする目的で図面を参照することで、以下に説明する。

図１は、本開示の実施形態に係るオープンＡＰＩに基づくオンライン・ビジネスを実現する方法を説明している。この方法は、以下の複数のステージを含む。

ステージ１０１：取引実行サーバが、サード・パーティ開発サーバから、オープンＡＰＩの呼び出し要求を受信する。この要求は、利用者の取引要求に基づいて送られる。前述のように、実装形態によっては、取引要求は、電子商取引で使用されるような業務取引のための業務要求と関連しており、取引実行サーバは、業務実行サーバと考えることもできる。

ステージ１０２：業務実行サーバは、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰを判定し、判定されたＩＳＰサーバへ呼び出し要求を送信する。

ステージ１０３：業務実行サーバは、呼び出し要求にしたがって、ＩＳＰサーバから戻されるサービス・ページを受信する。

ステージ１０４：業務実行サーバは、サービス・ページをサード・パーティ開発サーバへ送信して、サード・パーティ開発サーバは、サービス・ページを処理し、利用者に送る。

ステージ１０４：サード・パーティ開発サーバは、サービス・ページを業務要求に対応するページに埋め込むことにより、サービス・ページを処理する。

前述のオンライン・ビジネスの実装方法は、業務実行サーバが対応するネットワーク環境に導入されたサーバとなることが可能な種々のネットワーク環境に適用でき、更に、ネットワーク環境に実現される業務を制御、及び、管理するのに使用できる。サード・パーティ開発サーバは、ＩＳＶサーバである。

ある実施形態では、呼び出し要求の中で呼び出し要求されるオープンＡＰＩが、複数のオープンを含む場合、呼び出し要求を判定されたＩＳＰサーバへ送る前、すなわち、ステージ１０２よりも前に、更に、複数のオープンＡＰＩの呼び出し関係を判定することもできる。

複数のオープンＡＰＩ間の呼び出し関係は、呼び出し順序が、複数のオープンＡＰＩに存在するかどうかを示している。ある実施形態によれば、複数のオープンＡＰＩは、呼び出し順序を持つオープンＡＰＩを含むことができ、更に、他のオープンＡＰＩと呼び出し順序を共有し合う独立したオープンＡＰＩを含むことも可能である。

複数のオープンＡＰＩの呼び出し関係を判定した後、図１で示したプロセスのステージ１０２では、呼び出し要求を、判定したＩＳＰサーバへ送信し、図２に示すように、以下に述べる複数のステージを含む。

ステージ２０１：複数のオープンＡＰＩに存在する呼び出し関係にしたがって、呼び出し順序が、複数のオープンＡＰＩに存在するかどうかを判定する。呼び出し順序が存在すれば、このプロセスは、ステージ２０２へ進み、呼び出し順序が存在しなければ、ステージ２０３へ進む。

ステージ２０２：呼び出し要求を、複数のオープンＡＰＩの呼び出し順序の先頭にある第１オープンＡＰＩに対応するＩＳＰサーバへ送信し、図１のステージ１０３へ進む。

ステージ２０３：呼び出し要求を、複数のオープンＡＰＩのそれぞれに対応する複数のＩＳＰサーバのそれぞれに送信し、図１のステージ１０３へ進む。

一実施形態によれば、呼び出し要求の中で呼び出し要求されるオープンＡＰＩが、複数のオープンＡＰＩを含み、且つ、複数のオープンＡＰＩに呼び出し順序が存在する場合、呼び出し順序の最後のオープンＡＰＩが呼び出されるまで、業務ロジックにしたがって、複数の呼び出しを実行する。呼び出し順序に基づく第１呼び出しの実行後、及び、サービス・ページのサード・パーティ開発サーバへ送信する前、すなわち、図１のステージ１０４の前に、このプロセスは、さらに複数のオープンＡＰＩの呼び出し順序を、サービス・ページに埋め込むことができる。

上記のステージを実行することによって、オープンＡＰＩの呼び出し順序は、利用者に戻されるサービス・ページに埋め込まれる。利用者は、次のオープンＡＰＩ呼び出しフロー、つまり、以下の説明および図３に示すように、複数のステージを含むプロセスを始動できる。

ステージ３０１：業務実行サーバは、サービス・ページに埋め込まれた呼び出し順序にしたがって、利用者により始動され、第１オープンＡＰＩの次の第２オープンＡＰＩの呼び出し要求を受信する。

ステージ３０２：呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信する。

ステージ３０３：呼び出し要求にしたがって、第２オープンＡＰＩに対応するＩＳＰサーバから戻されたサービス・ページを受信する。

ステップ３０４：サービス・ページをサード・パーティ開発サーバへ送り、サービス・ページを処理して、利用者へ送信する。

図３で示したプロセスによれば、業務実行サーバは、利用者により始動された次オープンＡＰＩ呼び出し要求にしたがって、呼び出し要求のための呼び出しプロセスを実行する。ある実施形態によれば、利用者が次のオープンＡＰＩの呼び出しプロセスを始動した後、種々のオープンＡＰＩに対応するＩＳＰサーバ間の相互呼び出しに対応できる。例えば、複数のＩＳＰサーバの相互作用を伴う複雑な業務では、第１オープンＡＰＩに対応するＩＳＰサーバから提供される業務を呼び出した後、第２オープンＡＰＩに対応するＩＳＰサーバから提供される業務も、呼び出す必要となる場合がある。しかし、第２オープンＡＰＩに対応するＩＳＰサーバは、特定のＩＳＰサーバからのアクセスにしか対応できないことがある。一般に、このＩＳＰサーバは、初めて呼び出されるオープンＡＰＩに対応するＩＳＰサーバである。このような状況下では、第２オープンＡＰＩに対応するＩＳＰサーバから提供される業務を取得するため、第２オープンＡＰＩに対応するＩＳＰサーバは、第１オープンＡＰＩに対応するＩＳＰサーバを介して、呼び出す必要がある。とりわけ、業務実行サーバは、利用者が始動する次のオープンＡＰＩの呼び出し要求にしたがって、図４に示される呼び出し要求の呼び出しプロセスを実行する。

ステップ４０１：業務実行サーバは、サービス・ページに埋め込まれた呼び出し順序にしたがって利用者により始動される第１オープンＡＰＩの次の第２オープンＡＰＩの呼び出し要求を受信する。

ステージ４０２：複数のオープンＡＰＩの呼び出し関係にしたがって、第２オープンＡＰＩを、第１オープンＡＰＩによって呼び出す必要があるかどうかを判定する。第２オープンＡＰＩを、第１オープンＡＰＩを介して呼び出す必要がある場合、このプロセスは、ステージ４０３‐４０４へ進み、第２オープンＡＰＩを呼び出す必要がなければ、ステージ４０５‐４０６へ進む。

ステージ４０２：第１オープンＡＰＩと第２オープンＡＰＩの間で、相互呼び出し関係が存在する場合、第２オープンＡＰＩの呼び出しは、第１呼び出しオープンＡＰＩを介して実行する必要がある。

ステージ４０３：第１オープンＡＰＩに対応するＩＳＰサーバを介して、呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信する。

ステージ４０４：第１オープンＡＰＩに対応するＩＳＰサーバから戻された処理済サービス・ページを受信して、ステージ４０７へ進む。

ステージ４０４：第１オープンＡＰＩに対応するＩＳＰサーバは、第２オープンＡＰＩに対応するＩＳＰサーバから戻されるサービス・ページを受信して、受信したサービス・ページを、このＩＳＰサーバのサービス・ページに埋め込む。

ステージ４０５：呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信する。

ステージ４０６：呼び出し要求にしたがって、第２オープンＡＰＩに対応するＩＳＰサーバから戻されたサービス・ページを受信して、ステージ４０７へ進む。

ステージ４０７：サービス・ページをサード・パーティ開発サーバへ送信して、サービス・ページを処理し、利用者へ送る。

一実施形態によれば、ＩＳＰから戻されたサービス・ページの業務要求に対応するページに埋め込むことは、サービス・ページを業務要求に対応するページにＩｆｒａｍｅ（インナー・フレーム）形式で埋め込む処理を含むことができる。

Ｉｆｒａｍｅ形式で埋め込まれたページは、Ｉｆｒａｍｅ要素であり、これは、ページ内のフローティング・フレームであると認識できる。１組のフレームは、Ｉｆｒａｍｅのコンテンツへのアクセス権限を提供する。実際の実装では、フレームの組を用いて、Ｉｆｒａｍｅ内に含まれる要素を読み書きできる。

Ｉｆｒａｍｅは、インナー・フレームとしても知られ、ウェブ・ページを既存のウェブ・ページに埋め込む手法である。埋め込まれたウェブ・ページは、既存ウェブ・ページの指定フレーム位置内に表示される。だが、利用者には、表示されているウェブ・ページが、異なる２つのウェブ・ページからのものであるとことが分かってはならない。本開示の実施形態では、Ｉｆｒａｍｅの特徴を用いて、ＩＳＰサービスのウェブ・ページを開き、セキュリティ、及び、ユーザ・エクスペリエンスの質を確保している。

本開示の実施形態によれば、業務実行のセキュリティ、及び、管理機能を向上させるため、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰを判定する前、すなわち、図１に示したプロセスのステージ１０２より前に、このプロセスでは更に、業務要求を送信する利用者を認証して、利用者が認証を通った後に、ステージ１０２を実行することができる。

具体的には、業務要求を送信する利用者の認証は、種々の方法、例えば、ログイン・インターフェースを利用者へ返し、利用者が登録利用者であれば、ログイン・インターフェースを介して、登録済のアカウント、及び、パスワードを送信するよう利用者に要求し、一方、利用者が登録済利用者でなければ、まずログイン・インターフェースを介して登録するよう利用者に要求し、登録情報が確認されたら、利用者のログインを許可することにより実行できる。

実際の業務実行の場合、一般に、利用者とネットワーク・サーバの間に複数の相互作用が伴う。利用者のログインの妥当性を保証するため、本開示の実施形態によれば、利用者のログインの成功後、このプロセスでは、利用者が業務要求を送信する度に更新される利用者のログイン証明を検証することが可能である。ログイン証明が有効であれば、利用者は認証を通過し、無効であれば、利用者の業務要求は拒否される。利用者のログイン証明は、利用者のログインの成功後に作成される。実際の業務実行では、利用者ログイン証明の作成と更新は、以下の通りに実行可能である。

一部の実施形態では、業務実行は、一般にブラウザーで送ることができる。業務実行サーバは、利用者ログインを検証した後、ログインのプロセス中に生成される利用者のログイン証明のクッキーを、クッキーの時間情報と併せて、ブラウザーに書き込む。この利用者が、再度アクセスする際（例えば、オープンＡＰＩの呼び出し）、クッキーの有効性の検証中に、利用者識別情報の有無の検証の他、現在のアクセスとクッキーがブラウザーに書き込まれた最後の時間間隔が所定の時間間隔内にあるかどうかも検証される。すなわち、業務実行サーバは、オープンＡＰＩが呼び出される度に、クッキーを検証し、更新できる。利用者が、長時間オープンＡＰＩを呼び出さない場合、次回、利用者は、業務のセキュリティを向上させるため、再度ログインする必要があるだろう。

本開示の実施形態によれば、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応する判定されたＩＳＰサーバが、複数のＩＳＰサーバを含む場合、呼び出し要求を判定された１つ以上のＩＳＰサーバへ送る。この呼び出し要求の送信には、判定された複数のＩＳＰサーバのうち任意の１つの呼び出し要求の送信を含むことができる。

判定された複数のＩＳＰサーバの任意の一つに呼び出し要求を送信することは、ランダム・ルート・アルゴリズムによって実装できることが望ましい。すなわち、呼び出し要求は、ランダム・ルート・アルゴリズムにしたがって、判定された複数のＩＳＰサーバの任意の一つのＩＳＰサーバへ送られる。その間、ＩＳＰサーバの「ハートビート」試験が可能であり、ＩＳＰのランダム・リストは、ＩＳＰの状態にしたがって、動的に更新される。例えば、ＩＳＰの試験結果が、ＩＳＰの異常状態を示していれば、このＩＳＰはランダム・リストから削除されて、次回の呼び出し要求には、そのサーバに送られることはない。ＩＳＰの試験結果が、ＩＳＰの正常状態を示していれば、ＩＳＰはランダム・リストに再度追加され、次回の呼び出し要求には、その対応サーバへ送信される場合がある。

ある実施形態では、業務を提供するＩＳＰは、ＨＴＴＰソフト・ロードを介して、複数のＩＳＰサーバから特定できる。

ＨＴＴＰソフト・ロードは、ミドルウェア構成サーバ（すなわち、業務実行サーバ）に基づいて実装できる。ＩＳＰサーバはそれぞれ、ＨＴＴＰサービスを構成サーバに登録する。構成サーバのクライアント側は、ＩＳＰサーバに無作為に接続して、構成サーバの登録アドレスに基いて、ＨＴＴＰ要求を送信する。各ＩＳＰサービスは、サーバ側ターゲットを介して、アドレス情報を構成サーバに公開し、各クライアント側は、クライアント側ターゲットを介して、構成サーバの必要サービスに加入する。構成サーバは、新規で利用可能な全てのサービスのリストをクライアント側へ送って、クライアント側は、ルート・アルゴリズム（恐らく、ランダム・ルート・アルゴリズム）を介して呼び出すためのサービス・アドレスを一つ選択する。とりわけ、構成サーバへ送られるアドレス・リストは、文字列で表示可能である。

本開示の実施形態によれば、ＩＳＰサーバから戻されるサービス・ページには、場合によっては以下に述べる２つの形式がある。

形式１：ＩＳＰサーバが、サービス・ページを戻して、ＩＳＶはＩＳＰから戻されたサービス・ページを自身のサービス・ページに埋め込む。利用者に戻される最終結果のページは、ＩＳＰアプリケーション、つまり、開発者によって開発されたソフトウェアに対応するドメイン名に表示される。すなわち、利用者にＩＳＰアプリケーションのドメイン名であることがわかるように、ＩＳＰアプリケーションのドメイン名は利用者に戻される結果のページに埋め込まれる。

形式２：ＩＳＰサーバは、取得したページの先頭と末尾間のリンクに応じて、サービス・ページを表示し、サービス・ページは細部を整えられ、業務実行サーバに戻す。利用者に戻される最終結果のページは、業務実行サーバに対応するドメイン名として表示される。ページの先頭と末尾間のリンクは、ＡＰＩの呼び出しによってＩＳＶのアプリケーションが入力したパラメータ情報であり、サービス・ページの細部を整えることには、このパラメータ情報に基づく完成したページを作成することを含む。

本開示の実施形態によれば、本開示は、種々の業務要件を満たすことができる。例えば、処理を進める業務プロセスの順序で、業務実行サーバのドメイン名を利用者に表示することが求められる業務要件がある。説明の例として、返済業務の場合、利用者はパスワードを入力するよう求められる。セキュリティの抜け穴及びこれに起因する問題を低減するよう、利用者がパスワードを入力するウィンドーは、業務実行サーバのドメイン名に対応するページの下に表示する必要がある。利用者は、パスワードが第３者によって盗難されないよう、ドメイン名が正規なものであることを確認した後に、パスワードを入力する。

本開示の実施形態から提供される技術をより理解できるよう、実施形態の詳細について業務実行を制御する業務実行サーバの特定例と併せて説明する。

図５は、本開示の実施形態に係るオンライン・ビジネスを実現するシステムの相互作用の図である。関連する主な構成要素は、サード・パーティ開発サーバＩＳＶ、業務実行サーバ、複数のＩＳＰ（便宜上、図５では、ＩＳＰを３つ示している）、及び、認証コンポーネントを含む。

ＩＳＶから発行される呼び出し要求は、ページＡＰＩ呼び出し（すなわち、呼び出し関係のある複数のオープンＡＰＩの呼び出し）、及び、ＲＥＳＴ ＡＰＩ呼び出し（すなわち、他のオープンＡＰＩと呼び出し関係を持たない１つ以上のオープンＡＰＩの呼び出し）を含むことができる。

業務実行サーバは、業務実行時のセキュリティ及びフロー制御に関与する。図５に示すように、業務実行サーバは、１つ以上のＩＳＶ、及び、１つ以上のＩＳＰ間のコネクターとして機能し、オープンＡＰＩを呼び出す呼び出し要求を、ＩＳＶから対応のＩＳＰへ送信する。ＡＰＩプロセスは、１つ以上のＩＳＰとの相互作用に関する複数の操作を含み、この操作には、例えば、ページ相互作用操作や、通常のＲＥＳＴ ＡＰＩの操作が含まれる。同様に、プロセス・フロー・ページＡＰＩの処理中、ＩＳＰは、他のＩＳＰから提供されるサービスを呼び出して、他のＩＳＰから供給される１つ以上のページを、自身のページに埋め込み、埋め込んだページを、業務実行サーバがＩＳＶへ送信するために、業務実行サーバへ戻す。

認証コンポーネントは、種々の認証プロセス、例えば、業務実行サーバによるＩＳＶの認証、ＩＳＰによる業務実行サーバの認証等に関与する。

図６は、オープンＡＰＩに基づく業務の実装の実施形態を説明している。この図では、業務フローが、オープンＡＰＩを３回呼び出す必要があり、ＩＳＰ２のサービスは、ＩＳＰ１に応答する２度目の操作の中で呼び出される必要がある。

ステージ６０１：利用者は業務要求をＩＳＶへ発行する。

このステージでは、利用者から発行される業務要求には、入札要求、返金要求等が含まれる。利用者は、このような業務要求を発行する前に、ログインする必要がある。

ステージ６０２：ＩＳＶは、アプリケーションＡＰＰを介して、呼び出し要求をオープンＡＰＩへ発行する。

このステージにおいて、呼び出し要求は、ＡＰＩを呼び出すのに必要なパラメータ、及び、このパラメータに関する署名情報を含む。

ステージ６０３：業務実行サーバは、要求の受信後、利用者ログイン情報及びクッキーを検証する。検証が通れば、プロセスは次のステージに進み、検証が通らなければ、利用者の要求を拒否する（図示せず）。

ステージ６０４：業務実行サーバは、ＩＳＶのアクセス権限を検証する。この検証には、ＩＳＶはＡＰＩを呼び出してフローを制御する権限を与えられているかどうかを検証する処理が含まれる。この検証が通れば、プロセスは次ステージに進み、検証が通らなければ、呼び出し要求を拒否する（図示せず）。

ステージ６０５：業務実行サーバは、呼び出し要求を解析することで、オープンＡＰＩのＩＳＰ１をサポートしているかどうかを判定して、呼び出し要求をＩＳＰ１サーバへ送信する。

ステージ６０６：ＩＳＰ１サーバは、呼び出し要求の受信後、業務実行サーバの署名を検証する。この署名が検証を通ったら、プロセスは次ステージへ進み、検証を通らなければ、エラー・メッセージを戻す（図示せず）。

ステージ６０７：ＩＳＰ１サーバは、サービス・ページを業務実行サーバへ戻す。

ステージ６０８：業務実行サーバは、ＩＳＰ１から戻されたサービス・ページを埋め込み、ＩＳＶのＡＰＰへ戻す。

ステージ６０９：ＩＳＶのＡＰＰは、戻されたサービス・ページを自身のアプリケーション・ページに埋め込んでから、利用者に表示する。

ステージ６１０：利用者は、戻されたサービス・ページをクリックして、第２ステップの要求を始動する。この要求は、直接業務実行サーバへ送られる。

ステップ６１１：業務実行サーバは、要求の受信後、利用者を認証する。認証が通ると、プロセスは次のステージに進み、認証が通らなければ、エラー・メッセージを戻す（図示せず）。

ステージ６１２：業務実行サーバは、呼び出し要求の解析時に、要求をＩＳＰ１サーバへ送る。

ステージ６１３：ＩＳＰ１サーバは、呼び出し要求の受信後、業務実行サーバの署名を検証する。署名が検証を通れば、処理は次のステップに進み、署名が検証を通らなければ、エラー・メッセージを戻す（図示せず）。

ステージ６１４：ＩＳＰ１サーバは、要求解析時に、ＩＳＰ２から提供されるサービスを呼び出す必要があるかどうかを判定し、ＩＳＰ２を呼び出す要求をＩＳＰ２サーバへ送る。

ステージ６１５：ＩＳＰ２は、利用者のクッキーを検証する認証コンポーネントを介して、利用者の識別情報を検証する。この検証が通れば、検証結果をＩＳＰ２サーバへ戻して、次のステージに進め、検証が通らなければ、利用者ログイン・ページへ移って、利用者にログインし直すよう求める（図示せず）。

ステージ６１６：ＩＳＰ２サーバは、サービス要求に応答して、サービス・ページをＩＳＰ１サーバへ戻す。

ステージ６１７：ＩＳＰ１サーバは、ＩＳＰ２サーバから戻されたサービス・ページを自身のページに埋め込んで、業務実行サーバへ戻す。

ステージ６１８：業務実行サーバは、ＩＳＰ１サーバから戻されたサービス・ページを埋め込んで、ＩＳＶのＡＰＰへ送る。

ステージ６１９：ＩＳＶのＡＰＰは、戻されたページを自身のサービス・ページに埋め込んで、ぺージを利用者に表示する。

ステージ６２０：利用者は、戻されたサービス・ページをクリックして、プロセスの第３操作を始動する。この要求は業務実行サーバへ直接送られる。

ステージ６２１：業務実行サーバは、要求の受信後、利用者を認証する。認証が通ると、プロセスは次のステージに進み、認証が通らなければ、エラー・メッセージを戻す（図示せず）。

ステージ６２２：業務実行サーバは、呼び出し要求の解析時に、要求をＩＳＰ１サーバへ送る。

ステージ６２３：ＩＳＰ１サーバは、呼び出し要求の受信後、業務実行サーバの署名を検証する。署名が検証を通れば、プロセスは次のステージへ進み、署名が検証を通らなければ、エラー・メッセージを戻す（図示せず）。

ステージ６２４：ＩＳＰ１は、自身のサービス・ページをＩＳＶのＡＰＰへ戻す。

ステージ６２５：ＩＳＶのＡＰＰは、ＩＳＰ１サーバから戻された結果情報にしたがって、結果ページを埋め込み、利用者に表示する。

上記プロセスでは、業務実行サーバは、遷移、送信、制御、及び、監視機能を提供する。外部ＩＳＶが、要求を業務実行サーバへ発行する時、業務実行サーバは、要求の受信に応答して、ＩＳＶはページにアクセスする権限をあたえられているかどうかを検証する。この検証結果、ＩＳＶがページにアクセスする権限が与えられていれば、業務実行サーバは、要求をＩＳＰへ送信し、ＩＳＰの署名検証を取得し、ＩＳＰから戻されたデータを解析し、このデータを外部ＩＳＶへ戻す。ある実施形態では、業務実行サーバとＩＳＰの間の呼び出し用に、ＨＴＴＰを使用できる。すなわち、ＩＳＰは、ＨＴＴＰサービスを提供できる。業務実行サーバは、ＨＴＴＰクライアント側を介して、ＩＳＰページにアクセスして、ＩＳＰは、ＩＳＰページの内容を、業務実行サーバへ直接出力する。実施形態によっては、以下に述べるように、業務実行サーバは、オープンＡＰＩを呼び出すための呼び出し要求の受信後、複数の判定を実行することができる。

業務実行サーバは、ブラウザー内のクッキーが有効であるかどうかを判定できる。

業務実行サーバは、署名パラメータが適切であるかどうかを判定できる。署名証明パラメータは、ＩＳＶ利用者から導入されたデータの検証に使用される。署名パラメータは、ＩＳＶがＡＰＩを呼び出す前に、ＩＳＶと業務実行サーバの双方が合意したアルゴリズムにしたがって生成され、ＡＰＩ呼び出し中に導入される。

業務実行サーバは、Ａｐｐｋｅｙパラメータが適正であるかどうか、Ａｐｐｋｅｙパラメータが、現ページＡＰＩのアクセス権限を持っているかどうかを判定できる。各ＡＰＩにアクセスするアプリケーションの証明及びキーは、Ａｐｐｋｅｙパラメータ（ＡｐｐｋｅｙとＡＰＰ秘匿情報を含む）と呼ばれ、アプリケーションごとのセキュリティを認証、及び、制御するのに使用される。Ａｐｐｋｅｙパラメータは、ＩＳＶがＡＰＩを呼び出す際、導入される。

業務実行サーバは、セッション・パラメータがクッキーの利用者に対応しているかどうかを判定できる。ＩＳＶによって開発されたアプリケーションが、業務実行サーバから供給される情報を取得する際、この情報が、利用者の機密情報であれば、情報取得前に、利用者はログインする必要がある。利用者は、利用者認証下で、データにアクセスできることを示すため、ログイン後、セッション・パラメータ（セッション・キー）を取得する。この情報は、利用者のログイン時に作成され、ＡＰＩ呼び出し中に導入される。

業務実行サーバは、タイムスタンプ・パラメータと現在時間との時間間隔が、３０分以内であるかどうかを判定できる。タイムスタンプ・パラメータは、ＩＳＶアプリケーションがＡＰＩにアクセスする回数を制御するのに使用され、業務実行サーバによって作成される。タイムスタンプ・パラメータは、利用者のブラウザーのクッキーに書き込まれて、利用者は、ページ訪問によってＡＰＩにアクセスする際にタイムスタンプ・パラメータを取得するため、クッキーを読み取る。

業務実行サーバは、セッション・パラメータに対応する利用者が、対応するＡｐｐｋｅｙパラメータにアクセスする権限を持っているかどうかを判定できる。

上記判定のいずれにも該当しなければ、利用者の認証は通らない。

更に、上記プロセスにおいて、認証コンポーネントは、ログイン検証に関する統合機能を提供する。ある実施形態では、認証コンポーネントは、独立サーバとして存在できる。つまり、認証コンポーネントを、業務実行サーバやＩＳＰのものとは異なるドメイン名を使用できる。クッキーは、業務実行サーバのドメインに書き込まれる。他のＩＳＰを認証する際には、クッキーが、業務実行サーバのドメイン内にあるかどうかを判定するだけでよい。他のドメインが、業務実行サーバのドメイン内のクッキーへアクセス可能となるよう、アクセス中に、Ｐ３Ｐヘッダを使用できる。

図７では、認証コンポーネントを用いた認証プロセスを示し、このプロセスは、以下に述べる複数のステージを含むことができる。

ステージ７０１：利用者は、ログイン要求をＩＳＶへ送信する。

ステージ７０２：ＩＳＶは、ＡＰＰを介して、ログイン要求を業務実行サーバへ送り、自身の認証パラメータ（複数）を業務実行サーバへ送信する。

ステージ７０３：業務実行サーバは、要求の受信後、ログイン要求を認証コンポーネントへ送る。

ステップ７０４：認証コンポーネントは、業務実行サーバからのログイン要求の受信後、利用者ログイン・ページへ遷移する。利用者は、利用者名とパスワードを入力する。検証が通った場合、処理は次のステージへ進み、検証が通らなければ、処理は、ログイン・ページに戻る（図示せず）。

ステージ７０５：認証コンポーネントは、クッキーを書き込む要求を業務実行サーバへ発行する。

ステップ７０６：業務実行サーバは、要求受信後、１つ以上の要求パラメータに応じて、セキュリティ検証を実行する。検証が通ると、業務実行サーバは、クッキーを書き込む。

ステージ７０７：業務実行サーバは、クッキーの書き込む結果に対する応答を認証コンポーネントへ戻す。

オープンＡＰＩに基づくオンライン・ビジネスの実装プロセスを、システムとして実装できる。図８で示すように、本開示の実施形態により提供されるオープンＡＰＩに基づくオンライン・ビジネスの実装システムに対応するネットワーク接続形態を提供している。このシステムは、サード・パーティ開発サーバ８０１、業務実行サーバ８０２、及び、ＩＳＰサーバ８０３を含むことができる。実施形態によっては、ＩＳＰサーバが複数あってもよい。便宜上、図８では、ＩＳＰサーバを２つだけ示している。

業務実行サーバ８０２の利用者は、オンライン・ビジネスを展開、制御できる。具体的には、各サーバは、以下に述べる各機能を実行する。

サード・パーティ開発サーバ８０１は、利用者の業務要求にしたがって、オープンＡＰＩを呼び出すための呼び出し要求を、業務実行サーバ８０２へ送信する。サード・パーティ開発サーバ８０１は、業務実行サーバ８０２から戻されるサービス・ページを受信し、このページを、利用者に送信するための業務要求に対応するページに埋め込む。

業務実行サーバ８０２は、サード・パーティ開発サーバ８０１から送られた呼び出し要求にしたがって、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰサーバ８０３を判定し、判定されたＩＳＰサーバ８０３へ呼び出し要求を送信する。業務実行サーバ８０２は、ＩＳＰサーバ８０３から戻されたサービス・ページを受信し、サード・パーティ開発サーバ８０１へ送る。

ＩＳＰサーバ８０３は、業務実行サーバ８０２から送られた呼び出し要求にしたがって、対応するサービス・ページを業務実行サーバ８０２へ戻す。

オープンＡＰＩに基づくネットワークを実現するプロセスは、装置として実装できる。図９に示すように、上記プロセス、及び、本開示の実施形態に対応するオープンＡＰＩに基づくオンライン・ビジネスを実現する装置を提供している。この装置は、第１受信部９０１、第１ＩＳＰ呼び出し部９０２、及び、第１呼び出し結果フィードバック部９０３を含むことができる。

第１受信部９０１は、利用者の業務要求にしたがって、サード・パーティ開発サーバから送られたオープンＡＰＩを呼び出す呼び出し要求を受信する。

第１ＩＳＰ呼び出し部９０２は、第１受信部９０１によって受信された呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰサーバを判定して、このＩＳＰサーバに呼び出し要求を送信する。

第１呼び出し結果フィードバック部９０３は、第１ＩＳＰ呼び出し部９０２から送られた呼び出し要求にしたがって、ＩＳＰサーバから戻されたサービス・ページを受信して、このページをサード・パーティ開発サーバへ送信する。サード・パーティ開発サーバは、サービス・ページを処理して、処理済のサービス・ページを利用者へ送信する。サード・パーティ開発サーバは、サービス・ページを業務要求に対応するページに埋め込むことで、サービス・ページを処理する。

図１０に示すように、本開示の一実施形態によれば、第１ＩＳＰ呼び出し部９０２は、呼び出し関係判定モジュール９０２Ａ、第１呼び出し実行モジュール９０２Ｂ、及び、第２呼び出し実行モジュール９０２Ｃを更に含むことができる。

呼び出し関係判定モジュール９０２Ａは、第１受信部９０１が受信した呼び出し要求の中で呼び出し要求されるＡＰＩが、複数のオープンＡＰＩを含む場合、複数のオープンＡＰＩの呼び出し関係を判定する。

第１呼び出し実行モジュール９０２Ｂは、呼び出し関係モジュール９０２Ａにより判定された呼び出し関係にしたがって、呼び出し順序が、複数のオープンＡＰＩに存在すると判定された場合、複数のオープンＡＰＩの呼び出し順序の先頭にある第１オープンＡＰＩに対応するＩＳＰサーバへ、呼び出し要求を送信する。

呼び出し関係判定モジュール９０２Ａによって判定された呼び出し関係にしたがって、呼び出し順序が、複数のオープンＡＰＩ間に存在しないと判定された場合、第２呼び出し実行モジュール９０２Ｃは、複数のオープンＡＰＩにそれぞれ対応する複数のＩＳＰサーバへ、呼び出し要求を送信する。

図１１に示すように、本開示の実施形態によれば、図９に示した装置は、呼び出し関係埋め込み部９０４を、更に含んでもよい。

呼び出し関係にしたがって、呼び出し順序が、複数のオープンＡＰＩに存在すると判定された場合、呼び出し関係埋め込み部９０４は、複数のオープンＡＰＩの呼び出し関係をサービス・ページに埋め込む。呼び出し関係埋め込み部９０４は、埋め込み処理済のサービス・ページを、第１呼び出し結果フィードバック部９０３へ提供する。

図１２に示すように、本開示の実施形態によれば、図９に示した装置は、第２受信部９０５、第２ＩＳＰ呼び出し部９０６、及び、第２呼び出し結果フィードバック部９０７を、更に含んでもよい。

第２受信部９０５は、第１オープンＡＰＩの次に、且つ、第１呼び出し結果フィードバック部９０３によって戻されるサービス・ページに埋め込まれる呼び出し順序にしたがって始動する第２オープンＡＰＩを呼び出すための呼び出し要求を受信する。

第２ＩＳＰ呼び出し部９０６は、第２受信部 905により受信される呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信する。

第２呼び出し結果フィードバック部９０７は、第２ＩＳＰ呼び出し部９０６にしたがって、呼び出し要求に対応する第２オープンＡＰＩに関連するＩＳＰサーバから戻されたサービス・ページを受信して、サード・パーティ開発サーバへ送信する。サード・パーティ開発サーバは、サービス・ページを処理して、処理済のサービス・ページを利用者に送る。

図１３に示すように、本開示の実施形態によれば、図１２に示した装置内の第２ＩＳＰ呼び出し部９０６は、呼び出し関係解析モジュール９０６Ａ、及び、呼び出し要求送信モジュール９０６Ｂを、更に含んでもよい。

呼び出し関係解析モジュール９０６Ａは、第２受信部 905が受信した呼び出し要求を第２オープンＡＰＩに対応するＩＳＰサーバへ送信する前に、複数のオープンＡＰＩの呼び出し関係にしたがって、第１オープンＡＰＩを介して、第２オープンＡＰＩを呼び出す必要があるかどうかを判定する。

呼び出し関係解析モジュール９０６Ａの解析結果が、第２オープンＡＰＩを呼び出す必要がある場合、呼び出し要求送信モジュール９０６Ｂは、呼び出し要求を第２オープンＡＰＩに対応するＩＳＰサーバへ送る。

したがって、ある実施形態では、図１２に示した装置の第２呼び出し結果フィードバック部９０７は、受信モジュール９０７Ａ、及び、フィードバック・モジュール９０７Ｂを、更に含んでもよい。

受信モジュール９０７Ａは、第１オープンＡＰＩに対応するＩＳＰサーバから戻される処理済のページを受信する。第１オープンＡＰＩに対応するＩＳＰサーバは、第２オープンＡＰＩに対応するＩＳＰサーバから戻されたサービス・ページを受信して、自身のサービス・ページに埋め込み、更に、埋め込み処理したページを受信モジュール９０７Ａへ戻す。

フィードバック・モジュール９０７Ｂは、受信モジュール９０７Ａによって受信されたサービス・ページをサード・パーティ開発サーバへ送り、サービス・ページを処理して、処理済みのページを利用者へ送る。

図１４に示すように、本開示の実施形態によれば、図９に示した装置は、認証部９０８を、更に含んでもよい。

認証部９０８は、業務要求を送信する利用者を認証して、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰを判定するよう、第１ＩＳＰ呼び出し部９０２に指示する。

図１５に示すように、本開示の実施形態によれば、図１４に示した装置の認証部９０８は、認証モジュール９０８Ａ、及び、命令モジュール９０８Ｂを、更に含んでもよい。

認証モジュール９０８Ａは、利用者が設定条件を満たす場合、利用者権限を判定する。設定条件には、利用者がログインできたときに利用者ログイン証明を作成するステップと、利用者ログイン証明が有効であるかどうかを判定するステップを含み、利用者ログイン証明は、利用者が業務要求を送る度に更新される。

命令モジュール９０８Ｂは、利用者には権限があることを、認証モジュール９０８Ａによって判定された場合、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰを判定することを、第１ＩＳＰ呼び出し部９０２に対して命令する。

図１６に示すように、本発明の開示によれば、図９に示した装置の第１ＩＳＰ呼び出し部９０２は、ＩＳＰサーバ判定モジュール９０２Ｄ、及び、ＩＳＰサーバ選択モジュール９０２Ｅを、更に含んでもよい。

ＩＳＰサーバ判定モジュール９０２Ｄは、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰの数を判定する。

ＩＳＰサーバ選択モジュール９０２Ｅは、ＩＳＰサーバ判定モジュール９０２Ｄによって判定されたＩＳＰが、複数のＩＳＰを含む場合、ランダム・ルート・アルゴリズムを用いて、複数のＩＳＰサーバのうちの１つを見つけ、見つけたＩＳＰサーバに呼び出し要求を送信する。

本開示の実施形態によって提供されるオープンＡＰＩに基づくオンライン・ビジネスを実現する装置の機能を実装する専用の方法、及び／または、手段の詳細な説明については、上記のプロセスの該当ステージに詳細に説明してきたため、提供していない。

本開示の実施形態が提供するオープンＡＰＩに基づくオンライン・ビジネスを実現する装置は、独立した単独の装置でもよい。種々の用途に、ネットワーク構造の簡略化を考慮して、装置によって実行される機能を、業務実行サーバに統合できる。例えば、装置は、上記機能を実行する部として機能するよう、業務実行サーバに追加することが可能である。その他、本開示の実施形態が提供するオープンＡＰＩに基づくオンライン・ビジネスを実現する装置は、コンピュータによって実行可能な命令により実装できる。当業者であれば、この装置が前述の機能を備え、且つ、本開示の請求項によって保護される限り、上記モジュールを個別に定義、または、分割できることを理解されよう。

本開示を、実施形態の方法、装置（システム）、及び、コンピュータによって実行可能な命令のフローチャート、及び／または、ブロック図にしたがって説明した。フローチャート、及び／または、ブロック図、及び／または、ブロックの組み合わせは、コンピュータによって実行可能な命令によって実装できることを理解されたい。このコンピュータによって実行可能な命令は、１つ以上の汎用コンピュータ、１つ以上の専用コンピュータ、１つ以上の組み込み式コンピュータ、または、プログラマブル・データ処理装置の１つ以上の他のプロセッサー上で実装可能であり、これによって、ブロック図の１プロセス、または、複数プロセス、及び／または、１ブロック、または、複数ブロックの所定の機能を実装する装置を、コンピュータ、または、命令を実行するためのプログラマブル・データ処理装置の他のプロセッサーによって作成できる。

コンピュータによって実行可能な命令は、何らかの方法で、コンピュータ、または、他のプログラマブル・データ処理装置が動作可能な１つ以上のコンピュータ可読記憶媒体内に記憶できる。コンピュータの１つ以上のコンピュータ可読記憶媒体に記憶された命令は、ブロック図に示された１プロセス、または、複数プロセス、及び／または、１ブロック、または、複数ブロックの所定の機能を実装できる。

コンピュータにより実行可能な命令は、１つ以上のコンピュータ、または、１つ以上の他のプログラマブル・データ処理装置内に導入可能であり、これによって、上記のプロセスを実装するために、１つ以上のコンピュータ、または、１つ以上の他のプログラマブル・データ処理装置で一連の操作を実行できる。１つ以上のコンピュータ、または、１つ以上の他のプログラマブル・データ処理装置内で実行される命令は、ブロック図に示された１つ、または、複数のプロセス、及び／または、１つ、または、複数のブロックの所定機の能を実装する工程を提供する。

本開示から提供される態様の少なくとも１つの使用によるオンライン・ビジネスを実行する際の方法は、サード・パーティ開発サーバから、利用者の業務要求にしたがって、オープンＡＰＩを呼び出す呼び出し要求を受信するステップと、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰサーバを判定するステップと、判定されたＩＳＰサーバへ呼び出し要求を送信するステップと、呼び出し要求にしたがって、ＩＳＰサーバから戻されたサービス・ページを受信するステップと、サービス・ページを処理して、処理済のサービス・ページを利用者へ送信するため、サービス・ページをサード・パーティ開発サーバへ送信するステップを含むことができる。サービス・ページの処理は、サービス・ページを、業務要求に対応するページに埋め込む処理を含む。このように、サービス・データを、サービス・ページを介して、サード・パーティ開発サーバに戻すほうが、従来の方法のように構造データを直接サード・パーティ開発サーバへ送るよりも、データ・セキュリティの観点から安全である。その他、サード・パーティサーバとＩＳＰ間のサーバによって、業務の管理機能全てが実装されているため、サード・パーティサーバは、業務ロジックを解析する必要がなく、制御能力が向上する。

本開示は、限定された数の例示的実施形態を提供している。だが、本開示は、この例に制限されず、本開示の保護の下、当業者によるいかなる変更も考慮されるであろう。

Claims (18)

1. オープン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）に基づくネットワーク取引を実現する方法であって、
   利用者の取引要求にしたがって、サード・パーティ開発サーバから、オープンＡＰＩを呼び出すための第１呼び出し要求を受信するステップと、
   呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するインターネット・サービス・プロバイダー（ＩＳＰ）サーバを判定するステップと、
   第１呼び出し要求を、判定されたＩＳＰサーバへ送信するステップと、
   第１呼び出し要求にしたがってＩＳＰサーバにより戻されたサービス・ページを受信するステップと、および
   サービス・ページを処理して、処理済みのサービス・ページを利用者へ送信するため、サービス・ページをサード・パーティ開発サーバへ送信するステップとを含み、前記処理は、前記サービス・ページを、取引要求に対応するページに埋め込む処理を含む方法。
2. 呼び出しが要求されるオープンＡＰＩが、複数のオープンＡＰＩを含む場合、第１呼び出し要求を、判定されたＩＳＰサーバへ送信する前に、複数のオープンＡＰＩ間の呼び出し関係を判定するステップと、
   第１呼び出し要求を、判定されたＩＳＰサーバへ送信するステップであって、
   呼び出し関係にしたがって、呼び出し順序が前記複数のオープンＡＰＩに存在する場合には、複数のオープンＡＰＩの呼び出し順序の先頭にある第１オープンＡＰＩに対応するＩＳＰサーバへ、第１呼び出し要求を送信するステップと、および
   呼び出し関係にしたがって呼び出し順序が、複数のオープンＡＰＩに存在しない場合には、複数のオープンＡＰＩのそれぞれに対応する複数のＩＳＰサーバのそれぞれへ、前記第１呼び出し要求を送信するステップを、更に含む請求項１に記載の方法。
3. 呼び出し関係にしたがって、呼び出し順序が複数のオープンＡＰＩに存在する場合、サービス・ページをサード・パーティ開発サーバへ送信する前に、サービス・ページに、複数のオープンＡＰＩの呼び出し順序を埋め込むステップを更に含む請求項２に記載の方法。
4. 呼び出し順序にしたがって、第１オープンＡＰＩの次に、且つ、前記サービス・ページに埋め込まれた第２オープンＡＰＩを呼び出すための第２呼び出し要求を受信するステップと、
   第２呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信するステップと、
   前記第２呼び出し要求にしたがって、第２オープンＡＰＩに対応するＩＳＰサーバから、サービス・ページを受信するステップと、および
   サード・パーティ開発サーバによりサービス・ページを処理し、処理済のサービス・ページを利用者に送信するため、サービス・ページを前記サード・パーティ開発サーバへ送信するステップを更に含む請求項３に記載の方法。
5. 第２呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信する前に、
   複数のオープンＡＰＩの呼び出し関係にしたがって、第２オープンＡＰＩを、第１オープンＡＰＩを介して呼び出す必要があるかどうかを判定するステップと、
   第２呼び出し要求を第２オープンＡＰＩに対応するＩＳＰサーバへ送信するステップと、および、
   第１オープンＡＰＩに対応するＩＳＰサーバから、第２オープンＡＰＩに対応するＩＳＰサーバへ送信呼び出し要求を送信するステップと、および
   第１オープンＡＰＩに対応するＩＳＰサーバから、処理済のサービス・ページ（当該サービス・ページは、第２オープンＡＰＩに対応するＩＳＰサーバから、第１オープンＡＰＩに対応するＩＳＰサーバによって受信され、第２オープンＡＰＩに対応するＩＳＰサーバのサービス・ページに埋め込まれる）を受信するステップにより、
   第２呼び出し要求に応答して、第２オープンＡＰＩに対応するＩＳＰサーバから、サービス・ページを受信するステップを含む請求項４に記載の方法。
6. サービス・ページを取引要求に対応するページに埋め込むことは、サービス・ページを、取引要求に対応するページにＩｆｒａｍｅ形式で埋め込むことを含む請求項１に記載の方法。
7. 呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰを判定する前に、取引要求を送信する利用者を認証するステップを、更に含む請求項１に記載の方法。
8. 取引要求を送信する利用者を認証することは、
   前記利用者がログインできた時、利用者ログイン識別情報を作成するステップと、および、
   利用者が、各取引要求を送信する度に利用者ログイン識別情報が更新される際に、利用者ログイン情報は有効であるかどうかを判定するステップを含む請求項７に記載の方法。
9. 呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応する判定されたＩＳＰサーバが、複数のＩＳＰサーバを含む場合に、判定されたＩＳＰサーバへ第１呼び出し要求を送信することは、
   ランダム・ルート・アルゴリズムを用いて、判定されたＩＳＰサーバの１つを見つけるステップと、
   判定済みのＩＳＰサーバのうち見つけた１つに、第１呼び出し要求を送信するステップを含む請求項１に記載の方法。
10. オープン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）に基づくネットワーク・ビジネスを実装する装置であって、
    利用者の業務要求にしたがって、サード・パーティ開発サーバによって送られたオープンＡＰＩを呼び出すための呼び出し要求を受信する第１受信部と、
    第１受信部によって受信された呼び出し要求に呼び出し要求されるオープンＡＰＩに対応するインターネット・サービス・プロバイダー（ＩＳＰ）サーバを判定し、判定された前記ＩＳＰサーバへ前記呼び出し要求を送信する第１ＩＳＰ呼び出し部と、および
    第１ＩＳＰ呼び出し部によって送られた呼び出し要求にしたがって、対応するＩＳＰサーバから戻されたサービス・ページを受信して、サービス・ページを処理し、処理済のサービス・ページを利用者に送るため、サービス・ページをサード・パーティ開発サーバへ送り、前記処理には、サービス・ページを業務要求に対応するページに埋め込むことを含む第１呼び出し結果フィードバック部を含む装置。
11. 第１ＩＳＰ呼び出し部は、
    第１受信部によって受信された前記呼び出し要求の中で呼び出し要求されるオープンＡＰＩが、複数のオープンＡＰＩを含む場合、複数のオープンＡＰＩの呼び出し関係を判定する呼び出し関係判定モジュールと、
    呼び出し関係判定モジュールによって判定された呼び出し関係にしたがって、呼び出し順序が、複数のオープンＡＰＩに存在すると判定された場合、複数のオープンＡＰＩの呼び出し順序の先頭にある第１オープンＡＰＩに対応するＩＳＰサーバへ呼び出し要求を送信する第１呼び出し実行モジュールと、
    および、呼び出し関係判定モジュールによって判定された前記呼び出し関係にしたがって、呼び出し順序が、複数のオープンＡＰＩに存在しないと判定された場合、複数のオープンＡＰＩに対応する個々の複数のＩＳＰサーバへ、前記呼び出し要求を送信する第２呼び出し実行モジュールを含む請求項１０に記載の装置。
12. 呼び出し関係にしたがって、呼び出し順序が、複数のオープンＡＰＩに存在すると判定された場合、複数のオープンＡＰＩの呼び出し関係をサービス・ページに埋め込み、埋め込み処理をしたサービス・ページを、呼び出し結果フィードバック部へ送る呼び出し関係埋め込み部を更に含む請求項１１に記載の装置。
13. 第１オープンＡＰＩの次に、且つ、第１呼び出し結果フィードバック部によって戻されるサービス・ページ内に埋め込まれた呼び出し順序にしたがって始動する第２オープンＡＰＩを呼び出すための呼び出し要求を受信する第２受信部と、
    第２受信部によって受信される呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信する第２ＩＳＰ呼び出し部と、および、
    第２ＩＳＰ呼び出し部にしたがって、呼び出し要求に対応する第２オープンＡＰＩに対応するＩＳＰサーバから戻されたサービス・ページを受信して、サービス・ページを処理し、処理済のサービス・ページを利用者へ送信するため、サービス・ページをサード・パーティ開発サーバへ送信する第２呼び出し結果フィードバック部を更に含む請求項１２に記載の装置。
14. 第２ＩＳＰ呼び出し部は、
    第２受信部により受信された呼び出し要求を、第２オープンＡＰＩに対応するＩＳＰサーバへ送信する前に、複数のオープンＡＰＩの呼び出し関係にしたがって、第２オープンＡＰＩは第１オープンＡＰＩを介して呼び出す必要があるかどうかを判定する呼び出し関係解析モジュールと、および、
    呼び出し関係解析モジュールの解析結果が、第２オープンＡＰＩを呼び出す必要があるとされた場合、第２オープンＡＰＩに対応するＩＳＰサーバへ、呼び出し要求を送信する呼び出し要求送信モジュールを含み、
    第２呼び出し結果フィードバック部は、第１オープンＡＰＩに対応する前記ＩＳＰサーバによって処理され、戻されたサービス・ページを受信する受信モジュールを含み、サービス・ページは、第２オープンＡＰＩに対応するＩＳＰサーバによって戻されて、第１オープンＡＰＩによって提供されるサービス・ページに埋め込む第１オープンＡＰＩに対応するＩＳＰサーバにより受信されるサービス・ページであり、
    第２呼び出し結果フィードバック部は、サービス・ページを処理して、処理済のサービス・ページを利用者へ送信するため、受信モジュールが受信したサービス・ページをサード・パーティ開発サーバへ送信するフィードバック・モジュールを含む請求項１３に記載の装置。
15. 業務要求を送信する利用者を認証して、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰを判定することを第１ＩＳＰ呼び出し部に命令する認証部を更に含む請求項１０に記載の装置。
16. 認証部は、
    利用者が設定条件を満足する場合、利用者認証を判定する認証モジュールを含み、設定条件には、
    利用者がログインできた時、利用者ログイン証明を作成し、利用者ログイン証明が有効であるかどうかを判定し、利用者ログイン証明は、利用者が業務要求を送信する度に更新され、および、
    認証部は、利用者が認証されたことを、前記認証モジュールによって判定された場合、前記呼び出し要求の中で呼び出し要求されたオープンＡＰＩに対応するＩＳＰを判定することを、第１ＩＳＰ呼び出し部に命令する命令モジュールを含む請求項１５に記載の装置。
17. 第１ＩＳＰ呼び出し部は、
    呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するＩＳＰの数を判定するＩＳＰサーバ判定モジュールと、および
    ＩＳＰサーバ判定モジュールによって判定されたＩＳＰが、複数のＩＳＰを含む場合、ランダム・ルート・アルゴリズムを用いて、複数のＩＳＰサーバの中からＩＳＰサーバを１つ見つけ、見つけた前記ＩＳＰサーバへ、前記呼び出し要求を送信するＩＳＰサーバ選択モジュールを含む請求項１０に記載の装置。
18. オープン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）に基づくネットワーク取引を実現するシステムであって、
    サード・パーティ開発サーバと、
    取引実行サーバと、および
    ＩＳＰサーバを含み、
    サード・パーティ開発サーバは、利用者の取引要求にしたがって、オープンＡＰＩの呼び出し要求を、取引実行サーバへ送信して、取引実行サーバから戻されたサービス・ページを受信して、利用者に提供する前に、サービス・ページを取引要求に対応するページに埋め込み、
    取引実行サーバは、呼び出し要求に応答して、呼び出し要求の中で呼び出し要求されるオープンＡＰＩに対応するインターネット・サービス・プロバイダー（ＩＳＰ）サーバを判定して、判定されたＩＳＰサーバに呼び出し要求を送信し、ＩＳＰサーバから戻されたサービス・ページを受信して、サービス・ページをサード・パーティ開発サーバへ送信し、
    ＩＳＰサーバは、取引実行サーバによって送られた呼び出し要求にしたがって、対応するサービス・ページを取引実行サーバへ戻すことを特徴とするシステム。

Images