JP2009116865A - 情報提供方法及び広告提供方法 - Google Patents

Abstract

【課題】広告付きのＷｅｂページを生成するために貢献したＷｅｂＡＰＩを明確にし、広告の紹介料を分配可能にする広告提供システム等を提供することを目的とする。
【解決手段】広告仲介サービス１０５が生成したセッションＩＤをＷｅｂサイト１０３、ＷｅｂＡＰＩ１０４、広告仲介サービス１０５の間で引き回しながら処理を行うシステムであって、Ｗｅｂサイト１０３ではＷｅｂＡＰＩ１０４の処理結果及び広告情報のリソースを取得するためのリンク及び広告を選択したときに呼ばれるセッションＩＤをパラメータに持つリンクを含めたＷｅｂページを生成してＷｅｂブラウザ１０２に返し、Ｗｅｂブラウザ１０２が広告情報のリソースを広告仲介サービス１０５に要求すると、広告仲介サービス１０５では広告情報の要求があったことをセッションＩＤと関連付けて記録した後、広告情報のリソースをＷｅｂブラウザ１０２に返すことにより上記課題を解決する。
【選択図】図１

Description

本発明は、情報提供方法及び広告提供方法に関し、特に、インターネット上でソフトウェア機能を提供するＷｅｂＡＰＩを利用して生成された広告付きのＷｅｂページを提供し、広告付きのＷｅｂページを生成するために貢献したＷｅｂＡＰＩを明確にし、広告の紹介料を分配可能にする技術に関する。

インターネット上に公開したＷｅｂサイトの運営者が広告仲介サービスを運営する広告仲介者と契約し、広告仲介サービスが配布する事業者の広告をＷｅｂページ内に掲載し、閲覧者のＷｅｂブラウザに広告を表示した回数や、閲覧者がその広告のリンクを選択して広告に対応する事業者のＷｅｂページに遷移した回数や、その広告を選択して広告に対応する事業者の商品販売ページに遷移し商品を購入した回数や購入額等に応じてＷｅｂサイト運営者に紹介料を与える方法が広く利用されている。

例えば、Ｇｏｏｇｌｅ（登録商標）のＡｄＳｅｎｓｅ（非特許文献１）では、広告を掲載するＷｅｂ運営者を募っている。Ｇｏｏｇｌｅは、Ｗｅｂ運営者のＷｅｂページに広告を掲載してもらい、そのＷｅｂページの閲覧者が広告のリンクをクリックすると、Ｗｅｂ運営者に紹介料を支払う。

従来のＷｅｂサイトに対して広告を掲載する仕組みの概念図を図１１に示す。Ｗｅｂブラウザ１０２からＷｅｂサイト２０１に対してＷｅｂページ要求２１１を行うとＷｅｂサイト２０１は広告付Ｗｅｂページ２１２を提供する。このとき、通常、広告情報リソースの格納元を示すＵＲＬを含んだＨＴＭＬを送信しＷｅｂブラウザではこのＨＴＭＬを受け取ると、広告情報要求２１３を行い広告情報リソースのＵＲＬに対してリソースを要求する。広告情報２１４が返ると、Ｗｅｂブラウザでは広告情報を表示する。広告情報は、通常、人目を引くように画像やアニメーションを用いて表現する。この画像やアニメーションは、閲覧者が選択したときにより詳しい情報を記載したページ（通常は広告を出している事業者のＷｅｂページ）を返すことができるようにリンクとする。

このリンクには紹介者識別情報を埋め込む。Ｗｅｂページの閲覧者がＷｅｂブラウザ上で広告を選択すると、広告選択２１５の通知を広告仲介サービス２０２に送出する。広告仲介サービス２０２がリクエストを受けると、広告に対応する事業者のＷｅｂサイト１０６にリダイレクトし、Ｗｅｂブラウザ１０２に広告に対応するページを表示する。このとき、広告仲介サービス２０２では、広告のリンクに埋め込まれた紹介者情報を利用して紹介者識別情報毎に選択された回数等を集計する。この集計結果に基づき、広告仲介者は紹介料として与える額を決定する。

特許文献１に記載の発明は、アフィリエイト広告を通して商品を購入するなどした場合に、その商品の購入者が紹介料を与える相手を選択する方法について記述している。

特許文献２に記載の発明は、ＧＵＩを持つアプリケーションの一部にＷｅｂブラウザを埋め込み、そこに広告を表示する方法について記述している。このようにすることで、例えば広告を表示している間だけ、アプリケーションの機能を利用可能にするといった制御を実現している。
特開２００７−１８２００号公報 特開２００３−３２３５７１号公報 Ｇｏｏｇｌｅ ＡｄＳｅｎｓｅ ｈｔｔｐｓ：／／ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ／ａｄｓｅｎｓｅ／ｌｏｇｉｎ／ｊａ／ｉｎｄｅｘ．ｈｔｍｌ

インターネット上でソフトウェア機能を提供する形態であるＷｅｂＡＰＩが注目されている。Ｗｅｂアプリケーション開発者は、他者が提供するＷｅｂＡＰＩを組み合わせることで高機能なＷｅｂアプリケーションを安価に実現することが可能となる。

ＷｅｂＡＰＩには、ユーザ認証を行うもの、与えられた文章を構文解析するもの、与えられた画像を加工するもの、地図情報を提供するものなど様々なものがある。ＷｅｂＡＰＩが返す情報は、Ｗｅｂアプリケーション開発者が加工してＷｅｂページに埋め込みＷｅｂブラウザに表示することができる。加工が可能であるため、ＷｅｂＡＰＩの戻り値として広告の情報を一緒に返したとしてもＷｅｂアプリケーションの開発者が排除することが可能であり、ＷｅｂＡＰＩ提供者が広告による紹介料を得ることが難しいという課題がある。

特許文献１では、商品購入者が紹介料を与える相手を選択可能であるが、商品購入者の考えに依存してしまうため、公平に紹介料を得ることが難しい。

また、特許文献２を用いればＷｅｂページではなくコンピュータ上で動作するアプリケーションプログラムを通して広告収入を得る機会を得られるが、アプリケーションはＧＵＩを提供する必要があり、ＧＵＩを持たないＷｅｂＡＰＩに適用することはできない。

上記課題に鑑みて、本発明は、インターネット上でソフトウェア機能を提供するＷｅｂＡＰＩを利用して生成された広告付きのＷｅｂページを提供し、広告付きのＷｅｂページを生成するために貢献したＷｅｂＡＰＩを明確にし、広告の紹介料を分配可能にする広告提供システム及び広告提供方法を提供することを目的とする。

上記目的を達成するため、本発明の情報提供方法は、インターネット上でソフトウェア機能を提供するＷｅｂＡＰＩプログラムと、前記ＷｅｂＡＰＩプログラムを利用するＷｅｂＡＰＩ利用プログラムと、前記ＷｅｂＡＰＩプログラムの呼び出しを制御するＷｅｂＡＰＩ呼び出し制御プログラムとを用いた情報提供方法であって、前記ＷｅｂＡＰＩ利用プログラムが前記ＷｅｂＡＰＩプログラムを呼び出すときに、前記ＷｅｂＡＰＩ呼び出し制御プログラムが発行するキー情報を取得し、前記キー情報を用いて前記ＷｅｂＡＰＩプログラムを呼び出し、前記ＷｅｂＡＰＩプログラムは前記ＷｅｂＡＰＩ利用プログラムから受け取ったキー情報が正しいことを確認し、正しい場合のみ前記ＷｅｂＡＰＩプログラムの実行結果を返すようにＷｅｂＡＰＩ呼び出し制御を行うことを特徴とする。

さらに、本発明の情報提供方法は、前記ＷｅｂＡＰＩ利用プログラムが前記ＷｅｂＡＰＩプログラムを呼び出すたびに、前記ＷｅｂＡＰＩ呼び出し制御プログラムからセッションＩＤを取得し、前記セッションＩＤをキー情報として前記ＷｅｂＡＰＩプログラムを呼び出すＷｅｂＡＰＩ呼び出し制御を行う。

さらに、本発明の情報提供方法は、前記ＷｅｂＡＰＩ利用プログラムは事前に前記ＷｅｂＡＰＩ呼び出し制御プログラムから前記ＷｅｂＡＰＩプログラムを複数回呼び出し可能なキーを取得し、前記キーを用いて前記ＷｅｂＡＰＩプログラムを呼び出すＷｅｂＡＰＩ呼び出し制御を行う。

さらに、本発明の情報提供方法は、前記ＷｅｂＡＰＩプログラムが前記ＷｅｂＡＰＩ呼び出しプログラムから受け取ったキー情報を、前記ＷｅｂＡＰＩ呼び出し制御プログラムに送出し、前記ＷｅｂＡＰＩ呼び出し制御プログラムは受け取ったキー情報が前記ＷｅｂＡＰＩ呼び出し制御プログラムが発行した正しいものであるかどうかを検証し、検証した結果を前記ＷｅｂＡＰＩプログラムに送出するＷｅｂＡＰＩ呼び出し制御を行う。

さらに、本発明の情報提供方法は、前記ＷｅｂＡＰＩプログラムは、前記ＷｅｂＡＰＩ利用プログラムが送出したキー情報、呼び出し元のＷｅｂＡＰＩ利用プログラム及び呼び出し先のＷｅｂＡＰＩプログラムが判断できる情報を、ログに書き出し、定期的にログを前記ＷｅｂＡＰＩ呼び出し制御プログラムに送出し、前記ＷｅｂＡＰＩ呼び出し制御プログラムは前記ログを解析してキー情報が正しいかどうかを検証するＷｅｂＡＰＩ呼び出し制御を行う。

また、本発明の情報提供方法は、インターネット上でソフトウェア機能を提供するＷｅｂＡＰＩプログラムが一つ又は複数のＷｅｂＡＰＩ利用プログラムから利用されている場合に、前記ＷｅｂＡＰＩプログラム又は前記ＷｅｂＡＰＩ利用プログラムが、前記ＷｅｂＡＰＩプログラムの呼び出し状況をＷｅｂＡＰＩ呼び出し制御プログラムに送ることで、ＷｅｂＡＰＩプログラムの使用量を計測する。

さらに、本発明の情報提供方法は、前記ＷｅｂＡＰＩ利用プログラム毎に一意に決めたキー情報を用いて前記ＷｅｂＡＰＩ利用プログラムが前記ＷｅｂＡＰＩプログラムを呼び出し、前記ＷｅｂＡＰＩプログラムは前記キー情報を前記ＷｅｂＡＰＩ呼び出し制御プログラムに送ることでＷｅｂＡＰＩ呼び出し制御プログラムが、呼び出されたＷｅｂＡＰＩプログラムの使用量を計測する。

さらに、本発明の情報提供方法は、前記ＷｅｂＡＰＩ利用プログラムが利用したＷｅｂＡＰＩプログラムをログに残し、又は前記ＷｅｂＡＰＩプログラムが呼び出されたＷｅｂＡＰＩ利用プログラムをログに残し、前記ログを定期的に前記ＷｅｂＡＰＩ呼び出し制御プログラムに送付し、前記ＷｅｂＡＰＩ呼び出し制御プログラムでは前記ログを解析することで呼び出されたＷｅｂＡＰＩプログラムを特定する。

さらに、本発明の情報提供方法は、前記ＷｅｂＡＰＩ利用プログラムのログと前記ＷｅｂＡＰＩプログラムのログの両方を前記ＷｅｂＡＰＩ呼び出し制御プログラムに送り、両方のログを比較し、ＷｅｂＡＰＩ呼び出しに関する両者の不一致を検出し、不正なログを見つける。

さらに、本発明の情報提供方法は、前記ＷｅｂＡＰＩ利用プログラムは前記ＷｅｂＡＰＩプログラムを呼び出す前に前記ＷｅｂＡＰＩ呼び出し制御プログラムが発行するセッションＩＤを取得し、前記ＷｅｂＡＰＩ呼び出し制御プログラムは、前記セッションＩＤを発行したＷｅｂＡＰＩ利用プログラムを記録し、前記ＷｅｂＡＰＩ呼び出しプログラムが前記セッションＩＤを用いて前記ＷｅｂＡＰＩプログラムを呼び出した後、前記ＷｅｂＡＰＩプログラムは前記セッションＩＤを前記ＷｅｂＡＰＩ呼び出し制御プログラムに送ることで、ＷｅｂＡＰＩ呼び出し制御プログラムが呼び出し元であるＷｅｂＡＰＩ利用プログラムと呼び出し先であるＷｅｂＡＰＩプログラムを特定する。

また、本発明の広告提供方法は、インターネット上でＷｅｂページを提供するＷｅｂサイトを用いた広告提供方法であって、前記Ｗｅｂサイトは一つ又は複数のＷｅｂＡＰＩを用いたＷｅｂページであり、前記Ｗｅｂページに広告仲介サービスが提供する広告が掲載されている場合に、Ｗｅｂブラウザで前記Ｗｅｂページに掲載した広告が選択されたときに、前記Ｗｅｂページを構築するためにＷｅｂサイトが利用したＷｅｂＡＰＩを特定し、前記ＷｅｂＡＰＩ提供者に対価を支払う。

さらに、本発明の広告提供方法は、ネットワークで各々接続された、前記Ｗｅｂブラウザを稼動させるＷｅｂブラウザ処理装置と、前記Ｗｅｂサイトを稼動させるＷｅｂサイト処理装置と、前記ＷｅｂＡＰＩを稼動させるＷｅｂＡＰＩ処理装置と、広告仲介サービスを稼動させる広告仲介サービス処理装置とを有し、前記Ｗｅｂブラウザから前記Ｗｅｂページの要求を受けたＷｅｂサイト処理装置が、前記広告仲介サービス処理装置にＷｅｂサイト運営者の紹介者識別情報を送出し、前記広告仲介サービス処理装置からセッションＩＤと広告識別情報を取得し、当該セッションＩＤを引数に含めてＷｅｂＡＰＩを呼び出し、前記ＷｅｂＡＰＩ処理装置が、前記セッションＩＤと前記ＷｅｂＡＰＩ提供者の紹介者識別情報を広告仲介サービス処理装置に送出し、前記広告仲介サービス処理装置は、前記セッションＩＤが正しいものであることを確認し、セッションＩＤとＷｅｂＡＰＩ提供者の紹介者識別情報を記録し、前記広告仲介サービス処理装置で前記セッションＩＤが正しいことが判明した場合には、前記ＷｅｂＡＰＩ処理装置は、前記ＷｅｂＡＰＩを実行して処理結果をＷｅｂサイト処理装置に返し、前記Ｗｅｂサイトでは、処理結果及び広告仲介サービスが保持する広告情報のＵＲＬとセッションＩＤを用いて、広告情報のリソースを取得するためのＵＲＬにパラメータとしてセッションＩＤを含めたＷｅｂページを生成して前記Ｗｅｂブラウザに返し、前記Ｗｅｂブラウザが広告情報のリソースを広告仲介サービス処理装置に要求すると、前記広告仲介サービス処理装置では広告情報の要求があったことをセッションＩＤと関連付けて記録した後、広告情報のリソースを前記Ｗｅｂブラウザに返し、前記ＷｅｂブラウザではＷｅｂサイトが生成したＷｅｂページを表示する。

