オープンアプリケーションプログラミングインターフェースAPIに基づくネットワーク取引を実現する方法であって、利用者の取引要求にしたがって、サードパーティ開発サーバから、オープンAPIを呼び出すための第1呼び出し要求を受信するステップと、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するインターネットサービスプロバイダーISPサーバを判定するステップと、第1呼び出し要求を、判定されたISPサーバへ送信するステップと、第1呼び出し要求にしたがってISPサーバにより戻されたサービスページを受信するステップと、およびサービスページを処理して、処理済みのサービスページを利用者へ送信するため、サービスページをサードパーティ開発サーバへ送信するステップとを含み、前記処理は、前記サービスページを、取引要求に対応するページに埋め込む処理を含む方法。呼び出しが要求されるオープンAPIが、複数のオープンAPIを含む場合、第1呼び出し要求を、判定されたISPサーバへ送信する前に、複数のオープンAPI間の呼び出し関係を判定するステップと、第1呼び出し要求を、判定されたISPサーバへ送信するステップであって、呼び出し関係にしたがって、呼び出し順序が前記複数のオープンAPIに存在する場合には、複数のオープンAPIの呼び出し順序の先頭にある第1オープンAPIに対応するISPサーバへ、第1呼び出し要求を送信するステップと、および呼び出し関係にしたがって呼び出し順序が、複数のオープンAPIに存在しない場合には、複数のオープンAPIのそれぞれに対応する複数のISPサーバのそれぞれへ、前記第1呼び出し要求を送信するステップを、更に含む請求項1に記載の方法。呼び出し関係にしたがって、呼び出し順序が複数のオープンAPIに存在する場合、サービスページをサードパーティ開発サーバへ送信する前に、サービスページに、複数のオープンAPIの呼び出し順序を埋め込むステップを更に含む請求項2に記載の方法。呼び出し順序にしたがって、第1オープンAPIの次に、且つ、前記サービスページに埋め込まれた第2オープンAPIを呼び出すための第2呼び出し要求を受信するステップと、第2呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信するステップと、前記第2呼び出し要求にしたがって、第2オープンAPIに対応するISPサーバから、サービスページを受信するステップと、およびサードパーティ開発サーバによりサービスページを処理し、処理済のサービスページを利用者に送信するため、サービスページを前記サードパーティ開発サーバへ送信するステップを更に含む請求項3に記載の方法。第2呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信する前に、複数のオープンAPIの呼び出し関係にしたがって、第2オープンAPIを、第1オープンAPIを介して呼び出す必要があるかどうかを判定するステップと、第2呼び出し要求を第2オープンAPIに対応するISPサーバへ送信するステップと、および、第1オープンAPIに対応するISPサーバから、第2オープンAPIに対応するISPサーバへ送信呼び出し要求を送信するステップと、および第1オープンAPIに対応するISPサーバから、処理済のサービスページ当該サービスページは、第2オープンAPIに対応するISPサーバから、第1オープンAPIに対応するISPサーバによって受信され、第2オープンAPIに対応するISPサーバのサービスページに埋め込まれるを受信するステップにより、第2呼び出し要求に応答して、第2オープンAPIに対応するISPサーバから、サービスページを受信するステップを含む請求項4に記載の方法。サービスページを取引要求に対応するページに埋め込むことは、サービスページを、取引要求に対応するページにIframe形式で埋め込むことを含む請求項1に記載の方法。呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPを判定する前に、取引要求を送信する利用者を認証するステップを、更に含む請求項1に記載の方法。取引要求を送信する利用者を認証することは、前記利用者がログインできた時、利用者ログイン識別情報を作成するステップと、および、利用者が、各取引要求を送信する度に利用者ログイン識別情報が更新される際に、利用者ログイン情報は有効であるかどうかを判定するステップを含む請求項7に記載の方法。呼び出し要求の中で呼び出し要求されるオープンAPIに対応する判定されたISPサーバが、複数のISPサーバを含む場合に、判定されたISPサーバへ第1呼び出し要求を送信することは、ランダムルートアルゴリズムを用いて、判定されたISPサーバの1つを見つけるステップと、判定済みのISPサーバのうち見つけた1つに、第1呼び出し要求を送信するステップを含む請求項1に記載の方法。オープンアプリケーションプログラミングインターフェースAPIに基づくネットワークビジネスを実装する装置であって、利用者の業務要求にしたがって、サードパーティ開発サーバによって送られたオープンAPIを呼び出すための呼び出し要求を受信する第1受信部と、第1受信部によって受信された呼び出し要求に呼び出し要求されるオープンAPIに対応するインターネットサービスプロバイダーISPサーバを判定し、判定された前記ISPサーバへ前記呼び出し要求を送信する第1ISP呼び出し部と、および第1ISP呼び出し部によって送られた呼び出し要求にしたがって、対応するISPサーバから戻されたサービスページを受信して、サービスページを処理し、処理済のサービスページを利用者に送るため、サービスページをサードパーティ開発サーバへ送り、前記処理には、サービスページを業務要求に対応するページに埋め込むことを含む第1呼び出し結果フィードバック部を含む装置。第1ISP呼び出し部は、第1受信部によって受信された前記呼び出し要求の中で呼び出し要求されるオープンAPIが、複数のオープンAPIを含む場合、複数のオープンAPIの呼び出し関係を判定する呼び出し関係判定モジュールと、呼び出し関係判定モジュールによって判定された呼び出し関係にしたがって、呼び出し順序が、複数のオープンAPIに存在すると判定された場合、複数のオープンAPIの呼び出し順序の先頭にある第1オープンAPIに対応するISPサーバへ呼び出し要求を送信する第1呼び出し実行モジュールと、および、呼び出し関係判定モジュールによって判定された前記呼び出し関係にしたがって、呼び出し順序が、複数のオープンAPIに存在しないと判定された場合、複数のオープンAPIに対応する個々の複数のISPサーバへ、前記呼び出し要求を送信する第2呼び出し実行モジュールを含む請求項10に記載の装置。呼び出し関係にしたがって、呼び出し順序が、複数のオープンAPIに存在すると判定された場合、複数のオープンAPIの呼び出し関係をサービスページに埋め込み、埋め込み処理をしたサービスページを、呼び出し結果フィードバック部へ送る呼び出し関係埋め込み部を更に含む請求項11に記載の装置。第1オープンAPIの次に、且つ、第1呼び出し結果フィードバック部によって戻されるサービスページ内に埋め込まれた呼び出し順序にしたがって始動する第2オープンAPIを呼び出すための呼び出し要求を受信する第2受信部と、第2受信部によって受信される呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信する第2ISP呼び出し部と、および、第2ISP呼び出し部にしたがって、呼び出し要求に対応する第2オープンAPIに対応するISPサーバから戻されたサービスページを受信して、サービスページを処理し、処理済のサービスページを利用者へ送信するため、サービスページをサードパーティ開発サーバへ送信する第2呼び出し結果フィードバック部を更に含む請求項12に記載の装置。第2ISP呼び出し部は、第2受信部により受信された呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信する前に、複数のオープンAPIの呼び出し関係にしたがって、第2オープンAPIは第1オープンAPIを介して呼び出す必要があるかどうかを判定する呼び出し関係解析モジュールと、および、呼び出し関係解析モジュールの解析結果が、第2オープンAPIを呼び出す必要があるとされた場合、第2オープンAPIに対応するISPサーバへ、呼び出し要求を送信する呼び出し要求送信モジュールを含み、第2呼び出し結果フィードバック部は、第1オープンAPIに対応する前記ISPサーバによって処理され、戻されたサービスページを受信する受信モジュールを含み、サービスページは、第2オープンAPIに対応するISPサーバによって戻されて、第1オープンAPIによって提供されるサービスページに埋め込む第1オープンAPIに対応するISPサーバにより受信されるサービスページであり、第2呼び出し結果フィードバック部は、サービスページを処理して、処理済のサービスページを利用者へ送信するため、受信モジュールが受信したサービスページをサードパーティ開発サーバへ送信するフィードバックモジュールを含む請求項13に記載の装置。業務要求を送信する利用者を認証して、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPを判定することを第1ISP呼び出し部に命令する認証部を更に含む請求項10に記載の装置。認証部は、利用者が設定条件を満足する場合、利用者認証を判定する認証モジュールを含み、設定条件には、利用者がログインできた時、利用者ログイン証明を作成し、利用者ログイン証明が有効であるかどうかを判定し、利用者ログイン証明は、利用者が業務要求を送信する度に更新され、および、認証部は、利用者が認証されたことを、前記認証モジュールによって判定された場合、前記呼び出し要求の中で呼び出し要求されたオープンAPIに対応するISPを判定することを、第1ISP呼び出し部に命令する命令モジュールを含む請求項15に記載の装置。第1ISP呼び出し部は、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPの数を判定するISPサーバ判定モジュールと、およびISPサーバ判定モジュールによって判定されたISPが、複数のISPを含む場合、ランダムルートアルゴリズムを用いて、複数のISPサーバの中からISPサーバを1つ見つけ、見つけた前記ISPサーバへ、前記呼び出し要求を送信するISPサーバ選択モジュールを含む請求項10に記載の装置。オープンアプリケーションプログラミングインターフェースAPIに基づくネットワーク取引を実現するシステムであって、サードパーティ開発サーバと、取引実行サーバと、およびISPサーバを含み、サードパーティ開発サーバは、利用者の取引要求にしたがって、オープンAPIの呼び出し要求を、取引実行サーバへ送信して、取引実行サーバから戻されたサービスページを受信して、利用者に提供する前に、サービスページを取引要求に対応するページに埋め込み、取引実行サーバは、呼び出し要求に応答して、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するインターネットサービスプロバイダーISPサーバを判定して、判定されたISPサーバに呼び出し要求を送信し、ISPサーバから戻されたサービスページを受信して、サービスページをサードパーティ開発サーバへ送信し、ISPサーバは、取引実行サーバによって送られた呼び出し要求にしたがって、対応するサービスページを取引実行サーバへ戻すことを特徴とするシステム。RESTAPIに基づくオンラインビジネスを実行するための上記手法には、幾つかの欠点がある。第1の欠点は、応答結果である構造データは、ISVから読み取られ易いということである。一般的な業務実行サーバから提供される業務データが、利用者以外のサードパーティ例えば、ISVによって取得されることは望ましくない。したがって、業務実行サーバの観点から、上記手法によって実行されるオンラインビジネスに関するデータのセキュリティは低い。第2の欠点は、現在のオンラインビジネスのほとんどに、利用者とサービスプロバイダー間に複数の対話を必要とする複雑な業務ロジック操作が伴われるということである。従来のオンラインビジネス実行法では、RESTAPIは、利用者とサービスプロバイダー間の問い合わせ、データ更新等の対話を一度しか実行できない。複雑なオンラインビジネスの場合、ISVは、完璧なフローを実現するために、複数のRESTAPIを構築する必要があるが、これには、ISVが、複数のAPI呼び出しにビジネスロジックを解析することが求められる。これによって、RESTAPIに基づくオンラインビジネスの実行法の使い勝手が悪くなる。種々のISVの解析能力の違いを併せて考えると、業務の一貫性を保証することが難しくなることは明らかである。この結果、業務実行サーバによる業務の管理能力が、不十分となる。以上のことから、既存のAPIに基づくオンラインビジネスでは、業務データのセキュリティは、保証されず、且つ、業務の管理能力も不十分である。本開示は、オープンAPIに基づくネットワーク取引を実現する方法を紹介し、更に、この方法によるシステム、並びに、装置も紹介している。従来技術の欠点の一部、例えば、業務データのセキュリティの低さや、業務の不十分な管理能力は、本開示の導入により解消される。一態様では、オープンAPIに基づくネットワーク取引を実現する方法は、利用者からの取引要求にしたがって、サードパーティ開発サーバから、オープンAPIを呼び出すための第1呼び出し要求を受信するステップと、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPサーバを判定するステップと、判定されたISPサーバに第1呼び出し要求を送信するステップと、第1呼び出し要求にしたがって、ISPサーバから戻されるサービスページを受信するステップと、更に、サービスページを処理して、処理済のサービスページを利用者へと送信するために、サービスページをサードパーティ開発サーバへ送信するステップを含むことが可能であり、サービスページの処理には、サービスページを取引要求に対応するページに埋め込む処理が含まれる。取引要求は、実装形態によっては、業務要求に関連してもよい。呼び出しを要求されたオープンAPIが複数のオープンAPIを含む場合、第1呼び出し要求を判定されたISPサーバに送信する前に、上記方法は、複数のオープンAPIの呼び出し関係を判定するステップと、更に、第1呼び出し要求を判定されたISPサーバへ送信するステップを含んでもよい。第1呼び出し要求を送信する処理は、呼び出し関係にしたがって、呼び出し順序が、複数のオープンAPIに存在する場合、第1呼び出し要求を、複数のオープンAPIの呼び出し順序の中で先頭にある第1オープンAPIに対応するISPサーバへ送信するステップと、更に、呼び出し関係に準じた呼び出し順序が、複数のオープンAPIの中に存在しない場合、第1呼び出し要求を、複数のオープンAPIのそれぞれに対応する複数のISPサーバのそれぞれへ送信するステップを更に含むことができる。呼び出し関係にしたがって、呼び出し順序が、複数のオープンAPIの中に存在する場合、サービスページをサードパーティ開発サーバへ送信する前に、上記方法は、サービスページの中に、複数のオープンAPIの呼び出し順序を埋め込むステップを、更に含んでもよい。上記方法は、呼び出し順序にしたがって、第1オープンAPIの次に、且つ、サービスページの中に埋め込まれた第2オープンAPIを呼び出すための第2呼び出し要求を受信するステップと、第2呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信するステップと、第2呼び出し要求にしたがって、第2オープンAPIに対応するISPサーバから、サービスページを受信するステップと、サードパーティ開発サーバによってサービスページを処理し、処理済のサービスページを利用者へ送信するために、サービスページをサードパーティ開発サーバに送信するステップを更に含んでもよい。第2呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信する前に、上記方法は、複数のオープンAPIの呼び出し関係にしたがって、第2オープンAPIを、第1オープンAPIを介して呼び出す必要があるかどうかを判定するステップと、第2呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信するステップと、第2呼び出し要求に応答して、第2オープンAPIに対応するISPサーバから、サービスページを受信するステップを更に含んでもよい。サービスページの受信は、例えば、送信呼び出し要求を、第1オープンAPIに対応するISPサーバから、第2オープンAPIに対応するISPサーバへ送信するステップと、第1オープンAPIに対応するISPサーバから、処理済のサービスページを受信するステップによって実現可能であり、サービスページは、第2オープンAPIに対応するISPサーバから、第1オープンAPIに対応するISPサーバによって受信され、このサービスページは、第2オープンAPIに対応するISPサーバのサービスページへと埋め込まれる。サービスページを取引要求に対応するページに埋め込むステップは、サービスページを、取引要求に対応するページにIframeインラインフレーム形式で埋め込むステップを含むことができる。呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPを判定する前に、上記方法は、取引要求を送信する利用者を認証するステップを更に含んでもよい。取引要求を送信する利用者を認証するステップは、利用者がログインできた際に、利用者ログイン識別情報を作成するステップと、利用者が、それぞれの取引要求を送信する度に、利用者ログイン識別情報が更新される際、この利用者ログイン識別情報が有効であるかどうかを判定するステップを含むことが可能である。呼び出し要求の中で呼び出し要求されるオープンAPIに対応する判定されたISPサーバが、複数のISPサーバを含む場合、第1呼び出し要求を、判定されたISPサーバへと送信するステップは、ランダムルートアルゴリズムを用いて、判定されたISPサーバの1つを見つけるステップと、第1呼び出し要求を、判定されたISPサーバのうち見つけたISPサーバの1つへ送信するステップを含むことができる。別の態様では、オープンAPIに基づくネットワーク取引を実現する装置は、利用者からの取引要求にしたがって、サードパーティ開発サーバから送られたオープンAPIを呼び出すための呼び出し要求を受信する第1受信部と、第1受信部によって受信された呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPサーバを判定して、判定されたISPサーバに呼び出し要求を送信する第1ISP呼び出し部と、並びに、第1呼び出し結果フィードバック部であって、第1ISP呼び出し部から送られた呼び出し要求にしたがって、ISPサーバから戻されたサービスページを受信して、サービスページを処理し、処理済のページを利用者へ送信するために、サービスページをサードパーティ開発サーバへ送信し、サービスページの処理は、サービスページを取引要求に対応するページに埋め込む処理を含む第1呼び出し結果フィードバック部とを含むことが可能である。第1ISP呼び出し部は、第1受信部が受信した呼び出し要求の中で呼び出し要求されるオープンAPIが、複数のオープンAPIを含む場合、複数のオープンAPIの呼び出し関係を判定する呼び出し関係判定モジュールと、呼び出し関係判定モジュールにより判定された呼び出し関係にしたがって、呼び出し順序が複数のオープンAPIに存在すると判定された場合、複数のオープンAPIの呼び出し順序の先頭にある第1オープンAPIに対応するISPサーバへ、呼び出し要求を送信する第1呼び出し実行モジュールと、並びに、呼び出し関係判定モジュールにより判定された呼び出し関係にしたがって、呼び出し順序が複数のオープンAPIに存在しないと判定された場合、複数のオープンAPIに個々に対応する複数のISPサーバへ、呼び出し要求を送信する第2呼び出し実行モジュールを含んでもよい。上記装置は、呼び出し関係にしたがって、呼び出し順序が複数のオープンAPI間に存在すると判定された場合、複数のオープンAPIの呼び出し関係をサービスページに埋め込み、埋め込み処理されたサービスページを、第1呼び出し結果フィードバック部へ提供する呼び出し関係埋め込み部を、更に含む場合もある。上記装置は、第1オープンAPIの次にあり、且つ、第1呼び出し結果フィードバック部から戻されたサービスページに埋め込まれた呼び出し順序にしたがって始動する第2オープンAPIを呼び出すための呼び出し要求を受信する第2受信部と、第2受信部によって受信された呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信する第2ISP呼び出し部と、並びに、第2ISP呼び出し部にしたがって、呼び出し要求に対応する第2オープンAPIに関連するISPサーバから戻されたサービスページを受信し、これを処理して、処理済のサービスページを利用者へ送信するため、サービスページをサードパーティ開発サーバへ送信する第2呼び出し結果フィードバック部を含んでもよい。第2ISP呼び出し部は、第2受信部によって受信された呼び出し要求を、第2オープンAPIに対応するISPサーバに送信する前に、第2オープンAPIを、複数のオープンAPI間の呼び出し関係にしたがって、第1オープンAPIを介し、呼び出すべきかどうかを判定する呼び出し関係解析モジュールと、呼び出し関係解析モジュールの解析結果が第2オープンAPIを呼び出す必要があると判定した場合、呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信する呼び出し要求送信モジュールを含んでもよい。第2呼び出し結果フィードバック部は、第1オープンAPIに対応するISPサーバによって戻される処理済のサービスページを受信する受信モジュールを含むことができる。このサービスページは、第2オープンAPIに対応するISPサーバによって戻されて、第1オープンAPIに対応するISPサーバにより受信され、第1オープンAPIから供給されるサービスページに埋め込まれるサービスページである。更に、第2呼び出し結果フィードバック部は、サービスページを処理し、処理済みのページを利用者に送信するため、受信モジュールが受信したサービスページをサードパーティ開発サーバへ送信するフィードバックモジュールも含んでもよい。上記装置は、取引要求を送信する利用者を認証して、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPを判定することを、第1ISP呼び出し部に命令する認証部を、更に含むこともある。上記認証部は、利用者が設定条件を満たす場合、利用者認証を判定する認証モジュールと、並びに、利用者が承認されたということが認証モジュールにより判定された場合、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPを判定することを、第1ISP呼び出し部に命令する命令モジュールを含むことが可能である。設定条件には、利用者がログインに成功した場合の利用者ログイン証明を作成するステップと、利用者ログイン証明が有効であるかどうかを判定するステップを含んでもよい。利用者ログイン証明は、利用者から取引要求が送信される度に更新できる。第1ISP呼び出し部は、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPの数を判定するISPサーバ判定モジュールと、並びに、ISPサーバ判定モジュールにより判定されたISPが複数のISPを含む場合、ランダムルートアルゴリズムを用いて、複数のISPサーバから1つを見つけ、呼び出し要求を見つけたISPサーバに送信するISPサーバ選択モジュールを含んでもよい。別の態様ではさらに、オープンAPIに基づくネットワーク取引を実現するシステムは、サードパーティ開発サーバと、取引実行サーバと、並びに、ISPサーバとを含むことができる。サードパーティ開発サーバは、利用者からの取引要求にしたがって、オープンAPIの呼び出し要求を、取引実行サーバへ送信して、取引実行サーバから戻されたサービスページを受信し、更に、サービスページを、取引要求に対応するページに埋め込んでから、利用者へ送信できる。取引実行サーバは、呼び出し要求に応答して、呼び出し要求内で要求されるオープンAPIに対応するISPサーバを判定して、判定されたサーバに呼び出し要求を送信し、ISPサーバから戻されたサービスページを受信し、更に、サービスページをサードパーティ開発サーバへ送信することが可能である。ISPサーバは、取引実行サーバから送られた呼び出し要求にしたがって、対応するサービスページを取引実行サーバへ戻すことができる。本開示によれば、データセキュリティの観点から、サービスページを介して、サービスデータをサードパーティ開発サーバへ送るほうが、従来方式のように構造形式データをサードパーティ開発サーバへ直接戻すより安全である。更に、サードパーティ開発サーバとISP間のサーバによって、業務全体の管理機能が実装されるため、サードパーティ開発サーバは、業務ロジックを解析する必要がなく、結果として、管理能力が向上する。業務のデータセキュリティと管理能力の双方を高める手法を提供するため、本開示では、オープンAPIに基づくオンラインビジネスの実行法、システム、並びに、装置を提供している。以下で説明する技術は、方法、または、装置の形態でオンライン取引を実現するのに使用できる。この取引は、本来、オンライン電子商取引で使用されるような業務取引である。好ましい実施形態を、本開示の範囲を制限せずに説明をする目的で図面を参照することで、以下に説明する。図1は、本開示の実施形態に係るオープンAPIに基づくオンラインビジネスを実現する方法を説明している。この方法は、以下の複数のステージを含む。ステージ101:取引実行サーバが、サードパーティ開発サーバから、オープンAPIの呼び出し要求を受信する。この要求は、利用者の取引要求に基づいて送られる。前述のように、実装形態によっては、取引要求は、電子商取引で使用されるような業務取引のための業務要求と関連しており、取引実行サーバは、業務実行サーバと考えることもできる。ステージ102:業務実行サーバは、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPを判定し、判定されたISPサーバへ呼び出し要求を送信する。ステージ103:業務実行サーバは、呼び出し要求にしたがって、ISPサーバから戻されるサービスページを受信する。ステージ104:業務実行サーバは、サービスページをサードパーティ開発サーバへ送信して、サードパーティ開発サーバは、サービスページを処理し、利用者に送る。ステージ104:サードパーティ開発サーバは、サービスページを業務要求に対応するページに埋め込むことにより、サービスページを処理する。前述のオンラインビジネスの実装方法は、業務実行サーバが対応するネットワーク環境に導入されたサーバとなることが可能な種々のネットワーク環境に適用でき、更に、ネットワーク環境に実現される業務を制御、及び、管理するのに使用できる。サードパーティ開発サーバは、ISVサーバである。ある実施形態では、呼び出し要求の中で呼び出し要求されるオープンAPIが、複数のオープンを含む場合、呼び出し要求を判定されたISPサーバへ送る前、すなわち、ステージ102よりも前に、更に、複数のオープンAPIの呼び出し関係を判定することもできる。複数のオープンAPI間の呼び出し関係は、呼び出し順序が、複数のオープンAPIに存在するかどうかを示している。ある実施形態によれば、複数のオープンAPIは、呼び出し順序を持つオープンAPIを含むことができ、更に、他のオープンAPIと呼び出し順序を共有し合う独立したオープンAPIを含むことも可能である。複数のオープンAPIの呼び出し関係を判定した後、図1で示したプロセスのステージ102では、呼び出し要求を、判定したISPサーバへ送信し、図2に示すように、以下に述べる複数のステージを含む。ステージ201:複数のオープンAPIに存在する呼び出し関係にしたがって、呼び出し順序が、複数のオープンAPIに存在するかどうかを判定する。呼び出し順序が存在すれば、このプロセスは、ステージ202へ進み、呼び出し順序が存在しなければ、ステージ203へ進む。ステージ202:呼び出し要求を、複数のオープンAPIの呼び出し順序の先頭にある第1オープンAPIに対応するISPサーバへ送信し、図1のステージ103へ進む。ステージ203:呼び出し要求を、複数のオープンAPIのそれぞれに対応する複数のISPサーバのそれぞれに送信し、図1のステージ103へ進む。一実施形態によれば、呼び出し要求の中で呼び出し要求されるオープンAPIが、複数のオープンAPIを含み、且つ、複数のオープンAPIに呼び出し順序が存在する場合、呼び出し順序の最後のオープンAPIが呼び出されるまで、業務ロジックにしたがって、複数の呼び出しを実行する。呼び出し順序に基づく第1呼び出しの実行後、及び、サービスページのサードパーティ開発サーバへ送信する前、すなわち、図1のステージ104の前に、このプロセスは、さらに複数のオープンAPIの呼び出し順序を、サービスページに埋め込むことができる。上記のステージを実行することによって、オープンAPIの呼び出し順序は、利用者に戻されるサービスページに埋め込まれる。利用者は、次のオープンAPI呼び出しフロー、つまり、以下の説明および図3に示すように、複数のステージを含むプロセスを始動できる。ステージ301:業務実行サーバは、サービスページに埋め込まれた呼び出し順序にしたがって、利用者により始動され、第1オープンAPIの次の第2オープンAPIの呼び出し要求を受信する。ステージ302:呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信する。ステージ303:呼び出し要求にしたがって、第2オープンAPIに対応するISPサーバから戻されたサービスページを受信する。ステップ304:サービスページをサードパーティ開発サーバへ送り、サービスページを処理して、利用者へ送信する。図3で示したプロセスによれば、業務実行サーバは、利用者により始動された次オープンAPI呼び出し要求にしたがって、呼び出し要求のための呼び出しプロセスを実行する。ある実施形態によれば、利用者が次のオープンAPIの呼び出しプロセスを始動した後、種々のオープンAPIに対応するISPサーバ間の相互呼び出しに対応できる。例えば、複数のISPサーバの相互作用を伴う複雑な業務では、第1オープンAPIに対応するISPサーバから提供される業務を呼び出した後、第2オープンAPIに対応するISPサーバから提供される業務も、呼び出す必要となる場合がある。しかし、第2オープンAPIに対応するISPサーバは、特定のISPサーバからのアクセスにしか対応できないことがある。一般に、このISPサーバは、初めて呼び出されるオープンAPIに対応するISPサーバである。このような状況下では、第2オープンAPIに対応するISPサーバから提供される業務を取得するため、第2オープンAPIに対応するISPサーバは、第1オープンAPIに対応するISPサーバを介して、呼び出す必要がある。とりわけ、業務実行サーバは、利用者が始動する次のオープンAPIの呼び出し要求にしたがって、図4に示される呼び出し要求の呼び出しプロセスを実行する。ステップ401:業務実行サーバは、サービスページに埋め込まれた呼び出し順序にしたがって利用者により始動される第1オープンAPIの次の第2オープンAPIの呼び出し要求を受信する。ステージ402:複数のオープンAPIの呼び出し関係にしたがって、第2オープンAPIを、第1オープンAPIによって呼び出す必要があるかどうかを判定する。第2オープンAPIを、第1オープンAPIを介して呼び出す必要がある場合、このプロセスは、ステージ403‐404へ進み、第2オープンAPIを呼び出す必要がなければ、ステージ405‐406へ進む。ステージ402:第1オープンAPIと第2オープンAPIの間で、相互呼び出し関係が存在する場合、第2オープンAPIの呼び出しは、第1呼び出しオープンAPIを介して実行する必要がある。ステージ403:第1オープンAPIに対応するISPサーバを介して、呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信する。ステージ404:第1オープンAPIに対応するISPサーバから戻された処理済サービスページを受信して、ステージ407へ進む。ステージ404:第1オープンAPIに対応するISPサーバは、第2オープンAPIに対応するISPサーバから戻されるサービスページを受信して、受信したサービスページを、このISPサーバのサービスページに埋め込む。ステージ405:呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信する。ステージ406:呼び出し要求にしたがって、第2オープンAPIに対応するISPサーバから戻されたサービスページを受信して、ステージ407へ進む。ステージ407:サービスページをサードパーティ開発サーバへ送信して、サービスページを処理し、利用者へ送る。一実施形態によれば、ISPから戻されたサービスページの業務要求に対応するページに埋め込むことは、サービスページを業務要求に対応するページにIframeインナーフレーム形式で埋め込む処理を含むことができる。Iframe形式で埋め込まれたページは、Iframe要素であり、これは、ページ内のフローティングフレームであると認識できる。1組のフレームは、Iframeのコンテンツへのアクセス権限を提供する。実際の実装では、フレームの組を用いて、Iframe内に含まれる要素を読み書きできる。Iframeは、インナーフレームとしても知られ、ウェブページを既存のウェブページに埋め込む手法である。埋め込まれたウェブページは、既存ウェブページの指定フレーム位置内に表示される。だが、利用者には、表示されているウェブページが、異なる2つのウェブページからのものであるとことが分かってはならない。本開示の実施形態では、Iframeの特徴を用いて、ISPサービスのウェブページを開き、セキュリティ、及び、ユーザエクスペリエンスの質を確保している。本開示の実施形態によれば、業務実行のセキュリティ、及び、管理機能を向上させるため、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPを判定する前、すなわち、図1に示したプロセスのステージ102より前に、このプロセスでは更に、業務要求を送信する利用者を認証して、利用者が認証を通った後に、ステージ102を実行することができる。具体的には、業務要求を送信する利用者の認証は、種々の方法、例えば、ログインインターフェースを利用者へ返し、利用者が登録利用者であれば、ログインインターフェースを介して、登録済のアカウント、及び、パスワードを送信するよう利用者に要求し、一方、利用者が登録済利用者でなければ、まずログインインターフェースを介して登録するよう利用者に要求し、登録情報が確認されたら、利用者のログインを許可することにより実行できる。実際の業務実行の場合、一般に、利用者とネットワークサーバの間に複数の相互作用が伴う。利用者のログインの妥当性を保証するため、本開示の実施形態によれば、利用者のログインの成功後、このプロセスでは、利用者が業務要求を送信する度に更新される利用者のログイン証明を検証することが可能である。ログイン証明が有効であれば、利用者は認証を通過し、無効であれば、利用者の業務要求は拒否される。利用者のログイン証明は、利用者のログインの成功後に作成される。実際の業務実行では、利用者ログイン証明の作成と更新は、以下の通りに実行可能である。一部の実施形態では、業務実行は、一般にブラウザーで送ることができる。業務実行サーバは、利用者ログインを検証した後、ログインのプロセス中に生成される利用者のログイン証明のクッキーを、クッキーの時間情報と併せて、ブラウザーに書き込む。この利用者が、再度アクセスする際例えば、オープンAPIの呼び出し、クッキーの有効性の検証中に、利用者識別情報の有無の検証の他、現在のアクセスとクッキーがブラウザーに書き込まれた最後の時間間隔が所定の時間間隔内にあるかどうかも検証される。すなわち、業務実行サーバは、オープンAPIが呼び出される度に、クッキーを検証し、更新できる。利用者が、長時間オープンAPIを呼び出さない場合、次回、利用者は、業務のセキュリティを向上させるため、再度ログインする必要があるだろう。本開示の実施形態によれば、呼び出し要求の中で呼び出し要求されるオープンAPIに対応する判定されたISPサーバが、複数のISPサーバを含む場合、呼び出し要求を判定された1つ以上のISPサーバへ送る。この呼び出し要求の送信には、判定された複数のISPサーバのうち任意の1つの呼び出し要求の送信を含むことができる。判定された複数のISPサーバの任意の一つに呼び出し要求を送信することは、ランダムルートアルゴリズムによって実装できることが望ましい。すなわち、呼び出し要求は、ランダムルートアルゴリズムにしたがって、判定された複数のISPサーバの任意の一つのISPサーバへ送られる。その間、ISPサーバのハートビート試験が可能であり、ISPのランダムリストは、ISPの状態にしたがって、動的に更新される。例えば、ISPの試験結果が、ISPの異常状態を示していれば、このISPはランダムリストから削除されて、次回の呼び出し要求には、そのサーバに送られることはない。ISPの試験結果が、ISPの正常状態を示していれば、ISPはランダムリストに再度追加され、次回の呼び出し要求には、その対応サーバへ送信される場合がある。ある実施形態では、業務を提供するISPは、HTTPソフトロードを介して、複数のISPサーバから特定できる。HTTPソフトロードは、ミドルウェア構成サーバすなわち、業務実行サーバに基づいて実装できる。ISPサーバはそれぞれ、HTTPサービスを構成サーバに登録する。構成サーバのクライアント側は、ISPサーバに無作為に接続して、構成サーバの登録アドレスに基いて、HTTP要求を送信する。各ISPサービスは、サーバ側ターゲットを介して、アドレス情報を構成サーバに公開し、各クライアント側は、クライアント側ターゲットを介して、構成サーバの必要サービスに加入する。構成サーバは、新規で利用可能な全てのサービスのリストをクライアント側へ送って、クライアント側は、ルートアルゴリズム恐らく、ランダムルートアルゴリズムを介して呼び出すためのサービスアドレスを一つ選択する。とりわけ、構成サーバへ送られるアドレスリストは、文字列で表示可能である。本開示の実施形態によれば、ISPサーバから戻されるサービスページには、場合によっては以下に述べる2つの形式がある。形式1:ISPサーバが、サービスページを戻して、ISVはISPから戻されたサービスページを自身のサービスページに埋め込む。利用者に戻される最終結果のページは、ISPアプリケーション、つまり、開発者によって開発されたソフトウェアに対応するドメイン名に表示される。すなわち、利用者にISPアプリケーションのドメイン名であることがわかるように、ISPアプリケーションのドメイン名は利用者に戻される結果のページに埋め込まれる。形式2:ISPサーバは、取得したページの先頭と末尾間のリンクに応じて、サービスページを表示し、サービスページは細部を整えられ、業務実行サーバに戻す。利用者に戻される最終結果のページは、業務実行サーバに対応するドメイン名として表示される。ページの先頭と末尾間のリンクは、APIの呼び出しによってISVのアプリケーションが入力したパラメータ情報であり、サービスページの細部を整えることには、このパラメータ情報に基づく完成したページを作成することを含む。本開示の実施形態によれば、本開示は、種々の業務要件を満たすことができる。例えば、処理を進める業務プロセスの順序で、業務実行サーバのドメイン名を利用者に表示することが求められる業務要件がある。説明の例として、返済業務の場合、利用者はパスワードを入力するよう求められる。セキュリティの抜け穴及びこれに起因する問題を低減するよう、利用者がパスワードを入力するウィンドーは、業務実行サーバのドメイン名に対応するページの下に表示する必要がある。利用者は、パスワードが第3者によって盗難されないよう、ドメイン名が正規なものであることを確認した後に、パスワードを入力する。本開示の実施形態から提供される技術をより理解できるよう、実施形態の詳細について業務実行を制御する業務実行サーバの特定例と併せて説明する。図5は、本開示の実施形態に係るオンラインビジネスを実現するシステムの相互作用の図である。関連する主な構成要素は、サードパーティ開発サーバISV、業務実行サーバ、複数のISP便宜上、図5では、ISPを3つ示している、及び、認証コンポーネントを含む。ISVから発行される呼び出し要求は、ページAPI呼び出しすなわち、呼び出し関係のある複数のオープンAPIの呼び出し、及び、RESTAPI呼び出しすなわち、他のオープンAPIと呼び出し関係を持たない1つ以上のオープンAPIの呼び出しを含むことができる。業務実行サーバは、業務実行時のセキュリティ及びフロー制御に関与する。図5に示すように、業務実行サーバは、1つ以上のISV、及び、1つ以上のISP間のコネクターとして機能し、オープンAPIを呼び出す呼び出し要求を、ISVから対応のISPへ送信する。APIプロセスは、1つ以上のISPとの相互作用に関する複数の操作を含み、この操作には、例えば、ページ相互作用操作や、通常のRESTAPIの操作が含まれる。同様に、プロセスフローページAPIの処理中、ISPは、他のISPから提供されるサービスを呼び出して、他のISPから供給される1つ以上のページを、自身のページに埋め込み、埋め込んだページを、業務実行サーバがISVへ送信するために、業務実行サーバへ戻す。認証コンポーネントは、種々の認証プロセス、例えば、業務実行サーバによるISVの認証、ISPによる業務実行サーバの認証等に関与する。図6は、オープンAPIに基づく業務の実装の実施形態を説明している。この図では、業務フローが、オープンAPIを3回呼び出す必要があり、ISP2のサービスは、ISP1に応答する2度目の操作の中で呼び出される必要がある。ステージ601:利用者は業務要求をISVへ発行する。このステージでは、利用者から発行される業務要求には、入札要求、返金要求等が含まれる。利用者は、このような業務要求を発行する前に、ログインする必要がある。ステージ602:ISVは、アプリケーションAPPを介して、呼び出し要求をオープンAPIへ発行する。このステージにおいて、呼び出し要求は、APIを呼び出すのに必要なパラメータ、及び、このパラメータに関する署名情報を含む。ステージ603:業務実行サーバは、要求の受信後、利用者ログイン情報及びクッキーを検証する。検証が通れば、プロセスは次のステージに進み、検証が通らなければ、利用者の要求を拒否する図示せず。ステージ604:業務実行サーバは、ISVのアクセス権限を検証する。この検証には、ISVはAPIを呼び出してフローを制御する権限を与えられているかどうかを検証する処理が含まれる。この検証が通れば、プロセスは次ステージに進み、検証が通らなければ、呼び出し要求を拒否する図示せず。ステージ605:業務実行サーバは、呼び出し要求を解析することで、オープンAPIのISP1をサポートしているかどうかを判定して、呼び出し要求をISP1サーバへ送信する。ステージ606:ISP1サーバは、呼び出し要求の受信後、業務実行サーバの署名を検証する。この署名が検証を通ったら、プロセスは次ステージへ進み、検証を通らなければ、エラーメッセージを戻す図示せず。ステージ607:ISP1サーバは、サービスページを業務実行サーバへ戻す。ステージ608:業務実行サーバは、ISP1から戻されたサービスページを埋め込み、ISVのAPPへ戻す。ステージ609:ISVのAPPは、戻されたサービスページを自身のアプリケーションページに埋め込んでから、利用者に表示する。ステージ610:利用者は、戻されたサービスページをクリックして、第2ステップの要求を始動する。この要求は、直接業務実行サーバへ送られる。ステップ611:業務実行サーバは、要求の受信後、利用者を認証する。認証が通ると、プロセスは次のステージに進み、認証が通らなければ、エラーメッセージを戻す図示せず。ステージ612:業務実行サーバは、呼び出し要求の解析時に、要求をISP1サーバへ送る。ステージ613:ISP1サーバは、呼び出し要求の受信後、業務実行サーバの署名を検証する。署名が検証を通れば、処理は次のステップに進み、署名が検証を通らなければ、エラーメッセージを戻す図示せず。ステージ614:ISP1サーバは、要求解析時に、ISP2から提供されるサービスを呼び出す必要があるかどうかを判定し、ISP2を呼び出す要求をISP2サーバへ送る。ステージ615:ISP2は、利用者のクッキーを検証する認証コンポーネントを介して、利用者の識別情報を検証する。この検証が通れば、検証結果をISP2サーバへ戻して、次のステージに進め、検証が通らなければ、利用者ログインページへ移って、利用者にログインし直すよう求める図示せず。ステージ616:ISP2サーバは、サービス要求に応答して、サービスページをISP1サーバへ戻す。ステージ617:ISP1サーバは、ISP2サーバから戻されたサービスページを自身のページに埋め込んで、業務実行サーバへ戻す。ステージ618:業務実行サーバは、ISP1サーバから戻されたサービスページを埋め込んで、ISVのAPPへ送る。ステージ619:ISVのAPPは、戻されたページを自身のサービスページに埋め込んで、ぺージを利用者に表示する。ステージ620:利用者は、戻されたサービスページをクリックして、プロセスの第3操作を始動する。この要求は業務実行サーバへ直接送られる。ステージ621:業務実行サーバは、要求の受信後、利用者を認証する。認証が通ると、プロセスは次のステージに進み、認証が通らなければ、エラーメッセージを戻す図示せず。ステージ622:業務実行サーバは、呼び出し要求の解析時に、要求をISP1サーバへ送る。ステージ623:ISP1サーバは、呼び出し要求の受信後、業務実行サーバの署名を検証する。署名が検証を通れば、プロセスは次のステージへ進み、署名が検証を通らなければ、エラーメッセージを戻す図示せず。ステージ624:ISP1は、自身のサービスページをISVのAPPへ戻す。ステージ625:ISVのAPPは、ISP1サーバから戻された結果情報にしたがって、結果ページを埋め込み、利用者に表示する。上記プロセスでは、業務実行サーバは、遷移、送信、制御、及び、監視機能を提供する。外部ISVが、要求を業務実行サーバへ発行する時、業務実行サーバは、要求の受信に応答して、ISVはページにアクセスする権限をあたえられているかどうかを検証する。この検証結果、ISVがページにアクセスする権限が与えられていれば、業務実行サーバは、要求をISPへ送信し、ISPの署名検証を取得し、ISPから戻されたデータを解析し、このデータを外部ISVへ戻す。ある実施形態では、業務実行サーバとISPの間の呼び出し用に、HTTPを使用できる。すなわち、ISPは、HTTPサービスを提供できる。業務実行サーバは、HTTPクライアント側を介して、ISPページにアクセスして、ISPは、ISPページの内容を、業務実行サーバへ直接出力する。実施形態によっては、以下に述べるように、業務実行サーバは、オープンAPIを呼び出すための呼び出し要求の受信後、複数の判定を実行することができる。業務実行サーバは、ブラウザー内のクッキーが有効であるかどうかを判定できる。業務実行サーバは、署名パラメータが適切であるかどうかを判定できる。署名証明パラメータは、ISV利用者から導入されたデータの検証に使用される。署名パラメータは、ISVがAPIを呼び出す前に、ISVと業務実行サーバの双方が合意したアルゴリズムにしたがって生成され、API呼び出し中に導入される。業務実行サーバは、Appkeyパラメータが適正であるかどうか、Appkeyパラメータが、現ページAPIのアクセス権限を持っているかどうかを判定できる。各APIにアクセスするアプリケーションの証明及びキーは、AppkeyパラメータAppkeyとAPP秘匿情報を含むと呼ばれ、アプリケーションごとのセキュリティを認証、及び、制御するのに使用される。Appkeyパラメータは、ISVがAPIを呼び出す際、導入される。業務実行サーバは、セッションパラメータがクッキーの利用者に対応しているかどうかを判定できる。ISVによって開発されたアプリケーションが、業務実行サーバから供給される情報を取得する際、この情報が、利用者の機密情報であれば、情報取得前に、利用者はログインする必要がある。利用者は、利用者認証下で、データにアクセスできることを示すため、ログイン後、セッションパラメータセッションキーを取得する。この情報は、利用者のログイン時に作成され、API呼び出し中に導入される。業務実行サーバは、タイムスタンプパラメータと現在時間との時間間隔が、30分以内であるかどうかを判定できる。タイムスタンプパラメータは、ISVアプリケーションがAPIにアクセスする回数を制御するのに使用され、業務実行サーバによって作成される。タイムスタンプパラメータは、利用者のブラウザーのクッキーに書き込まれて、利用者は、ページ訪問によってAPIにアクセスする際にタイムスタンプパラメータを取得するため、クッキーを読み取る。業務実行サーバは、セッションパラメータに対応する利用者が、対応するAppkeyパラメータにアクセスする権限を持っているかどうかを判定できる。上記判定のいずれにも該当しなければ、利用者の認証は通らない。更に、上記プロセスにおいて、認証コンポーネントは、ログイン検証に関する統合機能を提供する。ある実施形態では、認証コンポーネントは、独立サーバとして存在できる。つまり、認証コンポーネントを、業務実行サーバやISPのものとは異なるドメイン名を使用できる。クッキーは、業務実行サーバのドメインに書き込まれる。他のISPを認証する際には、クッキーが、業務実行サーバのドメイン内にあるかどうかを判定するだけでよい。他のドメインが、業務実行サーバのドメイン内のクッキーへアクセス可能となるよう、アクセス中に、P3Pヘッダを使用できる。図7では、認証コンポーネントを用いた認証プロセスを示し、このプロセスは、以下に述べる複数のステージを含むことができる。ステージ701:利用者は、ログイン要求をISVへ送信する。ステージ702:ISVは、APPを介して、ログイン要求を業務実行サーバへ送り、自身の認証パラメータ複数を業務実行サーバへ送信する。ステージ703:業務実行サーバは、要求の受信後、ログイン要求を認証コンポーネントへ送る。ステップ704:認証コンポーネントは、業務実行サーバからのログイン要求の受信後、利用者ログインページへ遷移する。利用者は、利用者名とパスワードを入力する。検証が通った場合、処理は次のステージへ進み、検証が通らなければ、処理は、ログインページに戻る図示せず。ステージ705:認証コンポーネントは、クッキーを書き込む要求を業務実行サーバへ発行する。ステップ706:業務実行サーバは、要求受信後、1つ以上の要求パラメータに応じて、セキュリティ検証を実行する。検証が通ると、業務実行サーバは、クッキーを書き込む。ステージ707:業務実行サーバは、クッキーの書き込む結果に対する応答を認証コンポーネントへ戻す。オープンAPIに基づくオンラインビジネスの実装プロセスを、システムとして実装できる。図8で示すように、本開示の実施形態により提供されるオープンAPIに基づくオンラインビジネスの実装システムに対応するネットワーク接続形態を提供している。このシステムは、サードパーティ開発サーバ801、業務実行サーバ802、及び、ISPサーバ803を含むことができる。実施形態によっては、ISPサーバが複数あってもよい。便宜上、図8では、ISPサーバを2つだけ示している。業務実行サーバ802の利用者は、オンラインビジネスを展開、制御できる。具体的には、各サーバは、以下に述べる各機能を実行する。サードパーティ開発サーバ801は、利用者の業務要求にしたがって、オープンAPIを呼び出すための呼び出し要求を、業務実行サーバ802へ送信する。サードパーティ開発サーバ801は、業務実行サーバ802から戻されるサービスページを受信し、このページを、利用者に送信するための業務要求に対応するページに埋め込む。業務実行サーバ802は、サードパーティ開発サーバ801から送られた呼び出し要求にしたがって、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPサーバ803を判定し、判定されたISPサーバ803へ呼び出し要求を送信する。業務実行サーバ802は、ISPサーバ803から戻されたサービスページを受信し、サードパーティ開発サーバ801へ送る。ISPサーバ803は、業務実行サーバ802から送られた呼び出し要求にしたがって、対応するサービスページを業務実行サーバ802へ戻す。オープンAPIに基づくネットワークを実現するプロセスは、装置として実装できる。図9に示すように、上記プロセス、及び、本開示の実施形態に対応するオープンAPIに基づくオンラインビジネスを実現する装置を提供している。この装置は、第1受信部901、第1ISP呼び出し部902、及び、第1呼び出し結果フィードバック部903を含むことができる。第1受信部901は、利用者の業務要求にしたがって、サードパーティ開発サーバから送られたオープンAPIを呼び出す呼び出し要求を受信する。第1ISP呼び出し部902は、第1受信部901によって受信された呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPサーバを判定して、このISPサーバに呼び出し要求を送信する。第1呼び出し結果フィードバック部903は、第1ISP呼び出し部902から送られた呼び出し要求にしたがって、ISPサーバから戻されたサービスページを受信して、このページをサードパーティ開発サーバへ送信する。サードパーティ開発サーバは、サービスページを処理して、処理済のサービスページを利用者へ送信する。サードパーティ開発サーバは、サービスページを業務要求に対応するページに埋め込むことで、サービスページを処理する。図10に示すように、本開示の一実施形態によれば、第1ISP呼び出し部902は、呼び出し関係判定モジュール902A、第1呼び出し実行モジュール902B、及び、第2呼び出し実行モジュール902Cを更に含むことができる。呼び出し関係判定モジュール902Aは、第1受信部901が受信した呼び出し要求の中で呼び出し要求されるAPIが、複数のオープンAPIを含む場合、複数のオープンAPIの呼び出し関係を判定する。第1呼び出し実行モジュール902Bは、呼び出し関係モジュール902Aにより判定された呼び出し関係にしたがって、呼び出し順序が、複数のオープンAPIに存在すると判定された場合、複数のオープンAPIの呼び出し順序の先頭にある第1オープンAPIに対応するISPサーバへ、呼び出し要求を送信する。呼び出し関係判定モジュール902Aによって判定された呼び出し関係にしたがって、呼び出し順序が、複数のオープンAPI間に存在しないと判定された場合、第2呼び出し実行モジュール902Cは、複数のオープンAPIにそれぞれ対応する複数のISPサーバへ、呼び出し要求を送信する。図11に示すように、本開示の実施形態によれば、図9に示した装置は、呼び出し関係埋め込み部904を、更に含んでもよい。呼び出し関係にしたがって、呼び出し順序が、複数のオープンAPIに存在すると判定された場合、呼び出し関係埋め込み部904は、複数のオープンAPIの呼び出し関係をサービスページに埋め込む。呼び出し関係埋め込み部904は、埋め込み処理済のサービスページを、第1呼び出し結果フィードバック部903へ提供する。図12に示すように、本開示の実施形態によれば、図9に示した装置は、第2受信部905、第2ISP呼び出し部906、及び、第2呼び出し結果フィードバック部907を、更に含んでもよい。第2受信部905は、第1オープンAPIの次に、且つ、第1呼び出し結果フィードバック部903によって戻されるサービスページに埋め込まれる呼び出し順序にしたがって始動する第2オープンAPIを呼び出すための呼び出し要求を受信する。第2ISP呼び出し部906は、第2受信部905により受信される呼び出し要求を、第2オープンAPIに対応するISPサーバへ送信する。第2呼び出し結果フィードバック部907は、第2ISP呼び出し部906にしたがって、呼び出し要求に対応する第2オープンAPIに関連するISPサーバから戻されたサービスページを受信して、サードパーティ開発サーバへ送信する。サードパーティ開発サーバは、サービスページを処理して、処理済のサービスページを利用者に送る。図13に示すように、本開示の実施形態によれば、図12に示した装置内の第2ISP呼び出し部906は、呼び出し関係解析モジュール906A、及び、呼び出し要求送信モジュール906Bを、更に含んでもよい。呼び出し関係解析モジュール906Aは、第2受信部905が受信した呼び出し要求を第2オープンAPIに対応するISPサーバへ送信する前に、複数のオープンAPIの呼び出し関係にしたがって、第1オープンAPIを介して、第2オープンAPIを呼び出す必要があるかどうかを判定する。呼び出し関係解析モジュール906Aの解析結果が、第2オープンAPIを呼び出す必要がある場合、呼び出し要求送信モジュール906Bは、呼び出し要求を第2オープンAPIに対応するISPサーバへ送る。したがって、ある実施形態では、図12に示した装置の第2呼び出し結果フィードバック部907は、受信モジュール907A、及び、フィードバックモジュール907Bを、更に含んでもよい。受信モジュール907Aは、第1オープンAPIに対応するISPサーバから戻される処理済のページを受信する。第1オープンAPIに対応するISPサーバは、第2オープンAPIに対応するISPサーバから戻されたサービスページを受信して、自身のサービスページに埋め込み、更に、埋め込み処理したページを受信モジュール907Aへ戻す。フィードバックモジュール907Bは、受信モジュール907Aによって受信されたサービスページをサードパーティ開発サーバへ送り、サービスページを処理して、処理済みのページを利用者へ送る。図14に示すように、本開示の実施形態によれば、図9に示した装置は、認証部908を、更に含んでもよい。認証部908は、業務要求を送信する利用者を認証して、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPを判定するよう、第1ISP呼び出し部902に指示する。図15に示すように、本開示の実施形態によれば、図14に示した装置の認証部908は、認証モジュール908A、及び、命令モジュール908Bを、更に含んでもよい。認証モジュール908Aは、利用者が設定条件を満たす場合、利用者権限を判定する。設定条件には、利用者がログインできたときに利用者ログイン証明を作成するステップと、利用者ログイン証明が有効であるかどうかを判定するステップを含み、利用者ログイン証明は、利用者が業務要求を送る度に更新される。命令モジュール908Bは、利用者には権限があることを、認証モジュール908Aによって判定された場合、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPを判定することを、第1ISP呼び出し部902に対して命令する。図16に示すように、本発明の開示によれば、図9に示した装置の第1ISP呼び出し部902は、ISPサーバ判定モジュール902D、及び、ISPサーバ選択モジュール902Eを、更に含んでもよい。ISPサーバ判定モジュール902Dは、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPの数を判定する。ISPサーバ選択モジュール902Eは、ISPサーバ判定モジュール902Dによって判定されたISPが、複数のISPを含む場合、ランダムルートアルゴリズムを用いて、複数のISPサーバのうちの1つを見つけ、見つけたISPサーバに呼び出し要求を送信する。本開示の実施形態によって提供されるオープンAPIに基づくオンラインビジネスを実現する装置の機能を実装する専用の方法、及び/または、手段の詳細な説明については、上記のプロセスの該当ステージに詳細に説明してきたため、提供していない。本開示の実施形態が提供するオープンAPIに基づくオンラインビジネスを実現する装置は、独立した単独の装置でもよい。種々の用途に、ネットワーク構造の簡略化を考慮して、装置によって実行される機能を、業務実行サーバに統合できる。例えば、装置は、上記機能を実行する部として機能するよう、業務実行サーバに追加することが可能である。その他、本開示の実施形態が提供するオープンAPIに基づくオンラインビジネスを実現する装置は、コンピュータによって実行可能な命令により実装できる。当業者であれば、この装置が前述の機能を備え、且つ、本開示の請求項によって保護される限り、上記モジュールを個別に定義、または、分割できることを理解されよう。本開示を、実施形態の方法、装置システム、及び、コンピュータによって実行可能な命令のフローチャート、及び/または、ブロック図にしたがって説明した。フローチャート、及び/または、ブロック図、及び/または、ブロックの組み合わせは、コンピュータによって実行可能な命令によって実装できることを理解されたい。このコンピュータによって実行可能な命令は、1つ以上の汎用コンピュータ、1つ以上の専用コンピュータ、1つ以上の組み込み式コンピュータ、または、プログラマブルデータ処理装置の1つ以上の他のプロセッサー上で実装可能であり、これによって、ブロック図の1プロセス、または、複数プロセス、及び/または、1ブロック、または、複数ブロックの所定の機能を実装する装置を、コンピュータ、または、命令を実行するためのプログラマブルデータ処理装置の他のプロセッサーによって作成できる。コンピュータによって実行可能な命令は、何らかの方法で、コンピュータ、または、他のプログラマブルデータ処理装置が動作可能な1つ以上のコンピュータ可読記憶媒体内に記憶できる。コンピュータの1つ以上のコンピュータ可読記憶媒体に記憶された命令は、ブロック図に示された1プロセス、または、複数プロセス、及び/または、1ブロック、または、複数ブロックの所定の機能を実装できる。コンピュータにより実行可能な命令は、1つ以上のコンピュータ、または、1つ以上の他のプログラマブルデータ処理装置内に導入可能であり、これによって、上記のプロセスを実装するために、1つ以上のコンピュータ、または、1つ以上の他のプログラマブルデータ処理装置で一連の操作を実行できる。1つ以上のコンピュータ、または、1つ以上の他のプログラマブルデータ処理装置内で実行される命令は、ブロック図に示された1つ、または、複数のプロセス、及び/または、1つ、または、複数のブロックの所定機の能を実装する工程を提供する。本開示から提供される態様の少なくとも1つの使用によるオンラインビジネスを実行する際の方法は、サードパーティ開発サーバから、利用者の業務要求にしたがって、オープンAPIを呼び出す呼び出し要求を受信するステップと、呼び出し要求の中で呼び出し要求されるオープンAPIに対応するISPサーバを判定するステップと、判定されたISPサーバへ呼び出し要求を送信するステップと、呼び出し要求にしたがって、ISPサーバから戻されたサービスページを受信するステップと、サービスページを処理して、処理済のサービスページを利用者へ送信するため、サービスページをサードパーティ開発サーバへ送信するステップを含むことができる。サービスページの処理は、サービスページを、業務要求に対応するページに埋め込む処理を含む。このように、サービスデータを、サービスページを介して、サードパーティ開発サーバに戻すほうが、従来の方法のように構造データを直接サードパーティ開発サーバへ送るよりも、データセキュリティの観点から安全である。その他、サードパーティサーバとISP間のサーバによって、業務の管理機能全てが実装されているため、サードパーティサーバは、業務ロジックを解析する必要がなく、制御能力が向上する。本開示は、限定された数の例示的実施形態を提供している。だが、本開示は、この例に制限されず、本開示の保護の下、当業者によるいかなる変更も考慮されるであろう。