さらに、本発明の広告提供方法は、ネットワークで各々接続された、前記Ｗｅｂブラウザを稼動させるＷｅｂブラウザ処理装置と、前記Ｗｅｂサイトを稼動させる前記Ｗｅｂサイト処理装置と、前記ＷｅｂＡＰＩを稼動させるＷｅｂＡＰＩ処理装置と、広告仲介サービスを稼動させる広告仲介サービス処理装置とを有し、前記Ｗｅｂブラウザから前記Ｗｅｂページの要求を受けたＷｅｂサイト処理装置が、前記Ｗｅｂブラウザ処理装置にセッションＩＤ要求プログラム、ＷｅｂＡＰＩ呼び出しプログラム及びページ生成プログラムを含むページをＷｅｂブラウザに返し、前記Ｗｅｂブラウザは、返されたページに含まれるプログラムを実行することにより、前記ＷｅｂＡＰＩ提供者の紹介者識別情報を広告仲介サービス処理装置に送出し、前記広告仲介サービス処理装置がリクエストを受けると、セッションＩＤ生成、貢献者記録を実施してセッションＩＤをＷｅｂブラウザに返し、前記Ｗｅｂブラウザは、前記セッションＩＤと前記ＷｅｂＡＰＩ提供者の紹介者識別情報を前記広告仲介サービス処理装置に送出し、前記広告仲介サービス処理装置は、前記セッションＩＤが正しいものであることを確認し、前記セッションＩＤと前記ＷｅｂＡＰＩ提供者の紹介者識別情報を記録し、前記広告仲介サービス処理装置で前記セッションＩＤが正しいことを確認した場合には前記ＷｅｂＡＰＩ処理装置は、前記ＷｅｂＡＰＩを実行して処理結果を前記Ｗｅｂブラウザに送出し、前記Ｗｅｂブラウザは、前記Ｗｅｂページを生成し、広告情報のリソースを前記広告仲介サービス処理装置に要求すると、前記広告仲介サービス処理装置では広告情報の要求があったことを前記セッションＩＤと関連付けて記録した後、前記広告情報のリソースをＷｅｂブラウザに返し、前記Ｗｅｂブラウザでは生成したＷｅｂページを表示する。

さらに、本発明の広告提供方法は、ネットワークで各々接続された、前記Ｗｅｂブラウザを稼動させるＷｅｂブラウザ処理装置と、前記Ｗｅｂサイトを稼動させるＷｅｂサイト処理装置と、前記ＷｅｂＡＰＩを稼動させるＷｅｂＡＰＩ処理装置と、広告仲介サービスを稼動させる広告仲介サービス処理装置とを有し、前記Ｗｅｂブラウザから前記Ｗｅｂページの要求を受けたＷｅｂサイト処理装置が、前記広告仲介サービス処理装置にＷｅｂサイト運営者の紹介者識別情報を送出し、前記広告仲介サービス処理装置からセッションＩＤと広告識別情報を取得し、当該セッションＩＤを引数に含めてＷｅｂＡＰＩ呼び出しを前記広告仲介サービス処理装置に対して行い、前記広告仲介サービス処理装置は、前記セッションＩＤが正しいものであることを確認し、前記セッションＩＤと前記ＷｅｂＡＰＩ提供者の紹介者識別情報を記録し、ＷｅｂＡＰＩ呼び出しを実施し、前記ＷｅｂＡＰＩ処理装置は、前記ＷｅｂＡＰＩを実行して処理結果を広告仲介サービス処理装置に送出し、前記広告仲介サービス処理装置は、処理結果をＷｅｂサイト処理装置へ送出し、前記Ｗｅｂサイトでは、処理結果及び広告仲介サービスが保持する広告情報のＵＲＬとセッションＩＤを用いて、前記広告情報のリソースを取得するためのＵＲＬにパラメータとしてセッションＩＤを含めたＷｅｂページを生成して前記Ｗｅｂブラウザに返し、前記Ｗｅｂブラウザが広告情報のリソースを前記広告仲介サービス処理装置に要求すると、前記広告仲介サービス処理装置では広告情報の要求があったことを前記セッションＩＤと関連付けて記録した後、前記広告情報のリソースをＷｅｂブラウザに返し、前記Ｗｅｂブラウザでは前記Ｗｅｂサイトが生成したＷｅｂページを表示する。

さらに、本発明の広告提供方法は、ネットワークで各々接続された、前記Ｗｅｂブラウザを稼動させるＷｅｂブラウザ処理装置と、前記Ｗｅｂサイトを稼動させるＷｅｂサイト処理装置と、前記ＷｅｂＡＰＩを稼動させるＷｅｂＡＰＩ処理装置と、広告仲介サービスを稼動させる広告仲介サービス処理装置とを有し、前記Ｗｅｂブラウザから前記Ｗｅｂページの要求を受けたＷｅｂサイト処理装置が、前記広告仲介サービス処理装置にＷｅｂＡＰＩ呼び出しを実施し、前記広告仲介サービス処理装置は、セッションＩＤを生成し、前記ＷｅｂＡＰＩ提供者の紹介者識別情報を記録し、呼び出し先のＷｅｂＡＰＩの紹介者識別情報を貢献者としてセッションＩＤと共に記録し、当該セッションＩＤを引数に含めてＷｅｂＡＰＩ呼び出しを前記ＷｅｂＡＰＩ処理装置に対して行い、当該呼び出しを受けたＷｅｂＡＰＩ処理装置は、前記ＷｅｂＡＰＩを実行し、処理結果を前記広告仲介サービス処理装置に送出し、前記広告仲介サービス処理装置は、処理結果及びセッションＩＤをＷｅｂサイト処理装置へ送出し、前記Ｗｅｂサイトでは、処理結果及び広告仲介サービスが保持する広告情報のＵＲＬとセッションＩＤを用いて、前記広告情報のリソースを取得するためのＵＲＬにパラメータとしてセッションＩＤを含めたＷｅｂページを生成してＷｅｂブラウザに返し、前記Ｗｅｂブラウザが広告情報のリソースを広告仲介サービス処理装置に要求すると、前記広告仲介サービス処理装置では広告情報の要求があったことを前記セッションＩＤと関連付けて記録した後、前記広告情報のリソースを前記Ｗｅｂブラウザに返し、前記ＷｅｂブラウザではＷｅｂサイトが生成したＷｅｂページを表示する。

さらに、本発明の広告提供方法は、上記生成されたＷｅｂブラウザに表示した広告を、閲覧者が選択したときに、前記広告仲介サービス処理装置には、前記広告識別情報と前記セッションＩＤが到達し、前記広告仲介サービス処理装置では選択されたこととそのときのセッションＩＤを記録しておき、広告仲介サービスでは広告識別情報に関連する事業者のＷｅｂサイトにリダイレクトすることで広告に対応するＷｅｂページを表示する。

さらに、本発明の広告提供方法は、前記広告仲介サービス処理装置に記録した広告情報の要求があったセッションＩＤを利用し、前記セッションＩＤに関連付いた紹介者識別情報を抽出することで広告を表示したＷｅｂページの生成に貢献したＷｅｂサイト運営者及びＷｅｂＡＰＩ提供者を特定する。

さらに、本発明の広告提供方法は、前記広告仲介サービス処理装置に記録した広告が選択されたときのセッションＩＤを利用し、前記セッションＩＤに関連付いた紹介者識別情報を抽出することで広告が選択されたＷｅｂページの生成に貢献したＷｅｂサイト運営者及びＷｅｂＡＰＩ提供者を特定する。

さらに、本発明の広告提供方法は、セッションＩＤではなく、Ｗｅｂサイトを一意に特定できるキーを用いて、Ｗｅｂサイトが利用したＷｅｂＡＰＩを特定する場合には、前記Ｗｅｂサイトは、予めＷｅｂサイトを一意に識別できるキーを取得し、前記ＷｅｂＡＰＩを呼び出すときは前記キーを一緒に送出し、前記ＷｅｂＡＰＩは前記キーを広告仲介サービスに送出し、前記広告仲介サービスでは前記キーと前記キーを送出したＷｅｂＡＰＩを関連付けて保持し、前記Ｗｅｂサイトは、前記ＷｅｂＡＰＩの処理結果と広告を埋め込んだＷｅｂページをＷｅｂブラウザに送出し、前記Ｗｅｂブラウザから埋め込んだ広告情報の画像等を取得するときに用いるＵＲＬには、前記広告情報の画像等を広告仲介サービスから取得するときに、広告仲介サービスにキーが渡るように、パラメータとしてキーを付加しておき、広告がクリックされたときに遷移するＵＲＬにも、パラメータとしてキーを付加しておき、前記Ｗｅｂブラウザに広告を表示したときや閲覧者が広告をクリックしたときに、広告仲介サービスにキーが送られるようにしておくことで広告の閲覧状況を把握可能とし、その回数に応じてＷｅｂサイト毎の広告への貢献度及び、キーとＷｅｂＡＰＩを関連付けて保持している情報に基づいてＷｅｂサイト毎に利用したＷｅｂＡＰＩとその回数を特定する。

さらに、本発明の広告提供方法は、前記Ｗｅｂサイト、前記ＷｅｂＡＰＩの何れか又は両方が前記ＷｅｂＡＰＩの呼び出しログをセッションＩＤ又はキーと共に保持し、前記ログを定期的に広告仲介サービスに送出し、前記広告仲介サービスでは、前記ログを解析することでＷｅｂサイトが利用したＷｅｂＡＰＩを特定する。

さらに、本発明の広告提供方法は、前記広告仲介サービスは、前記Ｗｅｂサイトと前記ＷｅｂＡＰＩの両方からログを収集し、前記両方のログの内容を比較し、両者に前記ＷｅｂＡＰＩを呼び出した、又は呼び出された記述があったときにその呼び出しが確かであると判断する。

さらに、本発明は、Ｗｅｂブラウザに広告が表示された、又は広告がクリックされたときに発生する対価をＷｅｂＡＰＩ提供者に分配する対価分配方法であって、Ｗｅｂブラウザが広告を表示したＷｅｂページを要求したときに、その要求を受け取ったＷｅｂサイトが利用した一つ又は複数のＷｅｂＡＰＩを特定し、発生した対価をＷｅｂＡＰＩ提供者に分配する。

さらに、本発明は、Ｗｅｂブラウザに広告が表示された、又は広告がクリックされたときに発生する対価を特定期間毎にＷｅｂＡＰＩ提供者に分配する対価分配方法であって、収集した広告に貢献したＷｅｂサイトと前記Ｗｅｂサイトが利用したＷｅｂＡＰＩの記録から、前記特定期間内に前記Ｗｅｂサイトに発生した対価の総量と、前記Ｗｅｂサイトが利用した一つ又は複数のＷｅｂＡＰＩの回数を求め、各ＷｅｂＡＰＩの利用回数に応じて対価の総量をＷｅｂＡＰＩ提供者に分配する。

さらに、本発明の広告提供方法は、利用しているＷｅｂＡＰＩの種類に応じて表示する広告を選択する方法であり、広告仲介サービスは、ＷｅｂＡＰＩとそのＷｅｂＡＰＩに関連する一つ又は複数のキーワードを管理し、広告情報とその広告に関連するキーワードを管理し、広告仲介サービスがＷｅｂブラウザから広告情報の要求を受け取ったときに、セッションＩＤを用いて利用したＷｅｂＡＰＩを特定し、又はキーを用いてＷｅｂサイトが良く利用しているＷｅｂＡＰＩを特定し、そのＷｅｂＡＰＩに関連するキーワードを取得し、そのキーワードを同じキーワードを含む広告情報を選択することで、利用しているＷｅｂＡＰＩの種類に応じた広告をＷｅｂブラウザに提供する。

さらに、本発明の広告提供方法は、前記Ｗｅｂブラウザからの全リクエストに対するＷｅｂＡＰＩの使用量を計測するのではなく、特定期間に発生した前記Ｗｅｂブラウザからのリクエストに対するＷｅｂＡＰＩの使用量を計測し、その計測結果に従って、前記ＷｅｂＡＰＩに分配する広告貢献の対価を決定する。

本発明によれば、インターネット上でソフトウェア機能を提供するＷｅｂＡＰＩを利用して生成された広告付きのＷｅｂページを提供し、広告付きのＷｅｂページを生成するために貢献したＷｅｂＡＰＩを明確にし、広告の紹介料を分配可能にすることができる。

本発明を実施するための最良の形態を説明する。

ＷｅｂＡＰＩ提供者が広告仲介サービスを利用して広告収入を得るための仕組みの概念図を図１に示す。

Ｗｅｂブラウザ１０２は、Ｗｅｂブラウザ処理装置によって、Ｗｅｂサイト１０３は、Ｗｅｂサイト処理装置によって、ＷｅｂＡＰＩ１０４は、ＷｅｂＡＰＩ処理装置によって、広告仲介サービス１０５は、広告仲介サービス処理装置によって、事業者のＷｅｂサイト１０６は、事業者のＷｅｂサイト処理装置によって、それぞれ稼動し、これらはネットワークで接続されている。各処理装置は、コンピュータである。

ＷｅｂＡＰＩ１０４を利用したいＷｅｂサイト運営者は広告仲介者と契約し、紹介者識別情報を取得する。また、紹介料を得たいＷｅｂＡＰＩ提供者も広告仲介者と契約し、紹介者識別情報を取得する。

まず、Ｗｅｂブラウザ１０２からＷｅｂサイト１０３にＷｅｂページ要求１１１を実施する。

Ｗｅｂサイトでは、広告仲介サービス１０５に対してセッションＩＤ要求１１２を実施する。このとき、Ｗｅｂサイト運営者の紹介者識別情報を送出する。広告仲介サービス１０５がセッションＩＤ要求を受け取ると、Ｗｅｂブラウザからのリクエストを特定するためのＩＤであるセッションＩＤ１１３を生成して返す。広告仲介サービス１０５では、生成したセッションＩＤと紹介者識別情報の組み合わせをデータベース等に記録する。

次に、Ｗｅｂサイト１０３ではＡＰＩ呼び出しを実施１１４しＷｅｂＡＰＩ１０４を呼び出す。このとき、広告仲介サービス１０５から受け取ったセッションＩＤを送出する。また、必要に応じて、ＷｅｂＡＰＩの実行に必要なデータもＷｅｂサイト１０３から、ＷｅｂＡＰＩ１０４へ送る。

ＷｅｂＡＰＩ１０４では、受け取ったセッションＩＤが正しいものであるかどうかを確認するために、広告仲介サービス１０５にセッションＩＤ確認１１５を実施し、ＷｅｂＡＰＩ１０４の紹介者識別情報及びセッションＩＤを送出する。

広告仲介サービス１０５では、セッションＩＤを確認し、広告仲介サービス１０５が発行したものであるかどうか、いつ発行したものか（有効期限内であるか）、などの情報に基づき、有効であるかどうかを確認する。有効であった場合、そのセッションＩＤとＷｅｂＡＰＩ提供者の紹介者識別情報の組み合わせをデータベース等に記録する。ＷｅｂＡＰＩ１０４に、セッションＩＤ確認結果１１６として返す。

ＷｅｂＡＰＩ１０４では、セッションＩＤ確認結果が正しいものであればＷｅｂＡＰＩ１０４の機能を実行して呼び出し結果１１７をＷｅｂサイト１０３に返す。

Ｗｅｂサイト１０３では、ＷｅｂＡＰＩ１０４の呼び出し結果１１７を用いてＷｅｂページの元となるＨＴＭＬを構築する。また、広告を表示するために、広告情報リソースのＵＲＬを埋め込む。このＵＲＬには、セッションＩＤや広告を特定するために用いる広告ＩＤを埋め込む。また、その広告をＷｅｂブラウザ１０２で選択するときにより詳細な情報を提供するページに遷移させるが、このときに用いるリンクにもセッションＩＤを埋め込む。

構築した広告付Ｗｅｂページ１１８のＨＴＭＬをＷｅｂブラウザ１０２に送出すると、Ｗｅｂブラウザ１０２ではＨＴＭＬ内に埋め込むリソースをＵＲＬで示される箇所から取得する。広告情報もリソースの一つであり、広告情報要求１１９をＵＲＬに出すことにより取得する。広告情報のリソースは広告仲介サービス１０５が管理しており、このとき利用するリソースのＵＲＬはセッションＩＤを含める。広告仲介サービス１０５ではそのセッションＩＤと広告情報が要求された事実を記録しておくことでどのセッションＩＤの延長で広告情報が要求されたのかを知ることができる。

次に、広告仲介サービス１０５は要求された広告情報１２０をＷｅｂブラウザ１０２に返す。

Ｗｅｂブラウザ１０２では広告情報１２０を受け取ると、それをＷｅｂブラウザ１０２上に表示する。

広告が表示されたら課金する広告仲介サービス１０５であった場合、この表示した回数と表示に関与したＷｅｂサイト運営者、ＷｅｂＡＰＩ提供者を集計することで紹介料を算出する。

Ｗｅｂブラウザ１０２に表示された広告が、閲覧者１０１にクリックされる等して選択された場合に課金する場合は、次の処理も行う。

広告のリンクは、広告仲介サービス１０５へのリンクであり、その広告が選択されたときに同時にセッションＩＤや広告を識別するために用いる広告ＩＤも送出するようにＵＲＬにパラメータとしてセッションＩＤと広告ＩＤを含める。

閲覧者１０１が、広告を選択すると、ＵＲＬに広告選択１２１のリクエストを送出する。

広告仲介サービス１０５では、ＵＲＬに含まれるセッションＩＤと広告が選択された事実をデータベース等に記録し、広告ＩＤを参照して対応する広告に関するより詳しいページ（事業者のＷｅｂサイト１０６）にリダイレクト１２２する。その結果、Ｗｅｂブラウザには事業者のＷｅｂページ１２３が返され、表示される。

広告仲介サービス１０５に記録した広告選択の有無と選択された場合のセッションＩＤに関連付いたＷｅｂサイト運営者、ＷｅｂＡＰＩ提供者を集計し、広告が選択されたことにより得られる紹介料を特定のルールに基づいて貢献者に分配することが可能となる。

さらに具体的な例として、有名人の誕生日を通知するＷｅｂＡＰＩを想定する。ＷｅｂＡＰＩが要求を受信すると、パラメータとして渡された日付が誕生日である有名人の名前を返す。

Ｗｅｂサイトの運営者は、このＷｅｂＡＰＩを利用して、自分のＷｅｂサイトに今日誕生日の有名人の名前を表示する機能を付加したいとする。

これを実現するためのシステム構成図を図２に示す。Ｗｅｂブラウザ１０２が動作するＷｅｂブラウザ処理装置３６０、Ｗｅｂページを返すＷｅｂサイト処理装置３７０、ソフトウェア機能を提供するＷｅｂＡＰＩ処理装置３８０、広告仲介サービス処理装置３００は通信部３０３を備えており、この通信部３０３を介してネットワーク３０４に接続する。

各処理装置は、コンピュータである。

Ｗｅｂブラウザ処理装置３６０は、一般的なＷｅｂブラウザ１０２が稼動する処理装置であり本発明による特段の工夫はないため、詳しい説明は省略する。

Ｗｅｂサイト処理装置３７０は、Ｗｅｂブラウザ１０２からの要求を受けて情報を返す処理装置である。制御部３０１ｂと記憶部３０２ｂを持つ。制御部３０１ｂは送受信部３７４（Ｗｅｂサーバ相当）と、ページ生成部３７３、ＷｅｂＡＰＩ呼び出し部３７２とセッションＩＤ要求部３７１を持つ。本発明とは直接関係ないが一般的にはＷｅｂサイトの記憶部３０２ｂはＨＴＭＬ３７５や画像３７６等を持つ。

ＷｅｂＡＰＩ処理装置３８０は、ＷｅｂＡＰＩが持つ機能を要求されたときに、要求に応じた処理を行い要求者が求める結果を返す。本実施例では、日付毎にその日付が誕生日である有名人の名前を返す。ＷｅｂＡＰＩ処理装置３８０は、制御部３０１ｃと記憶部３０２ｃを持つ。制御部３０１ｃは、送受信部３８１、ＷｅｂＡＰＩ機能部３８２、セッションＩＤ確認要求部３８３を持つ。ＷｅｂＡＰＩ機能部３８２では、日付からその日付が誕生日である有名人の名前を返す。記憶部３０２ｃは、有名人誕生日テーブル３８４を持つ。有名人誕生日テーブル３８４は、日付とその日付が誕生日である有名人の名前を対応付けて格納する。

広告仲介サービス処理装置３００は、制御部３０１ａ、記憶部３０２ａを備える。制御部３０１ａは、セッションＩＤ生成部３１１、セッションＩＤ確認部３１２、貢献者記録部３１３、広告要求元ＩＰ取得部３１４、広告取得部３１５、選択記録部３１６、紹介料算出部３１７、送受信部３１８を持つ。記憶部３０２ａは、Ｗｅｂサイト管理テーブル３２１、ＷｅｂＡＰＩ管理テーブル３２２、セッション管理テーブル３２３、貢献者記録テーブル３２４、広告情報格納テーブル３２５を持つ。

Ｗｅｂサイト管理テーブル３２１は、紹介者識別情報３３１、ＷｅｂサイトＵＲＬ３３２、口座番号３３３等を格納する。

ＷｅｂＡＰＩ管理テーブル３２２は、紹介者識別情報３３５、ＷｅｂＡＰＩのＵＲＬ３３６、口座番号３３７等を格納する。

セッション管理テーブル３２３は、セッションＩＤ３４１、生成時刻３４２、広告要求元ＩＰ３４３、選択有無３４４を格納する。

貢献者記録テーブルは、セッションＩＤ３４５、紹介者識別情報３４６を格納する。

広告情報格納テーブルは、広告ＩＤ３５１、分類３５２、広告画像３５３、事業者ＵＲＬ３５４を格納する。

まず、準備としてＷｅｂＡＰＩ提供者は広告仲介サービスと契約し、ＷｅｂＡＰＩのＵＲＬや紹介料の振込先である口座番号等を登録し、紹介者識別情報の発行を受ける。紹介者識別情報とＷｅｂＡＰＩ提供者が登録した情報は、ＷｅｂＡＰＩ管理テーブル３２２に格納する。

ＷｅｂＡＰＩを利用したいＷｅｂサイト運営者は同様に広告仲介サービスと契約し、ＷｅｂサイトＵＲＬや紹介料の振込先である口座番号等を登録し、紹介者識別情報の発行を受ける。紹介者識別情報とＷｅｂサイト運営者が登録した情報は、Ｗｅｂサイト管理テーブル３２１に格納する。

Ｗｅｂブラウザ１０２からＷｅｂサイトのページを要求したときの処理の流れを図３に示す。処理の流れを通して各部で実施することを説明する。

閲覧者１０１がＷｅｂブラウザ１０２を操作し、ＷｅｂサイトのＷｅｂページ要求４０２を行うとＷｅｂブラウザ１０２はＷｅｂサイトにＷｅｂページ要求４０３を送信する。

Ｗｅｂサイト処理装置３７０では、セッションＩＤ要求部３７１を用いてセッションＩＤ要求４０４を実施する。このとき、パラメータとして紹介者識別情報（ここではｓｈｏｕｋａｉｓｈａ＿ｓｉｔｅ＿０９７８とする）を与える。例えば以下のように広告仲介サービス処理装置３００にＨＴＴＰアクセスすることでセッションＩＤを取得する。
ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ／ｇｅｔ＿ｓｅｓｓｉｏｎ＿ｉｄ？ｓｈｏｕｋａｉｓｈａ＿ｉｄ＝ｓｈｏｕｋａｉｓｈａ＿ｓｉｔｅ＿０９７８

本実施例では、ＨＴＴＰのＧＥＴリクエストで各種処理を要求するが、ＰＯＳＴやＣｏｏｋｉｅを用いたパラメータの受け渡しを行っても良い。

広告仲介サービス処理装置３００では、セッションＩＤ要求４０４を受信すると、セッションＩＤ生成部３１１を用いてセッションＩＤを生成し、セッション管理テーブル３２３にセッションＩＤ３４１として生成したセッションＩＤを、生成時刻として現在時刻を記録する。

セッションＩＤはＷｅｂブラウザ１０２からのＷｅｂページ要求４０３毎に固有のＩＤを生成する。

次に、貢献者記録部３１３を用いて貢献者記録テーブル３２４のセッションＩＤ欄３４５に生成したセッションＩＤを、紹介者識別情報欄３４６にパラメータで渡された紹介者識別情報を記録する。

生成したセッションＩＤは、Ｗｅｂサイト処理装置３７０に返す。

返されたセッションＩＤ４０７の例を以下に示す。これはＸＭＬ形式でセッションＩＤ４０７を返した場合の例である。
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝“１．０” ｅｎｃｏｄｉｎｇ＝“ＵＴＦ−８”？＞
＜ｉｔｅｍ＞
＜ｓｅｓｓｉｏｎ＿ｉｄ＞０１２３４５６７８９ａｂｃｄｅｆ＜／ｓｅｓｓｉｏｎ＿ｉｄ＞
＜／ｉｔｅｍ＞

セッションＩＤだけでなく、広告ＩＤや広告として用いるリンク文字列を返す方法も考えられる。

セッションＩＤと広告ＩＤを返す例：
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝“１．０” ｅｎｃｏｄｉｎｇ＝“ＵＴＦ−８”？＞
＜ｉｔｅｍ＞
＜ｓｅｓｓｉｏｎ＿ｉｄ＞０１２３４５６７８９ａｂｃｄｅｆ＜／ｓｅｓｓｉｏｎ＿ｉｄ＞
＜ｋｏｕｋｏｋｕ＿ｉｄ＞０２５５＜／ｋｏｕｋｏｋｕ＿ｉｄ＞
＜／ｉｔｅｍ＞

セッションＩＤとリンク文字列を返す例：
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝“１．０” ｅｎｃｏｄｉｎｇ＝“ＵＴＦ−８”？＞
＜ｉｔｅｍ＞
＜ｓｅｓｓｉｏｎ＿ｉｄ＞０１２３４５６７８９ａｂｃｄｅｆ＜／ｓｅｓｓｉｏｎ＿ｉｄ＞
＜ｌｉｎｋ＞＆ｌｔ；ａ
ｈｒｅｆ＝“ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ／ｊｕｍｐ？ｋｏｕｋｏｋｕ＿ｉｄ＝０２５５＆ｓｅｓｓｉｏｎ＿ｉｄ＝０１２３４５６７８９ａｂｃｄｅｆ” ＆ｇｔ；＆ｌｔ；ｉｍｇ
ｓｒｃ＝“ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ／ｋｏｕｋｏｋｕ＿ｇａｚｏｕ？ｋｏｕｋｏｋｕ＿ｉｄ＝０２５５＆ｓｅｓｓｉｏｎ＿ｉｄ＝０１２３４５６７８９ａｂｃｄｅｆ” ＆ｇｔ；＆ｌｔ；／ａ＆ｇｔ；＜／ｌｉｎｋ＞
＜／ｉｔｅｍ＞

その他、引数に広告の分類を渡し、広告仲介サービス処理装置では、広告情報格納テーブル３２５の中から分類３５２が引数の分類と一致する広告の広告ＩＤ３５１をランダムに選択しても良い。

次にＷｅｂＡＰＩ呼び出し部３７２を用いてＷｅｂＡＰＩ呼び出し４０８を行う。このとき、パラメータとして本日の日付すなわちＡＰＩの実行に必要なデータとセッションＩＤを与える。以下にＨＴＴＰアクセスにおける呼び出しの例を示す。
ｈｔｔｐ：／／ｗｅｂａｐｉ＿ｙｕｕｍｅｉｊｉｎ＿ｂｉｒｔｈｄａｙ．ｃｏｍ／ｇｅｔ＿ｎａｍｅｓ？ｄａｔｅ＝０８１１＆ｓｅｓｓｉｏｎ＿ｉｄ＝０１２３４５６７８９ａｂｃｄｅｆ

ＷｅｂＡＰＩ処理装置３８０では、上記の要求が到達するとセッションＩＤ確認要求部３８３を通してセッションＩＤ確認４０９を送出し、セッションＩＤが有効であるかどうかを広告仲介サービス処理装置３００に確認する。このとき、事前に取得した紹介者識別情報（ここではｓｈｏｕｋａｉｓｈａ＿ａｐｉ＿０８８８とする）も一緒に送信する。例えば以下のＨＴＴＰアクセスを行うことで実施する。
ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ／ｃｈｅｃｋ？ｓｅｓｓｉｏｎ＿ｉｄ＝０１２３４５６７８９ａｂｃｄｅｆ＆ｓｈｏｕｋａｉｓｈａ＿ｉｄ＝ｓｈｏｕｋａｉｓｈａ＿ａｐｉ＿０８８８

広告仲介サービス処理装置３００では、上記の要求を受け取るとｓｅｓｓｉｏｎ＿ｉｄパラメータで渡されたセッションＩＤが有効であるかどうかを調べる。具体的には、セッションＩＤ確認部３１２を用いてセッションＩＤ確認４１０を実施する。セッションＩＤが、セッション管理テーブル３２３に存在しているかどうか、セッションＩＤの生成時刻３４２から特定時間（例えば５分）以上経過していないか、等に基づいて有効であるかどうかを判定する。

確認した結果、有効であった場合、貢献者記録４１１を実施する。貢献者記録部３１３を用いて貢献者記録テーブル３２４にセッションＩＤ及びｓｈｏｕｋａｉｓｈａ＿ｉｄパラメータで渡されたＷｅｂＡＰＩ提供者の紹介者識別情報を記録する。

セッションＩＤ確認結果４１２をＷｅｂＡＰＩ処理装置３８０に返信する。例えば、以下のようにＸＭＬを用いて返信する方法が考えられる。
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝“１．０” ｅｎｃｏｄｉｎｇ＝“ＵＴＦ−８”？＞
＜ｃｈｅｃｋ＞
＜ｓｅｓｓｉｏｎ＿ｉｄ＞０１２３４５６７８９ａｂｃｄｅｆ＜／ｓｅｓｓｉｏｎ＿ｉｄ＞
＜ｒｅｓｕｌｔ＞ｖａｌｉｄ＜／ｒｅｓｕｌｔ＞
＜／ｃｈｅｃｋ＞

上記では、ｒｅｓｕｌｔタグに確認結果を含み、有効である場合は（例として）ｖａｌｉｄ、無効である場合は（例として）ｉｎｖａｌｉｄを返す。

ＷｅｂＡＰＩ処理装置３８０でセッションＩＤが有効であることが分かったならば、ＷｅｂＡＰＩ機能部３８２でＷｅｂＡＰＩの機能を実行４１３する。具体的には、ｄａｔｅパラメータで受け取った日付が誕生日である有名人を有名人誕生日テーブル３８４から検索して取得する。

取得した有名人のリストは呼び出し結果４１４として返す。例えば、以下のようにＸＭＬを用いて返信する方法が考えられる。
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝“１．０” ｅｎｃｏｄｉｎｇ＝“ＵＴＦ−８”？＞
＜ｒｅｓｐｏｎｓｅ＞
＜ｄａｔｅ＞０８１１＜／ｄａｔｅ＞
＜ｌｉｓｔ＞
＜ｎａｍｅ＞鈴木さん＜／ｎａｍｅ＞
＜ｎａｍｅ＞高野さん＜／ｎａｍｅ＞
＜／ｌｉｓｔ＞
＜／ｒｅｓｐｏｎｓｅ＞

ＷｅｂＡＰＩ処理装置３８０でセッションＩＤが無効であることが分かったならば、無効であることをＷｅｂＡＰＩの呼び出し元に通知する。以下に例を示す。
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝“１．０” ｅｎｃｏｄｉｎｇ＝“ＵＴＦ−８”？＞
＜ｒｅｓｐｏｎｓｅ＞ｉｎｖａｌｉｄ＜／ｒｅｓｐｏｎｓｅ＞

Ｗｅｂサイト処理装置３８０でＷｅｂＡＰＩの実行結果を受け取ると、その実行結果と広告を用いてページ生成４１５する。

生成したページのイメージを図４に示す。ページの上部に今日誕生日の有名人表示領域５０２と広告表示領域５０１を配する。

今日誕生日の有名人表示領域５０２には、ＷｅｂＡＰＩが返した値をＨＴＭＬ化して書き込む。

広告は、以下のようにリンクの形で広告表示領域５０１に埋め込む。
＜ａ ｈｒｅｆ＝“ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ／ｊｕｍｐ？ｋｏｕｋｏｋｕ＿ｉｄ＝０２５５＆ｓｅｓｓｉｏｎ＿ｉｄ＝０１２３４５６７８９ａｂｃｄｅｆｇ”＞＜ｉｍｇ ｓｒｃ＝“ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ
／ｋｏｕｋｏｋｕ＿ｇａｚｏｕ？ｋｏｕｋｏｋｕ＿ｉｄ＝０２５５＆ｓｅｓｓｉｏｎ＿ｉｄ＝０１２３４５６７８９ａｂｃｄｅｆｇ”＞＜／ａ＞

上記のａタグやｉｍｇタグに持つＵＲＬのｓｅｓｓｉｏｎ＿ｉｄパラメータの値（０１２３４５６７８９ａｂｃｄｅｆｇ）は、広告仲介サービス処理装置３００にセッションＩＤ要求４０４を行った結果取得したセッションＩＤ４０７の値である。

ｋｏｕｋｏｋｕ＿ｉｄパラメータとして埋め込む広告ＩＤは事前にＷｅｂサイト運営者が選択した広告の広告ＩＤを利用しても良いし、上記に示すようにセッションＩＤ４０７と一緒に広告ＩＤを返す場合、広告仲介サービス処理装置３００がその広告ＩＤを返す方法も考えられる。また、セッションＩＤ４０７と一緒に広告のリンク全体を広告仲介サービス処理装置３００が返す方法も考えられる。この場合は、広告仲介サービス処理装置３００が返したリンクの文字列をそのままＨＴＭＬ内の広告表示領域５０１に転記することで広告付Ｗｅｂページを実現できる。

Ｗｅｂサイト処理装置３７０では、広告付Ｗｅｂページ４１６をＷｅｂブラウザ１０２に返す。Ｗｅｂブラウザ１０２では返されたＷｅｂページを解析し、足りない情報があればその情報をさらに要求する。

本実施例の場合、Ｗｅｂページとして返したＨＴＭＬの中の広告のリンクには、ｉｍｇタグが存在し、この画像の存在場所であるＵＲＬがｓｒｃ属性として記述してある。Ｗｅｂブラウザ１０２では、ｓｒｃ属性に記述されたＵＲＬにアクセスして広告情報要求４１７を実施する。

広告情報要求４１７を受けた広告仲介サービス処理装置３００では、広告情報要求元ＩＰ記録４１８として、セッション管理テーブル３２３の広告要求元ＩＰに広告情報要求元のＩＰアドレス、つまりＷｅｂブラウザ処理装置３６０のＩＰアドレスを記録した後、広告情報格納テーブル３２５から広告画像３５３を取得し、要求元のＷｅｂブラウザ１０２に返す。

本実施例では、画像を広告情報として返しているが、ＦｌａｓｈやＪａｖａＡｐｐｌｅｔや動画をリンクとして利用する方法も考えられる。また、ＨＴＭＬ内に別のＨＴＭＬを埋め込むｉｆｒａｍｅタグ等を用いることで埋め込む広告をＨＴＭＬとして取得、表示する方法も考えられる。

Ｗｅｂブラウザ１０２は取得した広告情報４２０を用いてＷｅｂページを構築して表示する。

閲覧者１０１は、Ｗｅｂブラウザ１０２に表示されたＷｅｂページを閲覧する。Ｗｅｂページ内に興味のある広告が表示されていた場合、その広告をクリックする等して広告選択４２１を実施する。

広告選択４２１を行うと、Ｗｅｂブラウザ１０２では広告のリンクのＵＲＬに広告選択４２２のリクエストを送信する。本実施例におけるＵＲＬは下記である。
ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ／ｊｕｍｐ？ｋｏｕｋｏｋｕ＿ｉｄ＝０２５５＆ｓｅｓｓｉｏｎ＿ｉｄ＝０１２３４５６７８９ａｂｃｄｅｆｇ

広告仲介サービス処理装置３００では、広告が選択されたことをセッション管理テーブル３２３のセッションＩＤに対応する行の選択有無の欄３４４に有を記述することで記録する。セッション管理テーブル３２３の選択有無の欄３４４の初期値は無とする。

次に、事業者のＷｅｂサイト（ｈｔｔｐ：／／ｊｉｇｙｏｕｓｈａ＿ｐａｇｅ．ｃｏｍ）にリダイレクトする。Ｗｅｂブラウザ１０２に事業者のＷｅｂサイトにリダイレクト４２４を指示し、Ｗｅｂブラウザ１０２は事業者のＷｅｂページ要求４２５を事業者のＷｅｂサイト処理装置４０１に送出することで、事業者のＷｅｂページ４２６を取得する。

リダイレクトとは、上記で示すようにＷｅｂブラウザ１０２にレスポンスを戻し、自動的（閲覧者１０１が関与せず）に、リダイレクト先のＵＲＬ（事業者のＷｅｂサイトのＵＲＬ）にリクエストを送信してリダイレクト先のＷｅｂページを取得して表示する処理を指す。

実現方法として、Ｗｅｂブラウザにリダイレクト（３０１もしくは３０２）のステータスコード及びリダイレクト先のＵＲＬ（ｈｔｔｐ：／／ｊｉｇｙｏｕｓｈａ＿ｐａｇｅ．ｃｏｍ）をレスポンスとして返すことで、Ｗｅｂブラウザが備えている機能を用いて自動的にリダイレクト先のＵＲＬにリクエストを送出し、事業者のＷｅｂサイト処理装置４０１のページを取得する方法や、次のようなタグを含むＨＴＭＬを返すことで、Ｗｅｂブラウザ１０２が備えている機能を用いてｈｔｔｐ：／／ｊｉｇｙｏｕｓｈａ＿ｐａｇｅ．ｃｏｍにリクエストを送出し、事業者のＷｅｂページ４２６を取得する方法が考えられる。
＜ＭＥＴＡ ＨＴＴＰ−ＥＱＵＩＶ＝“ｒｅｆｒｅｓｈ” ｃｏｎｔｅｎｔ＝“０；ＵＲＬ＝ｈｔｔｐ：／／ｊｉｇｙｏｕｓｈａ＿ｐａｇｅ．ｃｏｍ “＞

［紹介料の算出方法］
紹介料の算出方法は様々な方針に基づいて決定される。ここでは、その一例について説明する。ここでの処理は、紹介料算出部３１７で行われる。

本実施例では、広告が一回選択されるたびに広告仲介者が支払う紹介料は３０円の一定であるとする。広告を表示したＷｅｂページの構築時に関与したＷｅｂＡＰＩがあれば、そのＷｅｂＡＰＩ提供者とＷｅｂサイト運営者に同額の紹介料を支払うとする。例えば、広告を選択されたＷｅｂページを構築するのに二つのＷｅｂＡＰＩを利用したとすると、Ｗｅｂサイトの運営者及び二つのＷｅｂＡＰＩの提供者各々に１０円ずつ、計３０円を支払う。

処理の流れを図５に示す。まず、紹介料算出テーブルを作成する６０２。これは、紹介者識別情報と紹介料のペアであり、全ての紹介者識別情報の行を持ち、各行の紹介料の初期値として０を格納したものである。

次に、セッション管理テーブルの生成時刻が紹介料を算出したい期間である行を一行ずつ順に取得する（この取得した行のデータを以下ＳＣと呼ぶ）６０３。例えば、２００７年の８月分の集計をしたい場合、生成時刻が２００７／０８／０１ ００：００：００から２００７／０９／０１ ００：００：００未満の間の行を一行ずつ取得する。

ＳＣの選択有無の欄が有であるかどうかを調べ６０４、有でなければ次の行を取得する。

有であれば、紹介料を計算する。貢献者記録テーブルを参照し、ＳＣのセッションＩＤと同じセッションＩＤを持つ行を全て取得６０５する。

選択毎の紹介料÷取得した行数を計算し、各紹介者に支払う紹介料を求める６０６。

次に、取得した行を一行ずつ順に取得する（この取得した行のデータを以下ＣＣと呼ぶ）６０７。

紹介料算出テーブル内のＣＣの紹介者識別情報に対応する行の紹介料欄の値に各紹介者に支払う紹介料を加算する６０８。

貢献者テーブルから取得した全ての行の処理を終えたかどうかを調べ６０９、終えていなければ次の行について繰り返す。

全ての行の処理を終えていれば、次に、セッション管理テーブルの生成時刻が紹介料を算出したい期間である全ての行の処理を終えたかどうかを調べ６１０、終えていなければ次の行について繰り返す。終えていれば紹介料の算出処理を終了する。

紹介料算出テーブルに紹介者識別情報毎の紹介料が格納されるので、この額を各紹介者識別情報に対応する者に支払う。具体的には、Ｗｅｂサイト管理テーブル３２１やＷｅｂＡＰＩ管理テーブル３２２の口座番号の欄（３３３、３３７）に格納された口座番号を利用してその口座に振り込む方法が考えられる。

本実施例では、閲覧者により広告が選択されると広告仲介者は紹介料を支払うことにしたが、閲覧者のＷｅｂブラウザに広告が表示される毎に紹介料を支払っても良い。その場合は、ＳＣの選択有無の欄が有かどうかを調べるステップ６０４は、ＳＣの広告要求元ＩＰが記録されていることを調べるステップとすれば良い。

［不正の発見方法］
本アイデアが含む、広告仲介サービスが不正に紹介料を支払うリスクを減らす施策について説明する。

（１）
本発明では、ＷｅｂブラウザからＷｅｂサイトへのページを要求する毎に広告仲介サービスがセッションＩＤを発行してこれを管理する。これ以外の方法として、Ｗｅｂサイト運営者又はＷｅｂＡＰＩ提供者の紹介者識別情報を広告仲介サービスに通知することで貢献したことを広告仲介者に知らしめる方法も考えられる。しかし、この方法では実際にＷｅｂＡＰＩが利用されていなくても紹介者識別情報を広告仲介サービスに通知することができるため、不正を働くことができてしまう。本発明のセッションＩＤを用いれば、ＷｅｂＡＰＩから広告仲介サービスにセッションＩＤ確認を行うことで通知されたセッションＩＤが広告仲介サービスにより発行した物であるかどうか、発行してから時間が経過し過ぎていないか等を確認することができるため、不正を困難にすることができる。

（２）
特定のセッションＩＤでＷｅｂＡＰＩが呼び出されたときに複数回、セッションＩＤ確認を行うことで貢献者記録テーブルにＷｅｂＡＰＩ提供者の紹介者識別情報を複数回記録し、貢献度を上げる不正を行うことも想定できる。この場合は、１つのセッションＩＤにつき課金するのは１度だけというルールを設け、広告仲介サービスで貢献者記録テーブルに貢献者を書き込むときに、既に同じセッションＩＤと紹介者識別情報の行が存在しているかどうかを調べ、存在していない場合にのみ貢献者記録テーブルに記録することで防ぐことが可能である。もしくは、貢献者記録テーブルには複数行書き込み、紹介料算出時にセッションＩＤと紹介者識別情報のペアと同じ行が複数回出現しても一回とカウントして処理することで防ぐことが可能である。

（３）
Ｗｅｂサイトの運営者は、ＷｅｂＡＰＩを利用するためにＷｅｂページに広告を掲載する必要がある。しかし、デザイン性を損なう等の理由からＷｅｂＡＰＩは利用したいが広告は掲載したくないＷｅｂサイト運営者もいるかもしれない。本発明を用いれば、広告のリンクをＷｅｂページに記述しなかった場合、Ｗｅｂブラウザから広告情報要求が広告仲介サービスに送信されない。本発明では、広告情報要求を広告仲介サービスが受信すると広告要求元ＩＰをセッション管理テーブルに記録する。そのため、広告のリンクを埋め込んでいないＷｅｂページを提供した場合、広告要求元ＩＰアドレスが記録されない。セッション管理テーブルの広告要求元ＩＰが記録されていない行のセッションＩＤを、貢献者記録テーブルから探し、見つけた最初の行に含まれる紹介者識別情報から広告を表示していないＷｅｂサイト運営者を特定することができる。Ｗｅｂサイト運営者を特定したら、そのＷｅｂサイト運営者に注意を与えたり、利用を停止したりするなどの対処をすることが可能である。

また、広告要求元ＩＰを記録するだけで良いなら、ＷｅｂブラウザからではなくＷｅｂサイト処理装置から広告仲介サービスに広告情報要求を送出することで、セッション管理テーブルの広告要求元ＩＰ欄にＩＰアドレスを記録することが可能である。しかし、この場合、常に同じＩＰアドレスが格納されるか、もしくはいくつかの特定のＩＰアドレスばかりが広告要求元ＩＰ欄に格納されるため、セッション管理テーブルの広告要求元ＩＰ欄を分析することで不正が疑われるＷｅｂサイト運営者を特定することが可能である。

ＪａｖａＳｃｒｉｐｔやＣＳＳを用いればＷｅｂブラウザで広告情報を取得してもＷｅｂブラウザ上では見えないようにすることも可能である。この場合、広告選択率が極端に少なくなることが予想できる。Ｗｅｂサイト管理テーブルやセッション管理テーブル、貢献者記録テーブルを調べ、そのようなＷｅｂサイトを発見したら、直接Ｗｅｂサイトを閲覧し、目視で広告が掲載されているかどうかを確認すれば良い。

具体的には、紹介者管理テーブル内の各紹介者について、貢献者記録テーブルから紹介者に対応する紹介者識別情報のセッションＩＤを全て取得（セッションＩＤ数をＷｅｂページ表示回数とする）し、セッション管理テーブルから取得したセッションＩＤに対応する行で、かつ選択有無が有である行を全て取得（行数を選択回数とする）し、選択回数 ÷ Ｗｅｂページ表示回数が閾値（例えば０．０１）以下であれば目視で確認したりして広告の表示が正しく行われているかどうかを確認する。

実施例１の効果について説明する。ＷｅｂＡＰＩ提供者に広告収入を得る機会を提供することが可能となる。セッションＩＤを広告仲介サービス、ＷｅｂＡＰＩ、Ｗｅｂサイトの３者のやり取り時に引き回すことにより、不正を働くことが困難な仕組みにすることができる。

ここでは、ＷｅｂＡＰＩについて、有名人の誕生日を通知するＷｅｂＡＰＩを想定したが、ＷｅｂＡＰＩには、ユーザ認証を行うもの、与えられた文章を構文解析するもの、与えられた画像を加工するもの、地図情報を提供するものなど様々なものがある。そして、ＷｅｂＡＰＩの実行にデータが必要な場合もあり、この場合、本実施例の日付の代わりに、各ＷｅｂＡＰＩの実行に必要なデータが適用される。以下の実施例でも同様である。

実施例１では、セッションＩＤ要求４０４、ＷｅｂＡＰＩ呼び出し４０８、ページ生成４１５をＷｅｂサイト処理装置３７０で実施したが、ＪａｖａＳｃｒｉｐｔ等のＷｅｂブラウザ１０２で動作するプログラミング言語を用い、Ｗｅｂブラウザ１０２上でこれらの処理を実現しても良い。

この場合、実施例１でＷｅｂサイト処理装置３７０に配していたセッションＩＤ要求部３７１、ＷｅｂＡＰＩ呼び出し部３７２、ページ生成部３７３をＷｅｂブラウザ１０２に配する。

具体的には、Ｗｅｂサイト処理装置３７０では、ＪａｖａＳｃｒｉｐｔ等を用いてセッションＩＤ要求部、ＷｅｂＡＰＩ呼び出し部、ページ生成部を含めたＷｅｂページをＷｅｂブラウザ１０２に送出する。これらの各部は、Ｗｅｂブラウザ１０２で実行する。

処理の流れを図６に示す。

実施例１との変更点を太線で示す。変更点を中心に説明する。Ｗｅｂブラウザ１０２からＷｅｂページ要求４０３を実施すると、Ｗｅｂサイト処理装置３７０は、送受信部３７４で要求を受け付け、セッションＩＤ要求部、ＷｅｂＡＰＩ呼び出し部、ページ生成部を含むページ７０１をＷｅｂブラウザ１０２に返す。

Ｗｅｂブラウザ１０２では、返されたページに含まれるプログラムを実行する。

まず、セッションＩＤ要求部を用い広告仲介サービス処理装置３００にセッションＩＤ要求７０２を行う。パラメータとして紹介者識別情報を送信する。

実施例２では、Ｗｅｂブラウザ１０２に表示したＷｅｂページの取得元（Ｗｅｂサイト処理装置３７０）とセッションＩＤの要求先（広告仲介サービス処理装置３００）のドメインが異なる。現在のＷｅｂブラウザ１０２では、セキュリティ対策のため、Ｗｅｂページの取得元以外のドメインにＪａｖａＳｃｒｉｐｔから直接アクセスすることは通常できない。他ドメインに対してもアクセス可能とするＪＳＯＮＰという方法を用いたセッションＩＤ要求処理について説明する。

Ｗｅｂページには、下記に示すように広告仲介サービス処理装置からＪａｖａＳｃｒｉｐｔを取得するタグを記述する。
＜ｓｃｒｉｐｔ ｓｒｃ＝“ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ／ｇｅｔ＿ｓｅｓｓｉｏｎ＿ｉｄ＿ｊｓｏｎ？ｃａｌｌｂａｃｋ＝ｒｅｃｅｉｖｅＳｅｓｓｉｏｎＩＤ＆ｓｈｏｕｋａｉｓｈａ＿ｉｄ＝ｓｈｏｕｋａｉｓｈａ＿ｓ
ｉｔｅ＿０９７８”＞＜／ｓｃｒｉｐｔ＞

ｃａｌｌｂａｃｋパラメータには、セッションＩＤが取得されたときにＷｅｂブラウザ１０２によって呼び出してもらいたいメソッド名を記述する。また、Ｗｅｂページには下記のように呼び出し先のメソッドを定義しておく必要がある。
＜ｓｃｒｉｐｔ＞
ｆｕｎｃｔｉｏｎ ｒｅｃｅｉｖｅＳｅｓｓｉｏｎＩＤ（ ｄａｔａ）｛
／／ セッションＩＤを取得した後の処理
・・・
｝
＜／ｓｃｒｉｐｔ＞

上記のように広告仲介サービス処理装置３００からＪａｖａＳｃｒｉｐｔを取得するタグを含むＷｅｂページを表示するとＷｅｂブラウザ１０２は広告仲介サービス処理装置３００にＨＴＴＰのＧＥＴリクエストを送出する。

広告仲介サービス処理装置３００がリクエストを受けると、実施例１と同様のセッションＩＤ生成４０５、貢献者記録４０６を実施してレスポンス（セッションＩＤ７０３）を返す。レスポンスは下記のようになる。
ｒｅｃｅｉｖｅＳｅｓｓｉｏｎＩＤ（ ｛ “ｓｅｓｓｉｏｎ＿ｉｄ” ： “０１２３４５６７８９ａｂｃｄｅｆ” ｝ ）；

Ｗｅｂブラウザ１０２がこのレスポンスを受け取ると、上で示したＷｅｂページに含まれるｒｅｃｅｉｖｅＳｅｓｓｉｏｎＩＤを呼び出す。以上のような処理を実施することにより、Ｗｅｂページを取得したドメインとは違うドメインにアクセスすることを可能とする。

実施例１と同様、広告仲介サービス処理装置３００はセッションＩＤだけではなく、広告ＩＤや広告のリンクを返しても良い。

セッションＩＤと広告ＩＤを返す例：
ｒｅｃｅｉｖｅＳｅｓｓｉｏｎＩＤ（ ｛ “ｓｅｓｓｉｏｎ＿ｉｄ” ： “０１２３４５６７８９ａｂｃｄｅｆ”、 “ｋｏｕｋｏｋｕ＿ｉｄ” ： “０２５５”｝ ）；

セッションＩＤとリンク文字列を返す例：
ｒｅｃｅｉｖｅＳｅｓｓｉｏｎＩＤ（ ｛ “ｓｅｓｓｉｏｎ＿ｉｄ” ： “０１２３４５６７８９ａｂｃｄｅｆ”、 “ｌｉｎｋ” ： “＜ａ ｈｒｅｆ＝ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ／ｊｕｍｐ？ｋｏｕｋｏｋｕ＿ｉｄ＝０２５５＆ｓｅｓｓｉｏｎ＿ｉｄ＝０１２３４５６７８９ａｂｃｄｅｆ＞＜ｉｍｇ ｓｒｃ＝“ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ／ｋｏｕｋｏｋｕ＿ｇａｚｏｕ？ｋｏｕｋｏｋｕ＿ｉｄ＝０２５５＆ｓｅｓｓｉｏｎ＿ｉｄ＝０１２３４５６７８９ａｂｃｄｅｆ”＞＜／ａ＞“｝ ）；

次に、Ｗｅｂブラウザ１０２ではＷｅｂＡＰＩ呼び出し部を用いて、ＷｅｂＡＰＩ呼び出し７０４を実施する。パラメータとして、日付とセッションＩＤを渡す。この呼び出しもセッションＩＤ要求７０２と同様、ＪＳＯＮＰを用いて行うが、説明は省略する。ＷｅｂＡＰＩを呼び出した後のＷｅｂＡＰＩ処理装置３８０の処理は実施例１と同じである。

処理を終えると、呼び出し結果７０５をＷｅｂブラウザ１０２に返す。

Ｗｅｂブラウザ１０２では、ページ生成部を用い、広告の貼り付け及びＷｅｂＡＰＩの呼び出し結果の表示などのページ生成７０６を実施する。

Ｗｅｂブラウザ１０２では、生成したＷｅｂページに外部から取得すべきリソースがあった場合、そのリソースを取得する処理を行う。本実施例の場合、広告のリンクが含む画像情報を、広告情報要求４１７を実施して取得する。本処理以降は、実施例１と同様なので説明を省略する。

本実施例では、セッションＩＤ要求、ＷｅｂＡＰＩ呼び出し、ページ生成の処理をＷｅｂブラウザで実施する例を示したが、この中の一部の処理のみをＷｅｂブラウザで実施するようにしても良い。

例えば、Ｗｅｂページ要求を受けたＷｅｂサイト処理装置では、セッションＩＤ要求を行い、取得したセッションＩＤ及びＷｅｂＡＰＩ呼び出し部、ページ生成部を含むＷｅｂページを作成してＷｅｂブラウザに返すと、ＷｅｂブラウザではそのセッションＩＤを利用してＷｅｂＡＰＩ呼び出し、ページ生成を実施するようにしても良い。

実施例２の効果について説明する。Ｗｅｂブラウザ１０２で入力フォームにテキスト文字列入力等による状態変更が発生したときにその状態変更に応じて動的にＷｅｂＡＰＩを呼び出したい場合やＷｅｂページ全体ではなく一部のみ変更したい場合に有効な方式である。例えば、日付の入力フォームを設け、閲覧者１０１がそのフォームに日付を入力したときに即座にＷｅｂＡＰＩの呼び出しを実施し、その日付が誕生日である有名人を取得してＷｅｂページの画面中の今日誕生日の有名人欄５０２のみを書き換えたい場合に有効である。これらは、本実施例では、ＷｅｂブラウザがＷｅｂＡＰＩの呼び出し結果を利用して画面構築を行うから可能となる。

ＷｅｂサイトからＷｅｂＡＰＩを呼び出すときに、直接ＷｅｂＡＰＩ処理装置３８０を呼ぶのではなく、広告仲介サービス処理装置３００を介してＷｅｂＡＰＩを呼ぶ実施例について説明する。

図７に概念図を示す。太線で図１からの変更点を示す。

図１では、ＡＰＩ呼び出し１１４を直接ＷｅｂＡＰＩに対して実施していたが、本実施例では広告仲介サービス８０３を介して実施する。広告仲介サービス８０３では、ＡＰＩ呼び出し８１４を受けると、指定されたＷｅｂＡＰＩ呼び出し８１５を実施して呼び出し結果８１６を取得する。呼び出し結果８１６を取得したら、その呼び出し結果８１６をＷｅｂサイト８０１に返す。

システム構成を図８に示す。広告仲介サービス処理装置９００に新たにＷｅｂＡＰＩ仲介部９０２を設け、ＷｅｂＡＰＩ処理装置９８０からセッションＩＤ確認要求部を削除した構成となる。

シーケンス図を図９に示す。実施例１と差異がある箇所を太線で示した。差異のある箇所を中心に説明する。Ｗｅｂサイト処理装置９８０は、ＷｅｂＡＰＩ呼び出し１００１を広告仲介サービス処理装置９００に対して行う。引数として呼び出し方法、呼び出し先ＵＲＬ、パラメータ、セッションＩＤを渡す。ここで、呼び出し方法とは、 ＨＴＴＰのＧＥＴ、ＰＯＳＴ等である。

例えば、引数が各々（ｇｅｔ、ｈｔｔｐ：／／ｗｅｂａｐｉ＿ｙｕｕｍｅｉｊｉｎ＿ｂｉｒｔｈｄａｙ．ｃｏｍ／ｇｅｔ＿ｎａｍｅｓ、ｄａｔｅ＝０８１１、０１２３４５６７８９ａｂｃｄｅｆ）であった場合、広告仲介サービスには次のようなリクエストを送出する。
ｈｔｔｐ：／／ｋｏｕｋｏｋｕ＿ｃｈｕｕｋａｉ＿ｓｅｒｖｉｃｅ．ｃｏｍ／ｃａｌｌ＿ｗｅｂａｐｉ？ｍｅｔｈｏｄ＝ｇｅｔ＆ｕｒｌ＝ｈｔｔｐ％３Ａ％２Ｆ％２Ｆｗｅｂａｐｉ＿ｙｕｕｍｅｉｊｉｎ＿ｂｉｒｔｈｄａｙ．ｃｏｍ％２Ｆｇｅｔ＿ｎａｍｅｓ＆ｐａｒａｍ＝ｄａｔｅ％３Ｄ０８１１＆ｓｅｓｓｉｏｎ＿ｉｄ＝０１２３４５６７８９ａｂｃｄｅｆ

上記で”％ｘｘ”はＨＴＴＰでパラメータを送付するときに実施するエンコード後の文字列である。

広告仲介サービス処理装置９００では、このリクエストを受けるとｓｅｓｓｉｏｎ＿ｉｄパラメータで受け取ったセッションＩＤに対してセッションＩＤ確認４１０を行う。具体的には、セッションＩＤである０１２３４５６７８９ａｂｃｄｅｆが正しいことを、セッションＩＤ確認部３１２を用いて確認する。不正であれば、セッションＩＤが不正であったことをＷｅｂサイト処理装置３７０に通知する。

セッションＩＤが正しければＷｅｂＡＰＩの紹介者識別情報取得１００２を実施する。ＷｅｂＡＰＩ管理テーブル３２２の中からＷｅｂＡＰＩのＵＲＬが、呼び出し先ＵＲＬと一致する（又はＵＲＬが含むホスト名（ｗｅｂａｐｉ＿ｙｕｕｍｅｉｊｉｎ＿ｂｉｒｔｈｄａｙ．ｃｏｍ）が一致する）行を取得し、その行の紹介者識別情報を取得することで実現できる。

貢献者記録４１１では、取得したＷｅｂＡＰＩの紹介者識別情報とセッションＩＤのペアを、貢献者記録部３１３を用いて貢献者記録テーブル３２４に記録する。

次に、ＷｅｂＡＰＩ呼び出し１００３を実施する。本実施例のリクエストを受け取った場合、ＷｅｂＡＰＩ仲介部９０２では次に示すＵＲＬにＨＴＴＰのＧＥＴリクエストを送出する。実施例１とは違い、ここでセッションＩＤを送出する必要はない。
ｈｔｔｐ：／／ｗｅｂａｐｉ＿ｙｕｕｍｅｉｊｉｎ＿ｂｉｒｔｈｄａｙ．ｃｏｍ／ｇｅｔ＿ｎａｍｅｓ？ｄａｔｅ＝０８１１

ＷｅｂＡＰＩ処理装置９８０でリクエストを受けると、ｄａｔｅパラメータで受け取った日付が誕生日である有名人の一覧をＷｅｂＡＰＩ機能部を実行４１３して取得し、広告仲介サービス処理装置９００に呼び出し結果１００４として返す。

広告仲介サービス処理装置９００は、取得した有名人の一覧をＷｅｂサイト処理装置３２１に返す。

以降の処理は実施例１と同じであるため、説明を省略する。

実施例３の効果について説明する。実施例１では、ＷｅｂＡＰＩにセッションＩＤを受け付けたり、そのセッションＩＤを確認したりする処理を作り込む必要があったが、実施例３ではそのような処理は必要ないため既存のＷｅｂＡＰＩ処理装置を本アイデアの枠組みに組み込む際のコストが少なくて済む。

実施例３では、Ｗｅｂサイト処理装置３７０からセッションＩＤ要求４０４及びＷｅｂＡＰＩ呼び出し１００１を別々に実施した。本実施例では、セッションＩＤ要求とＷｅｂＡＰＩ呼び出しを統合した場合について説明する。

図１０に処理のシーケンスを示す。図９と差異がある箇所を太線で示した。差異のある箇所を中心に説明する。

システム構成は、図８の広告仲介サービス処理装置９００からセッションＩＤ確認部３１２を削除した構成となる。

Ｗｅｂページ要求４０３を受けたＷｅｂサイト処理装置３７０は、まず、ＷｅｂＡＰＩ呼び出し１１０１を実施する。引数として、呼び出し方法、呼び出し先ＵＲＬ、パラメータ、紹介者識別情報を取る。図９では、紹介者識別情報ではなく、セッションＩＤを引数として渡していた。

広告仲介サービス処理装置３００が、ＷｅｂＡＰＩ呼び出し１１０１を受けると、セッションＩＤを生成し、貢献者記録４０６を行う。貢献者記録４０６では引数で渡された紹介者識別情報とセッションＩＤの組み合わせを貢献者記録テーブル３２４に格納する。

次に、ＷｅｂＡＰＩの紹介者識別情報取得１００２を行い、取得したＷｅｂＡＰＩの紹介者識別情報を貢献者記録４１１にて記録する。

ＷｅｂＡＰＩ呼び出し１００３を実施すと、ＷｅｂＡＰＩ処理装置で引数で渡された日付が誕生日である有名人のリストを取得し、呼び出し結果１００４として返す。

ＷｅｂＡＰＩの結果を得たら、呼び出し結果及びセッションＩＤ１１０２をＷｅｂサイトに返す。このとき、呼び出し結果１００４とセッションＩＤに加え、広告ＩＤや広告を表示するためのリンクの文字列を一緒に返しても良い。

実施例４の効果について説明する。図１０の処理では、Ｗｅｂサイト処理装置から広告仲介サービスへの一度のアクセスでセッションＩＤとＷｅｂＡＰＩの呼び出し結果を取得することが可能である。そのため、ネットワークを跨る通信回数を減らすことが可能である。

また、実施例１〜３では、セッションＩＤをまず取得し、同じセッションＩＤを用いて複数のＷｅｂＡＰＩを呼び出すことが可能であった。この場合、セッションＩＤを引き回す処理を実装する必要があった。実施例４では、複数のＷｅｂＡＰＩを呼び出した結果、ＷｅｂＡＰＩの処理結果と、広告のリンクを返すことにすればセッションＩＤを引き回す処理を行わなくても良い。複数のＷｅｂＡＰＩを呼び出したい場合は呼び出し毎に広告を載せることで対応することが可能である。この場合、ＷｅｂＡＰＩと広告が一対一の関係になるため、ＷｅｂＡＰＩ毎に出力したい広告の種類を限定してＷｅｂサイトに表示することが可能となる。

実施例１では、広告がクリックされるなどして広告収入が発生するたびに広告がクリックされたページを構築するのに利用したＷｅｂＡＰＩを特定し、発生した広告収入を分配していた。

本実施例では、Ｗｅｂサイトが呼び出した一つ又は複数のＷｅｂＡＰＩの各使用量を月毎に求め、Ｗｅｂサイトを経由して獲得した紹介料の合計値を、ＷｅｂＡＰＩの使用量の差に応じてＷｅｂＡＰＩ提供者に分配する方法について記述する。

例えば、ＷｅｂサイトＡに貼り付けた広告による今月の収入が５０００円だったとする。ＷｅｂサイトＡではＷｅｂＡＰＩα、ＷｅｂＡＰＩβを利用しており、各々の利用回数が６０００回、４０００回であったとする。これはＷｅｂＡＰＩの全呼び出し回数の６０％と４０％にあたるため、５０００円のうちＷｅｂＡＰＩαには３０００円、ＷｅｂＡＰＩβには２０００円を分配する。本例は一例であり、５０００円のうちの一部をＷｅｂサイトＡに分配したりする方法も考えられる。

図１２に紹介料算出のフローチャートを示す。図２、図８のシステム構成に適用可能である。この紹介料算出処理は広告提供サービスで実施することを想定しているが、Ｗｅｂサイト処理装置でＷｅｂＡＰＩの呼び出し回数をカウントし、Ｗｅｂサイトが広告仲介者から受け取る広告収入を、この紹介料算出処理を用いて行う実施形態も考えられる。

まず、紹介料算出テーブルを作成し、初期化する１２０２。紹介料算出テーブルには、各ＷｅｂＡＰＩの紹介者識別情報と紹介料のペアであり、紹介料の初期値は０である。

次に、Ｗｅｂサイト管理テーブルの行を一行ずつ順に取得する（この取得した行をＷＣと呼ぶ）１２０３。

呼び出し回数格納テーブル（紹介者識別情報と呼び出し回数）を作成し、初期化する１２０４。呼び出し回数の初期値は０である。紹介料合計値を初期化する１２０５。紹介料合計値の初期値は０である。紹介料合計値はステップ１２０３で取得したＷｅｂサイトを経由して発生した紹介料の合計値を格納する。ＷｅｂＡＰＩ呼び出し合計回数を初期化する１２０６。初期値は０である。ＷｅｂＡＰＩ呼び出し合計回数は、ステップ１２０３で取得したＷｅｂサイトが呼び出した全ＷｅｂＡＰＩの呼び出し回数を格納する。

セッション管理テーブルの生成時刻が紹介料を算出したい期間である行を一行ずつ順に取得する（この取得した行のデータをＳＣと呼ぶ）１２０８。貢献者記録テーブルを参照し、ＳＣのセッションＩＤを持つ行を全て取得１２０８する。貢献者記録テーブルから取得した行の中に紹介者識別情報がＷＣの紹介者識別情報と一致する行がある１２０９かを調べ、なければステップ１２０８に戻る。あれば、ＳＣの選択有無の欄が有１２１０であるかを調べ、有であれば紹介料合計値に選択毎の紹介料を加える１２１１。次に、貢献者記録テーブルから取得した行を一行ずつ順に取得する（この取得した行のデータをＣＣと呼ぶ）１２１２。呼び出し回数格納テーブル内のＣＣの紹介者識別情報に対応する行の値に１を加算する１２１３。ＷｅｂＡＰＩ呼び出し合計回数に１を加算する１２１４。貢献者記録テーブルから取得した全ての行の処理を終えた１２１５かを確認し、終えていなければステップ１２１２に戻る。終えていれば、セッション管理テーブルの生成時刻が紹介料を算出したい期間である全ての行の処理を終えた１２１６かを確認し、終えていなければステップ１２０７に戻る。終えていれば、ＷｅｂＡＰＩ毎の紹介料の分配を決める。

呼び出し回数格納テーブルの行を一行ずつ順に取得する（この取得した行をＹＣと呼ぶ）１２１７。紹介料算出テーブルのＹＣの貢献者識別情報の行に、紹介料合計値×ＹＣの呼び出し回数÷ＷｅｂＡＰＩ呼び出し合計回数を計算して格納する１２１８。呼び出し回数格納テーブルの全ての行の処理を終えた１２１９かを確認し、終えていなければステップ１２１７に戻る。終えていれば、Ｗｅｂサイト管理テーブルの全ての行の処理を終えた１２２０かを確認し、終えていなければステップ１２０３に戻り、次のＷｅｂサイトについても同様の処理を実施する。

実施例５では、特定のＷｅｂサイトを経由して得た紹介料を、そのＷｅｂサイトが利用したＷｅｂＡＰＩに、ＷｅｂＡＰＩの利用率に応じて分配する方法について示した。実施例５では、実施例１〜４で示したシステムに適用可能な紹介料の振り分け方法を示したが、利用率に応じた分配を実施する場合、セッションＩＤを利用せずに実現できる。
本実施例ではセッションＩＤを利用しない実現方法について説明する。図１３に概念図を示す。

セッションＩＤではなく、Ｗｅｂサイト毎に事前に決められたキーを用いてＷｅｂＡＰＩ１３０２を利用したＷｅｂサイト１３０１を特定する。キーとして広告仲介者が発行した紹介者識別情報を用いても良い。

システム構成を図１４に示す。図２と異なる点を太線で示す。Ｗｅｂサイト管理テーブル１４１１にキー１４０１を追加し、貢献者記録テーブル１４１３に時刻１４０８、キー１４０４を追加し、広告要求管理テーブル１４１２を追加して広告要求時刻１４０２、キー１４０３、広告要求元ＩＰ１４０９を管理可能とし、広告選択管理テーブル１４１４を追加して、広告選択時刻１４０５、キー１４０６、広告選択元ＩＰ１４０７を管理可能とした。セッション管理テーブル３２３は削除した。

図１３を用いて流れを説明する。Ｗｅｂブラウザ１０２がＷｅｂページ要求１１１をＷｅｂサイト１３０１に送ると、Ｗｅｂサイト１３０１はＡＰＩ呼び出し（キー）１３１１をＷｅｂＡＰＩ１３０２に対して行う。ＷｅｂＡＰＩ１３０２はＷｅｂサイト１３０１が送出したキーが正当なものであることを確認するために、キー確認（紹介者識別情報及びキーを送出）１３１２を実施する。広告仲介サービス１３０３はキーが正しいかどうか（Ｗｅｂサイト管理テーブル１４１１に格納されたキーであるかどうか）を確認し、キーが正当なものであれば、時刻１４０８とキー１４０４とＷｅｂＡＰＩ１３０２の紹介者識別情報３４６を貢献者記録テーブル１４１３に格納する。そして、キー確認結果１３１３をＷｅｂＡＰＩ１３０２に返す。

ＷｅｂＡＰＩ１３０２はキーが正当なものであればＷｅｂＡＰＩの処理を実行し、呼び出し結果１１７をＷｅｂサイト１３０１に返す。Ｗｅｂサイト１３０１では、呼び出し結果及び広告表示のためのＨＴＭＬ等を埋め込んだ広告付Ｗｅｂページ（ＨＴＭＬ）１１８を構築してＷｅｂブラウザ１０２に返す。Ｗｅｂブラウザ１０２では、広告情報を取得するために、広告情報要求（キーを送出）１３１４を広告仲介サービス１３０３に送付する。広告仲介サービス１３０３では、セッション管理テーブル１４１２に、広告要求時刻１４０２、キー１４０３、広告要求元ＩＰ１３４を追加する。そして、広告情報管理テーブル３２５から適切な広告情報１２０を取得し返す。Ｗｅｂブラウザ１０２では取得した広告情報を表示する。

閲覧者１０１が広告を選択すると、広告選択（キーを送出）１２１を広告仲介サービス１３０３に送出する。広告仲介サービス１３０３では、広告選択管理テーブル１４１４に広告選択時刻１４０５、キー１４０６、広告選択元ＩＰ１４０７を追加する。そして、事業者のＷｅｂサイト１０６にリダイレクト１２２する。事業者のＷｅｂサイト１０６では事業者のＷｅｂページ１２３を返し、Ｗｅｂブラウザ１０２はそのＷｅｂページを表示する。

図１５に本実施例における紹介料算出のフローチャートを示す。図１２との差分を中心に説明する。

ステップ１２０１〜１２０６までは図１２と同様である。

次に、ステップ１２０３で取得したＷＣに対応するＷｅｂサイト毎に紹介料合計値を求める。広告選択管理テーブルの広告選択時刻が紹介料を算出したい期間である行を一行ずつ順に取得する（この取得した行をＫＣと呼ぶ）１５０１。ＫＣのキーがＷＣのキーと一致１５０２するなら紹介料合計値に選択毎の紹介料を加える１２１１。広告選択管理テーブルの広告選択時刻が紹介料を算出したい期間である全ての行の処理を終えた１５０３かを確認し、終えていなければステップ１５０１に戻る。終えていればＷＣに対応するＷｅｂサイトの紹介料合計値の算出を終わる。

次に、ＷＣに対応するＷｅｂサイトが利用した一つ又は複数のＷｅｂＡＰＩの呼び出し回数を算出する。貢献者記録テーブルの時刻が紹介料を算出したい期間である行を一行ずつ順位取得する（この取得した行をＣＣと呼ぶ）１５０４。ＣＣのキーがＷＣのキーと一致１５０５するなら呼び出し回数格納テーブル内のＣＣの紹介者識別情報に対応する行の値に１を加算する１２１３。ＷｅｂＡＰＩ呼び出し合計回数に１を加算する１２１４。貢献者記録テーブルの時刻が紹介料を算出したい期間である全ての行の処理を終えた１５０６かを確認し、終えていなければステップ１５０４に戻る。終えていれば図１２と同じである、ステップ１２１７からステップ１２２１までを実行し、紹介料を算出する。

本実施例を用いれば、広告仲介サービス１０５からセッションＩＤを取得する処理が必要なくなり通信回数が減るためＷｅｂブラウザからのリクエスト処理時間が短縮できる効果が期待できる。

なお、本実施例の方式では、Ｗｅｂサイト毎に既存となるキーを利用しているが、これに対して、実施例１〜５では、リクエスト毎に生成するセッションＩＤを用いていたため、ＷｅｂＡＰＩが呼ばれていないにも関わらず不正にキー確認を行い、ＷｅｂＡＰＩが多く呼ばれていると見せかける、という不正を働くことを困難とする利点を有する。

広告仲介サービスにリクエストの都度ＷｅｂＡＰＩの利用状況を通知するのではなく、一ヶ月に一回など定期的に利用状況を送出する実施例を示す。

図１６に概念図を示す。図１ではリクエストの都度、広告仲介サービスにセッションＩＤ確認１１５及びセッションＩＤ確認結果１１６の取得を行っていたが、図１６ではＷｅｂサイト１０３、ＷｅｂＡＰＩ１０４から定期的にログを送出１６１０し、広告仲介サービス１０５ではこれを集計することで貢献したＷｅｂＡＰＩを明確にする。

図１７にシステム構成を示す。太枠で囲んだのが新規に追加した箇所である。

Ｗｅｂサイト処理装置、ＷｅｂＡＰＩ処理装置には、ログ管理部１７０１を配置する。Ｗｅｂサイト処理装置のログ管理部１７０１ｂでは、ＷｅｂＡＰＩを呼び出したことをログ１７０２ｂとして残す。ＷｅｂＡＰＩ処理装置のログ管理部１７０１ｃでは、ＷｅｂＡＰＩが呼び出されたことをログ１７０２ｃに残す。

ログ１７０２の例を図１８に示す。Ｗｅｂサイトのログ１８０１、ＷｅｂＡＰＩのログ１８０２が各々セッションＩＤと呼出時刻、呼出元紹介者識別情報、呼出先紹介者識別情報をログとして記録する。

このログ１７０２は定期的（例えば一ヶ月に一回等）に広告仲介サービス処理装置に送出する。

ログの送出方法として、広告仲介サービス処理装置にログを受け取るためのＷｅｂサーバのようなプログラムを稼動させ、Ｗｅｂサイト処理装置、ＷｅｂＡＰＩ処理装置が定期的にそのサーバにログを送付する方法や、Ｗｅｂサイト処理装置、ＷｅｂＡＰＩ処理装置にＷｅｂサーバのようなサーバプログラムを稼動させ、広告提供サービスは定期的にＷｅｂサイト処理装置、ＷｅｂＡＰＩ処理装置にログ送出要求を行い、Ｗｅｂサイト処理装置、ＷｅｂＡＰＩ処理装置はその要求を受け取ると、ログを送付する、等の方法が考えられる。

広告仲介サービス処理装置では、ログ１７０２を受け取るとログ集計部１７０３を用いて集計する。

図１９にログ集計部１７０３のフローチャートを示す。ここでは、ログの内容を抽出して、貢献者記録テーブル３２４に格納する作業を行う。まず、ＷｅｂＡＰＩのログの全行について一行ずつ順に取得する（取得した行をＬとする）１９０２。Ｌの呼出元紹介者識別情報に対応するＷｅｂサイトのログに、ＬのセッションＩＤ、呼出先紹介者識別情報が一致するログが存在し、お互いの呼出時刻の差が１５秒以内１９０３でないなら不正である可能性があるため貢献者記録テーブル３２４には記録せず、ステップ１９０２に戻る。ステップ１９０２に戻る前に、不正である可能性がある紹介者識別情報を記録しておき、紹介者識別情報に対応するＷｅｂＡＰＩ提供者又はＷｅｂサイト運営者に警告を出したり、ＷｅｂＡＰＩの利用を停止したりするために利用しても良い。

ステップ１９０３における１５秒とは呼出元から呼出先までリクエストが到達する時間の目安であり、この値を超えると不正が発生した可能性があるため無効とする。もちろん１５秒ではない値を利用する、又はこのチェックを実施しなくても良い。

ステップ１９０３が正しいなら、ＬのセッションＩＤと呼出先紹介者識別情報を貢献者記録テーブルに格納する１９０４。

ＷｅｂＡＰＩのログの全行についての処理を終えた１９０５かを確認し、終えていないならばステップ１９０２に戻る。終えていれば、処理を終了する。

本実施例では、Ｗｅｂサイト処理装置とＷｅｂＡＰＩ処理装置の両方からログを収集するため、ＷｅｂＡＰＩが利用されていないのに利用されたと嘘の申告をする等の不正を働くにはＷｅｂサイトとＷｅｂＡＰＩが結託する必要があり、不正を働きづらいという効果が期待できる。もちろん、Ｗｅｂサイト処理装置、又はＷｅｂＡＰＩ処理装置のみからログを収集し、集計しても良い。

また、本実施例ではセッションＩＤを用いたが、実施例６と同じくキーを用いる方法も考えられる。この場合、ログにはセッションＩＤではなく、ＷｅｂＡＰＩのキーを記録する。キーはＷｅｂＡＰＩの紹介者識別情報と同じであっても良い。

キーを用いる場合、図１７における広告仲介サービスの記憶部は、図１４と同様となり、図１９のログ集計部の処理における、ＬのセッションＩＤと呼出先紹介者識別情報を貢献者記録テーブルに格納する処理１９０３を、Ｌのキーと紹介者識別情報、時刻として呼出時刻を記録する処理とする。

本実施例の定期的に集めたログを集計する方法を用いると、各リクエスト毎にセッションＩＤを確認する方法に比べ、性能が向上する。しかし、ログを集計したタイミングでしか不正を見つけられないという欠点もある。

ＷｅｂＡＰＩの種類に応じて広告を変更する方法について記述する。

図２０にシステム構成を示す。太枠で囲んだ部分が新規に追加した箇所である。ＷｅｂＡＰＩ管理テーブル２０１０にキーワード２００１の欄を追加し、広告情報格納テーブル２０２０にもキーワード２００２の欄を追加した。各キーワードの欄には複数のキーワードを登録可能とする。

ＷｅｂＡＰＩ管理テーブル２０１０のキーワード２００１の欄にはＷｅｂＡＰＩ毎にそのＷｅｂＡＰＩに関連するキーワードを登録しておく。例えば、有名人の誕生日を通知するＷｅｂＡＰＩであった場合、キーワードとして「有名人」、「誕生日」を登録することが考えられる。

広告情報格納テーブル２０２０のキーワード２００２の欄には広告毎にその広告に関連するキーワードを登録しておく。例えば、花屋の広告で合った場合、キーワードとして「花」、「プレゼント」、「誕生日」を登録することが考えられる。

例えば、図１における広告情報要求（セッションＩＤを送出）１１９を広告仲介サービス１０６が受け取ると貢献者記録テーブル３２３から受け取ったセッションＩＤと一致するセッションＩＤを含む行を探し、その行に含まれる紹介者識別情報３４６を求め、ＷｅｂＡＰＩ管理テーブル２０１０からその紹介者識別情報を含む行のキーワード２００１（複数）を抽出する。次に、広告情報格納テーブル２０２０から取得したキーワードの何れかを含む広告を探し、見つけた行を広告情報１２０としてＷｅｂブラウザに返す。複数の行を見つけた場合は最も多くのキーワードがマッチするものを採用したり、ランダムで選択したりする。

上記では、セッションＩＤに基づいてリクエストのたびに広告を探す処理を実施したが、Ｗｅｂサイト管理テーブルに利用するＷｅｂＡＰＩの欄又はＷｅｂＡＰＩのキーワードの欄を設け、予めＷｅｂサイトが利用するＷｅｂＡＰＩ又は利用するＷｅｂＡＰＩのキーワードを登録しておく方法も考えられる。この方法は、キーを利用する実施形態やログを利用する実施形態でも適用可能である。

これまでの実施例ではＷｅｂＡＰＩの利用状況の全てを広告仲介サービスで集計していた。全ての利用状況を集計するのではなく、特定の期間（毎月の最初の週だけ、毎週水曜日だけ、毎日１０時−１２時の間だけ、または不定期等）だけ利用状況を集計することで集計の負荷を軽減する方法も考えられる。

これまで、広告収入を得ることが難しかったＷｅｂＡＰＩの提供者に、本アイデアを用いることにより広告収入を得る機会を提供することが可能となる。また、Ｗｅｂサイト運営者は、有料のＷｅｂＡＰＩを利用したい場合、その料金を支払うだけの効果があるかどうかを慎重に判断する必要があるが、本アイデアにより提供されたＷｅｂＡＰＩを利用する場合は広告を載せるだけで良いため導入し易い。以上のように本アイデアはＷｅｂＡＰＩの利用促進やＷｅｂＡＰＩ提供者の裾野を広げる効果があると考える。

以上、本発明には、ＷｅｂＡＰＩ提供者、Ｗｅｂサイト運営者、広告仲介者の３者が登場する。本発明が、各々にもたらす効果について下記に示す。

・ＷｅｂＡＰＩ提供者
現状、無料で公開されることが多いＷｅｂＡＰＩであるが、本発明を用いることによりＷｅｂＡＰＩを利用したサイトから広告による紹介料を取得することができる。

・Ｗｅｂサイト運営者
ＷｅｂＡＰＩを利用して高機能なサイトを容易に構築することができる。現状、ＷｅｂＡＰＩの一部は、そのＷｅｂＡＰＩを利用したいＷｅｂサイト運営者と例えば月？円、１リクエスト？円などの契約をして利用されるが、本発明を用いればＷｅｂサイトに掲載した広告を閲覧した量に応じてＷｅｂＡＰＩ提供者に紹介料が入る仕組みであるため、Ｗｅｂサイト運営者はＷｅｂサイトに広告を掲載するだけでＷｅｂＡＰＩを利用することができる。
紹介料の分配方法として以下二案が考えられる。
ＷｅｂＡＰＩを利用したいＷｅｂサイト運営者は、ＷｅｂＡＰＩ提供者が指定する方法で広告を掲載する必要があり、その広告の紹介料はＷｅｂＡＰＩ提供者のみに入る。
ＷｅｂＡＰＩを利用したいＷｅｂサイト運営者は、ＷｅｂＡＰＩ提供者が指定する方法で広告を掲載する必要があり、その広告の紹介料はＷｅｂＡＰＩ提供者とＷｅｂサイト運営者の双方に入る。
後者の場合、ＷｅｂＡＰＩを利用したサイトの閲覧が増加し、広告閲覧もこれに伴って増加すれば紹介料を多く得ることができる。

・広告仲介者
広告仲介者は、広告を展開したい事業者と、Ｗｅｂサイトに広告を掲載することで広告収入を得たいＷｅｂサイト運営者の仲介を行う者である。広告を展開したい事業者が支払う料金と、Ｗｅｂサイト運営者やＷｅｂＡＰＩ提供者に支払う紹介料の差分が広告仲介者の利益となる。広告を展開したい事業者が支払う料金は、一回閲覧される毎の料金を設定することが多い。ＷｅｂＡＰＩにより、高機能で魅力的な広告を掲載したＷｅｂサイトが増加することにより、広告が閲覧される機会を増やすことができる。その結果、広告を展開したい事業者の増加が見込め、広告仲介者の利益増加を狙うことができる。

実施例１の概念図を示す。 実施例１のシステム構成図を示す。 実施例１のシーケンス図を示す。 Ｗｅｂサイトの提供するＷｅｂページのイメージ例を示す。 紹介料算出の一実施形態であるフローチャートを示す。 実施例２のシーケンス図を示す。 実施例３の概念図を示す。 実施例３のシステム構成図を示す。 実施例３のシーケンス図を示す。 実施例４のシーケンス図を示す。 従来技術における概念図を示す。 実施例５の紹介料算出のフローチャートを示す。 実施例６の概念図を示す。 実施例６のシステム構成図を示す。 実施例６の紹介料算出のフローチャートを示す。 実施例７における概念図を示す。 実施例７のシステム構成図を示す。 実施例７のログの例を示す。 実施例７のログ集計部のフローチャートを示す。 実施例８のシステム構成を示す。

符号の説明

１０１ 閲覧者
１０２ Ｗｅｂブラウザ
１０３ Ｗｅｂサイト
１０４ ＷｅｂＡＰＩ
１０５ 広告仲介サービス
１０６ 事業者のＷｅｂサイト
２０１ Ｗｅｂサイト
２０２ 広告仲介サービス
３００ 広告仲介サービス処理装置
３０１ 制御部
３０２ 記憶部
３０３ 通信部
３０４ ネットワーク
３１１ セッションＩＤ生成部
３１２ セッションＩＤ確認部
３１３ 貢献者記録部
３１４ 広告要求元ＩＰ取得部
３１５ 広告取得部
３１６ 選択記録部
３１７ 紹介料算出部
３１８ 送受信部
３２１ Ｗｅｂサイト管理テーブル
３２２ ＷｅｂＡＰＩ管理テーブル
３２３ セッション管理テーブル
３２４ 貢献者記録テーブル
３２５ 広告情報格納テーブル
３３１ 紹介者識別情報の欄
３３２ ＷｅｂサイトＵＲＬの欄
３３３ 口座番号の欄
３３５ 紹介者識別情報の欄
３３６ ＷｅｂＡＰＩのＵＲＬの欄
３３７ 口座番号の欄
３４１ セッションＩＤの欄
３４２ 生成時刻の欄
３４３ 広告要求元ＩＰの欄
３４４ 選択有無の欄
３４５ セッションＩＤの欄
３４６ 紹介者識別情報の欄
３５１ 広告ＩＤの欄
３５２ 分類の欄
３５３ 広告画像の欄
３５４ 事業者ＵＲＬの欄
３６０ Ｗｅｂブラウザ
３７０ Ｗｅｂサイト処理装置
３７１ セッションＩＤ要求部
３７２ ＷｅｂＡＰＩ呼び出し部
３７３ ページ生成部
３７４ 送受信部
３７５ ＨＴＭＬ
３７６ 画像
３８０ ＷｅｂＡＰＩ処理装置
３８１ 送受信部
３８２ ＷｅｂＡＰＩ機能部
３８３ セッションＩＤ確認要求部
３８４ 有名人誕生日テーブル
４０１ 事業者のＷｅｂサイト処理装置
５００ Ｗｅｂブラウザ画面
５０１ 広告表示領域
５０２ 今日誕生日の有名人表示領域
８０１ Ｗｅｂサイト
８０２ ＷｅｂＡＰＩ
８０３ 広告仲介サービス
９００ 広告仲介サービス処理装置
９０１ 制御部
９０２ ＷｅｂＡＰＩ仲介部
１４０１ キーの欄
１４０２ 広告要求時刻の欄
１４０３ キーの欄
１４０４ キーの欄
１４０５ 広告選択時刻の欄
１４０６ キーの欄
１４０７ 広告選択元ＩＰの欄
１４０８ 時刻の欄
１７０１ ログ管理部
１７０２ ログ
１７０３ ログ集計部
２００１ キーワードの欄
２００２ キーワードの欄

Claims (25)

1. インターネット上でソフトウェア機能を提供するＷｅｂＡＰＩプログラムと、前記ＷｅｂＡＰＩプログラムを利用するＷｅｂＡＰＩ利用プログラムと、前記ＷｅｂＡＰＩプログラムの呼び出しを制御するＷｅｂＡＰＩ呼び出し制御プログラムとを用いた情報提供方法であって、
   前記ＷｅｂＡＰＩ利用プログラムが前記ＷｅｂＡＰＩプログラムを呼び出すときに、前記ＷｅｂＡＰＩ呼び出し制御プログラムが発行するキー情報を取得し、前記キー情報を用いて前記ＷｅｂＡＰＩプログラムを呼び出し、前記ＷｅｂＡＰＩプログラムは前記ＷｅｂＡＰＩ利用プログラムから受け取ったキー情報が正しいことを確認し、正しい場合のみ前記ＷｅｂＡＰＩプログラムの実行結果を返すようにＷｅｂＡＰＩ呼び出し制御を行うことを特徴とする情報提供方法。
2. 請求項１において、前記ＷｅｂＡＰＩ利用プログラムが前記ＷｅｂＡＰＩプログラムを呼び出すたびに、前記ＷｅｂＡＰＩ呼び出し制御プログラムからセッションＩＤを取得し、前記セッションＩＤをキー情報として前記ＷｅｂＡＰＩプログラムを呼び出すＷｅｂＡＰＩ呼び出し制御を行う情報提供方法。
3. 請求項１において、前記ＷｅｂＡＰＩ利用プログラムは事前に前記ＷｅｂＡＰＩ呼び出し制御プログラムから前記ＷｅｂＡＰＩプログラムを複数回呼び出し可能なキーを取得し、前記キーを用いて前記ＷｅｂＡＰＩプログラムを呼び出すＷｅｂＡＰＩ呼び出し制御を行う情報提供方法。
4. 請求項１において、前記ＷｅｂＡＰＩプログラムが前記ＷｅｂＡＰＩ呼び出しプログラムから受け取ったキー情報を、前記ＷｅｂＡＰＩ呼び出し制御プログラムに送出し、前記ＷｅｂＡＰＩ呼び出し制御プログラムは受け取ったキー情報が前記ＷｅｂＡＰＩ呼び出し制御プログラムが発行した正しいものであるかどうかを検証し、検証した結果を前記ＷｅｂＡＰＩプログラムに送出するＷｅｂＡＰＩ呼び出し制御を行う情報提供方法。
5. 請求項１において、前記ＷｅｂＡＰＩプログラムは、前記ＷｅｂＡＰＩ利用プログラムが送出したキー情報、呼び出し元のＷｅｂＡＰＩ利用プログラム及び呼び出し先のＷｅｂＡＰＩプログラムが判断できる情報を、ログに書き出し、定期的にログを前記ＷｅｂＡＰＩ呼び出し制御プログラムに送出し、前記ＷｅｂＡＰＩ呼び出し制御プログラムは前記ログを解析してキー情報が正しいかどうかを検証するＷｅｂＡＰＩ呼び出し制御を行う情報提供方法。
6. インターネット上でソフトウェア機能を提供するＷｅｂＡＰＩプログラムが一つ又は複数のＷｅｂＡＰＩ利用プログラムから利用されている場合に、前記ＷｅｂＡＰＩプログラム又は前記ＷｅｂＡＰＩ利用プログラムが、前記ＷｅｂＡＰＩプログラムの呼び出し状況をＷｅｂＡＰＩ呼び出し制御プログラムに送ることで、ＷｅｂＡＰＩプログラムの使用量を計測する情報提供方法。
7. 請求項６において、前記ＷｅｂＡＰＩ利用プログラム毎に一意に決めたキー情報を用いて前記ＷｅｂＡＰＩ利用プログラムが前記ＷｅｂＡＰＩプログラムを呼び出し、前記ＷｅｂＡＰＩプログラムは前記キー情報を前記ＷｅｂＡＰＩ呼び出し制御プログラムに送ることでＷｅｂＡＰＩ呼び出し制御プログラムが、呼び出されたＷｅｂＡＰＩプログラムの使用量を計測する情報提供方法。
8. 請求項７において、前記ＷｅｂＡＰＩ利用プログラムが利用したＷｅｂＡＰＩプログラムをログに残し、又は前記ＷｅｂＡＰＩプログラムが呼び出されたＷｅｂＡＰＩ利用プログラムをログに残し、前記ログを定期的に前記ＷｅｂＡＰＩ呼び出し制御プログラムに送付し、前記ＷｅｂＡＰＩ呼び出し制御プログラムでは前記ログを解析することで呼び出されたＷｅｂＡＰＩプログラムを特定する情報提供方法。
9. 請求項８において、前記ＷｅｂＡＰＩ利用プログラムのログと前記ＷｅｂＡＰＩプログラムのログの両方を前記ＷｅｂＡＰＩ呼び出し制御プログラムに送り、両方のログを比較し、ＷｅｂＡＰＩ呼び出しに関する両者の不一致を検出し、不正なログを見つける情報提供方法。
10. 請求項６において、前記ＷｅｂＡＰＩ利用プログラムは前記ＷｅｂＡＰＩプログラムを呼び出す前に前記ＷｅｂＡＰＩ呼び出し制御プログラムが発行するセッションＩＤを取得し、前記ＷｅｂＡＰＩ呼び出し制御プログラムは、前記セッションＩＤを発行したＷｅｂＡＰＩ利用プログラムを記録し、前記ＷｅｂＡＰＩ呼び出しプログラムが前記セッションＩＤを用いて前記ＷｅｂＡＰＩプログラムを呼び出した後、前記ＷｅｂＡＰＩプログラムは前記セッションＩＤを前記ＷｅｂＡＰＩ呼び出し制御プログラムに送ることで、ＷｅｂＡＰＩ呼び出し制御プログラムが呼び出し元であるＷｅｂＡＰＩ利用プログラムと呼び出し先であるＷｅｂＡＰＩプログラムを特定する情報提供方法。
11. インターネット上でＷｅｂページを提供するＷｅｂサイトを用いた広告提供方法であって、
    前記Ｗｅｂサイトは一つ又は複数のＷｅｂＡＰＩを用いたＷｅｂページであり、前記Ｗｅｂページに広告仲介サービスが提供する広告が掲載されている場合に、Ｗｅｂブラウザで前記Ｗｅｂページに掲載した広告が選択されたときに、前記Ｗｅｂページを構築するためにＷｅｂサイトが利用したＷｅｂＡＰＩを特定し、前記ＷｅｂＡＰＩ提供者に対価を支払う広告提供方法。
12. 請求項１１において、ネットワークで各々接続された、前記Ｗｅｂブラウザを稼動させるＷｅｂブラウザ処理装置と、前記Ｗｅｂサイトを稼動させるＷｅｂサイト処理装置と、前記ＷｅｂＡＰＩを稼動させるＷｅｂＡＰＩ処理装置と、広告仲介サービスを稼動させる広告仲介サービス処理装置とを有し、
    前記Ｗｅｂブラウザから前記Ｗｅｂページの要求を受けたＷｅｂサイト処理装置が、前記広告仲介サービス処理装置にＷｅｂサイト運営者の紹介者識別情報を送出し、前記広告仲介サービス処理装置からセッションＩＤと広告識別情報を取得し、当該セッションＩＤを引数に含めてＷｅｂＡＰＩを呼び出し、
    前記ＷｅｂＡＰＩ処理装置が、前記セッションＩＤと前記ＷｅｂＡＰＩ提供者の紹介者識別情報を広告仲介サービス処理装置に送出し、
    前記広告仲介サービス処理装置は、前記セッションＩＤが正しいものであることを確認し、セッションＩＤとＷｅｂＡＰＩ提供者の紹介者識別情報を記録し、
    前記広告仲介サービス処理装置で前記セッションＩＤが正しいことが判明した場合には、前記ＷｅｂＡＰＩ処理装置は、前記ＷｅｂＡＰＩを実行して処理結果をＷｅｂサイト処理装置に返し、
    前記Ｗｅｂサイトでは、処理結果及び広告仲介サービスが保持する広告情報のＵＲＬとセッションＩＤを用いて、広告情報のリソースを取得するためのＵＲＬにパラメータとしてセッションＩＤを含めたＷｅｂページを生成して前記Ｗｅｂブラウザに返し、
    前記Ｗｅｂブラウザが広告情報のリソースを広告仲介サービス処理装置に要求すると、前記広告仲介サービス処理装置では広告情報の要求があったことをセッションＩＤと関連付けて記録した後、広告情報のリソースを前記Ｗｅｂブラウザに返し、
    前記ＷｅｂブラウザではＷｅｂサイトが生成したＷｅｂページを表示する広告提供方法。
13. 請求項１１において、ネットワークで各々接続された、前記Ｗｅｂブラウザを稼動させるＷｅｂブラウザ処理装置と、前記Ｗｅｂサイトを稼動させる前記Ｗｅｂサイト処理装置と、前記ＷｅｂＡＰＩを稼動させるＷｅｂＡＰＩ処理装置と、広告仲介サービスを稼動させる広告仲介サービス処理装置とを有し、
    前記Ｗｅｂブラウザから前記Ｗｅｂページの要求を受けたＷｅｂサイト処理装置が、前記Ｗｅｂブラウザ処理装置にセッションＩＤ要求プログラム、ＷｅｂＡＰＩ呼び出しプログラム及びページ生成プログラムを含むページをＷｅｂブラウザに返し、
    前記Ｗｅｂブラウザは、返されたページに含まれるプログラムを実行することにより、前記ＷｅｂＡＰＩ提供者の紹介者識別情報を広告仲介サービス処理装置に送出し、
    前記広告仲介サービス処理装置がリクエストを受けると、セッションＩＤ生成、貢献者記録を実施してセッションＩＤをＷｅｂブラウザに返し、
    前記Ｗｅｂブラウザは、前記セッションＩＤと前記ＷｅｂＡＰＩ提供者の紹介者識別情報を前記広告仲介サービス処理装置に送出し、
    前記広告仲介サービス処理装置は、前記セッションＩＤが正しいものであることを確認し、前記セッションＩＤと前記ＷｅｂＡＰＩ提供者の紹介者識別情報を記録し、
    前記広告仲介サービス処理装置で前記セッションＩＤが正しいことを確認した場合には前記ＷｅｂＡＰＩ処理装置は、前記ＷｅｂＡＰＩを実行して処理結果を前記Ｗｅｂブラウザに送出し、
    前記Ｗｅｂブラウザは、前記Ｗｅｂページを生成し、広告情報のリソースを前記広告仲介サービス処理装置に要求すると、前記広告仲介サービス処理装置では広告情報の要求があったことを前記セッションＩＤと関連付けて記録した後、前記広告情報のリソースをＷｅｂブラウザに返し、
    前記Ｗｅｂブラウザでは生成したＷｅｂページを表示する広告提供方法。
14. 請求項１１において、ネットワークで各々接続された、前記Ｗｅｂブラウザを稼動させるＷｅｂブラウザ処理装置と、前記Ｗｅｂサイトを稼動させるＷｅｂサイト処理装置と、前記ＷｅｂＡＰＩを稼動させるＷｅｂＡＰＩ処理装置と、広告仲介サービスを稼動させる広告仲介サービス処理装置とを有し、
    前記Ｗｅｂブラウザから前記Ｗｅｂページの要求を受けたＷｅｂサイト処理装置が、前記広告仲介サービス処理装置にＷｅｂサイト運営者の紹介者識別情報を送出し、前記広告仲介サービス処理装置からセッションＩＤと広告識別情報を取得し、当該セッションＩＤを引数に含めてＷｅｂＡＰＩ呼び出しを前記広告仲介サービス処理装置に対して行い、
    前記広告仲介サービス処理装置は、前記セッションＩＤが正しいものであることを確認し、前記セッションＩＤと前記ＷｅｂＡＰＩ提供者の紹介者識別情報を記録し、ＷｅｂＡＰＩ呼び出しを実施し、
    前記ＷｅｂＡＰＩ処理装置は、前記ＷｅｂＡＰＩを実行して処理結果を広告仲介サービス処理装置に送出し、
    前記広告仲介サービス処理装置は、処理結果をＷｅｂサイト処理装置へ送出し、
    前記Ｗｅｂサイトでは、処理結果及び広告仲介サービスが保持する広告情報のＵＲＬとセッションＩＤを用いて、前記広告情報のリソースを取得するためのＵＲＬにパラメータとしてセッションＩＤを含めたＷｅｂページを生成して前記Ｗｅｂブラウザに返し、
    前記Ｗｅｂブラウザが広告情報のリソースを前記広告仲介サービス処理装置に要求すると、前記広告仲介サービス処理装置では広告情報の要求があったことを前記セッションＩＤと関連付けて記録した後、前記広告情報のリソースをＷｅｂブラウザに返し、
    前記Ｗｅｂブラウザでは前記Ｗｅｂサイトが生成したＷｅｂページを表示する広告提供方法。
15. 請求項１１において、ネットワークで各々接続された、前記Ｗｅｂブラウザを稼動させるＷｅｂブラウザ処理装置と、前記Ｗｅｂサイトを稼動させるＷｅｂサイト処理装置と、前記ＷｅｂＡＰＩを稼動させるＷｅｂＡＰＩ処理装置と、広告仲介サービスを稼動させる広告仲介サービス処理装置とを有し、
    前記Ｗｅｂブラウザから前記Ｗｅｂページの要求を受けたＷｅｂサイト処理装置が、前記広告仲介サービス処理装置にＷｅｂＡＰＩ呼び出しを実施し、
    前記広告仲介サービス処理装置は、セッションＩＤを生成し、前記ＷｅｂＡＰＩ提供者の紹介者識別情報を記録し、呼び出し先のＷｅｂＡＰＩの紹介者識別情報を貢献者としてセッションＩＤと共に記録し、当該セッションＩＤを引数に含めてＷｅｂＡＰＩ呼び出しを前記ＷｅｂＡＰＩ処理装置に対して行い、
    当該呼び出しを受けたＷｅｂＡＰＩ処理装置は、前記ＷｅｂＡＰＩを実行し、処理結果を前記広告仲介サービス処理装置に送出し、
    前記広告仲介サービス処理装置は、処理結果及びセッションＩＤをＷｅｂサイト処理装置へ送出し、
    前記Ｗｅｂサイトでは、処理結果及び広告仲介サービスが保持する広告情報のＵＲＬとセッションＩＤを用いて、前記広告情報のリソースを取得するためのＵＲＬにパラメータとしてセッションＩＤを含めたＷｅｂページを生成してＷｅｂブラウザに返し、
    前記Ｗｅｂブラウザが広告情報のリソースを広告仲介サービス処理装置に要求すると、前記広告仲介サービス処理装置では広告情報の要求があったことを前記セッションＩＤと関連付けて記録した後、前記広告情報のリソースを前記Ｗｅｂブラウザに返し、
    前記ＷｅｂブラウザではＷｅｂサイトが生成したＷｅｂページを表示する広告提供方法。
16. 請求項１２から請求項１５のいずれか一項に記載の広告提供方法において、
    上記生成されたＷｅｂブラウザに表示した広告を、閲覧者が選択したときに、前記広告仲介サービス処理装置には、前記広告識別情報と前記セッションＩＤが到達し、前記広告仲介サービス処理装置では選択されたこととそのときのセッションＩＤを記録しておき、
    広告仲介サービスでは広告識別情報に関連する事業者のＷｅｂサイトにリダイレクトすることで広告に対応するＷｅｂページを表示する広告提供方法。
17. 請求項１２から請求項１５のいずれか一項に記載の広告提供方法において、
    前記広告仲介サービス処理装置に記録した広告情報の要求があったセッションＩＤを利用し、前記セッションＩＤに関連付いた紹介者識別情報を抽出することで広告を表示したＷｅｂページの生成に貢献したＷｅｂサイト運営者及びＷｅｂＡＰＩ提供者を特定する広告提供方法。
18. 請求項１２から請求項１５のいずれか一項に記載の広告提供方法において、
    前記広告仲介サービス処理装置に記録した広告が選択されたときのセッションＩＤを利用し、前記セッションＩＤに関連付いた紹介者識別情報を抽出することで広告が選択されたＷｅｂページの生成に貢献したＷｅｂサイト運営者及びＷｅｂＡＰＩ提供者を特定する広告提供方法。
19. 請求項１２から請求項１５のいずれか一項に記載の広告提供方法において、
    セッションＩＤではなく、Ｗｅｂサイトを一意に特定できるキーを用いて、Ｗｅｂサイトが利用したＷｅｂＡＰＩを特定する場合には、
    前記Ｗｅｂサイトは、予めＷｅｂサイトを一意に識別できるキーを取得し、前記ＷｅｂＡＰＩを呼び出すときは前記キーを一緒に送出し、前記ＷｅｂＡＰＩは前記キーを広告仲介サービスに送出し、前記広告仲介サービスでは前記キーと前記キーを送出したＷｅｂＡＰＩを関連付けて保持し、
    前記Ｗｅｂサイトは、前記ＷｅｂＡＰＩの処理結果と広告を埋め込んだＷｅｂページをＷｅｂブラウザに送出し、
    前記Ｗｅｂブラウザから埋め込んだ広告情報の画像等を取得するときに用いるＵＲＬには、前記広告情報の画像等を広告仲介サービスから取得するときに、広告仲介サービスにキーが渡るように、パラメータとしてキーを付加しておき、
    広告がクリックされたときに遷移するＵＲＬにも、パラメータとしてキーを付加しておき、
    前記Ｗｅｂブラウザに広告を表示したときや閲覧者が広告をクリックしたときに、広告仲介サービスにキーが送られるようにしておくことで広告の閲覧状況を把握可能とし、
    その回数に応じてＷｅｂサイト毎の広告への貢献度及び、キーとＷｅｂＡＰＩを関連付けて保持している情報に基づいてＷｅｂサイト毎に利用したＷｅｂＡＰＩとその回数を特定する広告提供方法。
20. 請求項１２から請求項１５のいずれか一項に記載の広告提供方法において、
    前記Ｗｅｂサイト、前記ＷｅｂＡＰＩの何れか又は両方が前記ＷｅｂＡＰＩの呼び出しログをセッションＩＤ又はキーと共に保持し、前記ログを定期的に広告仲介サービスに送出し、
    前記広告仲介サービスでは、前記ログを解析することでＷｅｂサイトが利用したＷｅｂＡＰＩを特定する広告提供方法。
21. 請求項２０に記載の広告提供方法において、
    前記広告仲介サービスは、前記Ｗｅｂサイトと前記ＷｅｂＡＰＩの両方からログを収集し、前記両方のログの内容を比較し、両者に前記ＷｅｂＡＰＩを呼び出した、又は呼び出された記述があったときにその呼び出しが確かであると判断する広告提供方法。
22. Ｗｅｂブラウザに広告が表示された、又は広告がクリックされたときに発生する対価をＷｅｂＡＰＩ提供者に分配する対価分配方法であって、
    Ｗｅｂブラウザが広告を表示したＷｅｂページを要求したときに、その要求を受け取ったＷｅｂサイトが利用した一つ又は複数のＷｅｂＡＰＩを請求項１２から請求項１５、請求項２０の何れかの方法で特定し、発生した対価をＷｅｂＡＰＩ提供者に分配する対価分配方法。
23. Ｗｅｂブラウザに広告が表示された、又は広告がクリックされたときに発生する対価を特定期間毎にＷｅｂＡＰＩ提供者に分配する対価分配方法であって、
    請求項１２から請求項１５、請求項１９、請求項２０の何れかの方法で収集した広告に貢献したＷｅｂサイトと前記Ｗｅｂサイトが利用したＷｅｂＡＰＩの記録から、前記特定期間内に前記Ｗｅｂサイトに発生した対価の総量と、前記Ｗｅｂサイトが利用した一つ又は複数のＷｅｂＡＰＩの回数を求め、各ＷｅｂＡＰＩの利用回数に応じて対価の総量をＷｅｂＡＰＩ提供者に分配する対価分配方法。
24. 請求項１１において、利用しているＷｅｂＡＰＩの種類に応じて表示する広告を選択する方法であり、
    広告仲介サービスは、ＷｅｂＡＰＩとそのＷｅｂＡＰＩに関連する一つ又は複数のキーワードを管理し、広告情報とその広告に関連するキーワードを管理し、
    広告仲介サービスがＷｅｂブラウザから広告情報の要求を受け取ったときに、セッションＩＤを用いて利用したＷｅｂＡＰＩを特定し、又はキーを用いてＷｅｂサイトが良く利用しているＷｅｂＡＰＩを特定し、
    そのＷｅｂＡＰＩに関連するキーワードを取得し、そのキーワードを同じキーワードを含む広告情報を選択することで、利用しているＷｅｂＡＰＩの種類に応じた広告をＷｅｂブラウザに提供する広告提供方法。
25. 請求項１１において、前記Ｗｅｂブラウザからの全リクエストに対するＷｅｂＡＰＩの使用量を計測するのではなく、特定期間に発生した前記Ｗｅｂブラウザからのリクエストに対するＷｅｂＡＰＩの使用量を計測し、その計測結果に従って、前記ＷｅｂＡＰＩに分配する広告貢献の対価を決定する広告提供方法。

Images