WebAPI提供者が広告仲介サービスを利用し� ��広告収入を得るための仕組みの概念図を図1 に示す。

 Webブラウザ102は、Webブラウザ処理装置に� ��って、Webサイト103は、Webサイト処理装置に� ��って、WebAPI104は、WebAPI処理装置によって、� ��告仲介サービス105は、広告仲介サービス処� ��装置によって、事業者のWebサイト106は、事� ��者のWebサイト処理装置によって、それぞれ� ��動し、これらはネットワークで接続されて� ��る。各処理装置は、コンピュータである。

 WebAPI104を利用したいWebサイト運営者は広� ��仲介者と契約し、紹介者識別情報を取得す� ��。また、紹介料を得たいWebAPI提供者も広告� ��介者と契約し、紹介者識別情報を取得する� ��

 まず、Webブラウザ102からWebサイト103にWeb� ��ージ要求111を実施する。

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

 次に、Webサイト103ではAPI呼び出しを実施1 14しWebAPI104を呼び出す。このとき、広告仲介� ��ービス105から受け取ったセッションIDを送� �する。また、必要に応じて、WebAPIの実行に� �要なデータもWebサイト103から、WebAPI104へ送� �。

 WebAPI104では、受け取ったセッションIDが� �しいものであるかどうかを確認するために� �広告仲介サービス105にセッションID確認115を 実施し、WebAPI104の紹介者識別情報及びセッシ ョンIDを送出する。

 広告仲介サービス105では、セッションID� �確認し、広告仲介サービス105が発行したも� �であるかどうか、いつ発行したものか(有効� ��限内であるか)、などの情報に基づき、有効 であるかどうかを確認する。有効であった場 合、そのセッションIDとWebAPI提供者の紹介者� ��別情報の組み合わせをデータベース等に記� ��する。WebAPI104に、セッションID確認結果116� �して返す。

 WebAPI104では、セッションID確認結果が正� �いものであればWebAPI104の機能を実行して呼� �出し結果117をWebサイト103に返す。

 Webサイト103では、WebAPI104の呼び出し結果1 17を用いてWebページの元となるHTMLを構築する 。また、広告を表示するために、広告情報リ ソースのURLを埋め込む。このURLには、セッシ ョンIDや広告を特定するために用いる広告ID� �埋め込む。また、その広告をWebブラウザ102� �選択するときにより詳細な情報を提供する� �ージに遷移させるが、このときに用いるリ� �クにもセッションIDを埋め込む。

 構築した広告付Webページ118のHTMLをWebブラ ウザ102に送出すると、Webブラウザ102ではHTML� �に埋め込むリソースをURLで示される箇所か� �取得する。広告情報もリソースの一つであ� �、広告情報要求119をURLに出すことにより取� �する。広告情報のリソースは広告仲介サー� �ス105が管理しており、このとき利用するリ� �ースのURLはセッションIDを含める。広告仲介 サービス105ではそのセッションIDと広告情報� ��要求された事実を記録しておくことでどの� ��ッションIDの延長で広告情報が要求された� �かを知ることができる。

 次に、広告仲介サービス105は要求された� ��告情報120をWebブラウザ102に返す。

 Webブラウザ102では広告情報120を受け取る� ��、それをWebブラウザ102上に表示する。

 広告が表示されたら課金する広告仲介サ� ��ビス105であった場合、この表示した回数と� ��示に関与したWebサイト運営者、WebAPI提供者� ��集計することで紹介料を算出する。

 Webブラウザ102に表示された広告が、閲覧� ��101にクリックされる等して選択された場合� ��課金する場合は、次の処理も行う。

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

 閲覧者101が、広告を選択すると、URLに広� ��選択121のリクエストを送出する。

 広告仲介サービス105では、URLに含まれる� ��ッションIDと広告が選択された事実をデー� �ベース等に記録し、広告IDを参照して対応す る広告に関するより詳しいページ(事業者のWe bサイト106)にリダイレクト122する。その結果� ��Webブラウザには事業者のWebページ123が返さ� ��、表示される。

 広告仲介サービス105に記録した広告選択� ��有無と選択された場合のセッションIDに関� �付いたWebサイト運営者、WebAPI提供者を集計� �、広告が選択されたことにより得られる紹� �料を特定のルールに基づいて貢献者に分配� �ることが可能となる。

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

 Webサイトの運営者は、このWebAPIを利用し� ��、自分のWebサイトに今日誕生日の有名人の� ��前を表示する機能を付加したいとする。

 これを実現するためのシステム構成図を� ��2に示す。Webブラウザ102が動作するWebブラウ ザ処理装置360、Webページを返すWebサイト処理 装置370、ソフトウェア機能を提供するWebAPI処 理装置380、広告仲介サービス処理装置300は通 信部303を備えており、この通信部303を介して ネットワーク304に接続する。

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

 Webブラウザ処理装置360は、一般的なWebブ� ��ウザ102が稼動する処理装置であり本発明に� ��る特段の工夫はないため、詳しい説明は省� ��する。

 Webサイト処理装置370は、Webブラウザ102か� ��の要求を受けて情報を返す処理装置である� ��制御部301bと記憶部302bを持つ。制御部301bは� ��受信部374(Webサーバ相当)と、ページ生成部37 3、WebAPI呼び出し部372とセッションID要求部371 を持つ。本発明とは直接関係ないが一般的に はWebサイトの記憶部302bはHTML375や画像376等を� ��つ。

 WebAPI処理装置380は、WebAPIが持つ機能を要� ��されたときに、要求に応じた処理を行い要� ��者が求める結果を返す。本実施例では、日� ��毎にその日付が誕生日である有名人の名前� ��返す。WebAPI処理装置380は、制御部301cと記憶 部302cを持つ。制御部301cは、送受信部381、WebA PI機能部382、セッションID確認要求部383を持� �。WebAPI機能部382では、日付からその日付が� �生日である有名人の名前を返す。記憶部302c� ��、有名人誕生日テーブル384を持つ。有名人� ��生日テーブル384は、日付とその日付が誕生� ��である有名人の名前を対応付けて格納する� ��

 広告仲介サービス処理装置300は、制御部3 01a、記憶部302aを備える。制御部301aは、セッ� ��ョンID生成部311、セッションID確認部312、貢 献者記録部313、広告要求元IP取得部314、広告� ��得部315、選択記録部316、紹介料算出部317、� ��受信部318を持つ。記憶部302aは、Webサイト管 理テーブル321、WebAPI管理テーブル322、セッシ ョン管理テーブル323、貢献者記録テーブル324 、広告情報格納テーブル325を持つ。

 Webサイト管理テーブル321は、紹介者識別� ��報331、WebサイトURL332、口座番号333等を格納� ��る。

 WebAPI管理テーブル322は、紹介者識別情報3 35、WebAPIのURL336、口座番号337等を格納する。

 セッション管理テーブル323は、セッショ� ��ID341、生成時刻342、広告要求元IP343、選択有 無344を格納する。

 貢献者記録テーブルは、セッションID345� �紹介者識別情報346を格納する。

 広告情報格納テーブルは、広告ID351、分� �352、広告画像353、事業者URL354を格納する。

 まず、準備としてWebAPI提供者は広告仲介� ��ービスと契約し、WebAPIのURLや紹介料の振込� ��である口座番号等を登録し、紹介者識別情� ��の発行を受ける。紹介者識別情報とWebAPI提� ��者が登録した情報は、WebAPI管理テーブル322� ��格納する。

 WebAPIを利用したいWebサイト運営者は同様� ��広告仲介サービスと契約し、WebサイトURLや� ��介料の振込先である口座番号等を登録し、� ��介者識別情報の発行を受ける。紹介者識別� ��報とWebサイト運営者が登録した情報は、Web� ��イト管理テーブル321に格納する。

 Webブラウザ102からWebサイトのページを要� ��したときの処理の流れを図3に示す。処理の 流れを通して各部で実施することを説明する 。

 閲覧者101がWebブラウザ102を操作し、Webサ� ��トのWebページ要求402を行うとWebブラウザ102� ��WebサイトにWebページ要求403を送信する。

 Webサイト処理装置370では、セッションID要� �部371を用いてセッションID要求404を実施する 。このとき、パラメータとして紹介者識別情 報(ここではshoukaisha_site_0978とする)を与える� �例えば以下のように広告仲介サービス処理� �置300にHTTPアクセスすることでセッションID� �取得する。
 http://koukoku_chuukai_service.com/get_session_id?shoukais ha_id=shoukaisha_site_0978

 本実施例では、HTTPのGETリクエストで各種 処理を要求するが、POSTやCookieを用いたパラ� �ータの受け渡しを行っても良い。

 広告仲介サービス処理装置300では、セッ� ��ョンID要求404を受信すると、セッションID生 成部311を用いてセッションIDを生成し、セッ� ��ョン管理テーブル323にセッションID341とし� �生成したセッションIDを、生成時刻として現 在時刻を記録する。

 セッションIDはWebブラウザ102からのWebペ� �ジ要求403毎に固有のIDを生成する。

 次に、貢献者記録部313を用いて貢献者記� ��テーブル324のセッションID欄345に生成した� �ッションIDを、紹介者識別情報欄346にパラメ ータで渡された紹介者識別情報を記録する。

 生成したセッションIDは、Webサイト処理� �置370に返す。

 返されたセッションID407の例を以下に示す� �これはXML形式でセッションID407を返した場合 の例である。
 <?xml version=“1.0” encoding=“UTF-8”?>
<item>
    <session_id>0123456789abcdef</session_id> ;
</item>

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

 セッションIDと広告IDを返す例:
<?xml version=“1.0” encoding=“UTF-8”?>
<item>
    <session_id>0123456789abcdef</session_id> ;
    <koukoku_id>0255</koukoku_id>
</item>

 セッションIDとリンク文字列を返す例:
<?xml version=“1.0” encoding=“UTF-8”?>
<item>
    <session_id>0123456789abcdef</session_id> ;
    <link>&lt;a
 href=“http://koukoku_chuukai_service.com/jump?koukoku_id =0255&session_id=0123456789abcdef” &gt;&lt;im g src=“http://koukoku_chuukai_service.com/koukoku_gazou?k oukoku_id=0255&session_id=0123456789abcdef” &gt;& amp;lt;/a&gt;</link>
  </item>

 その他、引数に広告の分類を渡し、広告� ��介サービス処理装置では、広告情報格納テ� ��ブル325の中から分類352が引数の分類と一致� ��る広告の広告ID351をランダムに選択しても� �い。

 次にWebAPI呼び出し部372を用いてWebAPI呼び出� ��408を行う。このとき、パラメータとして本� ��の日付すなわちAPIの実行に必要なデータと� ��ッションIDを与える。以下にHTTPアクセスに� ��ける呼び出しの例を示す。
 http://webapi_yuumeijin_birthday.com/get_names?date=0811&a mp;session_id=0123456789abcdef

 WebAPI処理装置380では、上記の要求が到達す� ��とセッションID確認要求部383を通してセッ� �ョンID確認409を送出し、セッションIDが有効� ��あるかどうかを広告仲介サービス処理装置3 00に確認する。このとき、事前に取得した紹� ��者識別情報(ここではshoukaisha_api_0888とする)� ��一緒に送信する。例えば以下のHTTPアクセス を行うことで実施する。
 http://koukoku_chuukai_service.com/check?session_id=012345 6789abcdef&shoukaisha_id=shoukaisha_api_0888

 広告仲介サービス処理装置300では、上記� ��要求を受け取るとsession_idパラメータで渡さ れたセッションIDが有効であるかどうかを調� ��る。具体的には、セッションID確認部312を� �いてセッションID確認410を実施する。セッシ ョンIDが、セッション管理テーブル323に存在� ��ているかどうか、セッションIDの生成時刻34 2から特定時間(例えば5分)以上経過していな� �か、等に基づいて有効であるかどうかを判� �する。

 確認した結果、有効であった場合、貢献� ��記録411を実施する。貢献者記録部313を用い� ��貢献者記録テーブル324にセッションID及びsh oukaisha_idパラメータで渡されたWebAPI提供者の� ��介者識別情報を記録する。

 セッションID確認結果412をWebAPI処理装置380� �返信する。例えば、以下のようにXMLを用い� �返信する方法が考えられる。
<?xml version=“1.0” encoding=“UTF-8”?>
<check>
   <session_id>0123456789abcdef</session_id>
   <result>valid</result>
</check>

 上記では、resultタグに確認結果を含み、� ��効である場合は(例として)valid、無効である 場合は(例として)invalidを返す。

 WebAPI処理装置380でセッションIDが有効で� �ることが分かったならば、WebAPI機能部382でWe bAPIの機能を実行413する。具体的には、dateパ� ��メータで受け取った日付が誕生日である有� ��人を有名人誕生日テーブル384から検索して� ��得する。

 取得した有名人のリストは呼び出し結果414� ��して返す。例えば、以下のようにXMLを用い� ��返信する方法が考えられる。
 <?xml version=“1.0” encoding=“UTF-8”?>
 <response>
     <date>0811</date>
     <list>
        <name>鈴木さん</name>
        <name>高野さん</name>
   </list>
</response>

 WebAPI処理装置380でセッションIDが無効であ� �ことが分かったならば、無効であることをWe bAPIの呼び出し元に通知する。以下に例を示� �。
<?xml version=“1.0” encoding=“UTF-8”?>
<response>invalid</response>

 Webサイト処理装置380でWebAPIの実行結果を� ��け取ると、その実行結果と広告を用いてペ� ��ジ生成415する。

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

 今日誕生日の有名人表示領域502には、WebA PIが返した値をHTML化して書き込む。

 広告は、以下のようにリンクの形で広告表� ��領域501に埋め込む。
 <a href=“http://koukoku_chuukai_service.com/jump?kou koku_id=0255&session_id=0123456789abcdefg”><img� �src=“http://koukoku_chuukai_service.com/koukoku_gazou?kou koku_id=0255&session_id=0123456789abcdefg”></a&g t;

 上記のaタグやimgタグに持つURLのsession_id� �ラメータの値(0123456789abcdefg)は、広告仲介サ� ��ビス処理装置300にセッションID要求404を行� �た結果取得したセッションID407の値である。

 koukoku_idパラメータとして埋め込む広告ID� ��事前にWebサイト運営者が選択した広告の広� ��IDを利用しても良いし、上記に示すように� �ッションID407と一緒に広告IDを返す場合、広� ��仲介サービス処理装置300がその広告IDを返� �方法も考えられる。また、セッションID407と 一緒に広告のリンク全体を広告仲介サービス 処理装置300が返す方法も考えられる。この場 合は、広告仲介サービス処理装置300が返した リンクの文字列をそのままHTML内の広告表示� �域501に転記することで広告付Webページを実� �できる。

 Webサイト処理装置370では、広告付Webペー� ��416をWebブラウザ102に返す。Webブラウザ102で� ��返されたWebページを解析し、足りない情報� ��あればその情報をさらに要求する。

 本実施例の場合、Webページとして返したH TMLの中の広告のリンクには、imgタグが存在し 、この画像の存在場所であるURLがsrc属性とし て記述してある。Webブラウザ102では、src属性 に記述されたURLにアクセスして広告情報要求 417を実施する。

 広告情報要求417を受けた広告仲介サービ� ��処理装置300では、広告情報要求元IP記録418� �して、セッション管理テーブル323の広告要� �元IPに広告情報要求元のIPアドレス、つまりW ebブラウザ処理装置360のIPアドレスを記録し� �後、広告情報格納テーブル325から広告画像35 3を取得し、要求元のWebブラウザ102に返す。

 本実施例では、画像を広告情報として返� ��ているが、FlashやJavaAppletや動画をリンクと� ��て利用する方法も考えられる。また、HTML内 に別のHTMLを埋め込むiframeタグ等を用いるこ� �で埋め込む広告をHTMLとして取得、表示する� ��法も考えられる。

 Webブラウザ102は取得した広告情報420を用� ��てWebページを構築して表示する。

 閲覧者101は、Webブラウザ102に表示されたW ebページを閲覧する。Webページ内に興味のあ� ��広告が表示されていた場合、その広告をク� ��ックする等して広告選択421を実施する。

 広告選択421を行うと、Webブラウザ102では広� ��のリンクのURLに広告選択422のリクエストを� ��信する。本実施例におけるURLは下記である� ��
 http://koukoku_chuukai_service.com/jump?koukoku_id=0255&am p;session_id=0123456789abcdefg

 広告仲介サービス処理装置300では、広告� ��選択されたことをセッション管理テーブル3 23のセッションIDに対応する行の選択有無の� �344に有を記述することで記録する。セッシ� �ン管理テーブル323の選択有無の欄344の初期� �は無とする。

 次に、事業者のWebサイト(http://jigyousha_page .com)にリダイレクトする。Webブラウザ102に事� ��者のWebサイトにリダイレクト424を指示し、W ebブラウザ102は事業者のWebページ要求425を事� ��者のWebサイト処理装置401に送出することで� ��事業者のWebページ426を取得する。

 リダイレクトとは、上記で示すようにWeb� ��ラウザ102にレスポンスを戻し、自動的(閲覧 者101が関与せず)に、リダイレクト先のURL(事� ��者のWebサイトのURL)にリクエストを送信して リダイレクト先のWebページを取得して表示す る処理を指す。

 実現方法として、Webブラウザにリダイレク� ��(301もしくは302)のステータスコード及びリ� �イレクト先のURL(http://jigyousha_page.com)をレス� �ンスとして返すことで、Webブラウザが備え� �いる機能を用いて自動的にリダイレクト先� �URLにリクエストを送出し、事業者のWebサイ� �処理装置401のページを取得する方法や、次� �ようなタグを含むHTMLを返すことで、Webブラ� ��ザ102が備えている機能を用いてhttp://jigyousha _page.comにリクエストを送出し、事業者のWebペ ージ426を取得する方法が考えられる。
<META HTTP-EQUIV=“refresh” content=“0;URL=http:// jigyousha_page.com “>

 [紹介料の算出方法]
 紹介料の算出方法は様々な方針に基づいて� ��定される。ここでは、その一例について説� ��する。ここでの処理は、紹介料算出部317で� ��われる。

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

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

 次に、セッション管理テーブルの生成時� ��が紹介料を算出したい期間である行を一行� ��つ順に取得する(この取得した行のデータを 以下SCと呼ぶ)603。例えば、2007年の8月分の集� ��をしたい場合、生成時刻が2007/08/01 00:00:00� �ら2007/09/01 00:00:00未満の間の行を一行ずつ取 得する。

 SCの選択有無の欄が有であるかどうかを� �べ604、有でなければ次の行を取得する。

 有であれば、紹介料を計算する。貢献者� ��録テーブルを参照し、SCのセッションIDと同 じセッションIDを持つ行を全て取得605する。

 選択毎の紹介料í取得した行数を計算し� �各紹介者に支払う紹介料を求める606。

 次に、取得した行を一行ずつ順に取得す� ��(この取得した行のデータを以下CCと呼ぶ)607 。

 紹介料算出テーブル内のCCの紹介者識別� �報に対応する行の紹介料欄の値に各紹介者� �支払う紹介料を加算する608。

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

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

 紹介料算出テーブルに紹介者識別情報毎� ��紹介料が格納されるので、この額を各紹介� ��識別情報に対応する者に支払う。具体的に� ��、Webサイト管理テーブル321やWebAPI管理テー� ��ル322の口座番号の欄(333、337)に格納された� �座番号を利用してその口座に振り込む方法� �考えられる。

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

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

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

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

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

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

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

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

 実施例1の効果について説明する。WebAPI提 供者に広告収入を得る機会を提供することが 可能となる。セッションIDを広告仲介サービ� ��、WebAPI、Webサイトの3者のやり取り時に引き 回すことにより、不正を働くことが困難な仕 組みにすることができる。

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

 実施例1では、セッションID要求404、WebAPI� ��び出し408、ページ生成415をWebサイト処理装� ��370で実施したが、JavaScript等のWebブラウザ102 で動作するプログラミング言語を用い、Webブ ラウザ102上でこれらの処理を実現しても良い 。

 この場合、実施例1でWebサイト処理装置370 に配していたセッションID要求部371、WebAPI呼� ��出し部372、ページ生成部373をWebブラウザ102� ��配する。

 具体的には、Webサイト処理装置370では、J avaScript等を用いてセッションID要求部、WebAPI� ��び出し部、ページ生成部を含めたWebページ� ��Webブラウザ102に送出する。これらの各部は� ��Webブラウザ102で実行する。

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

 実施例1との変更点を太線で示す。変更点 を中心に説明する。Webブラウザ102からWebペー ジ要求403を実施すると、Webサイト処理装置370 は、送受信部374で要求を受け付け、セッショ ンID要求部、WebAPI呼び出し部、ページ生成部� ��含むページ701をWebブラウザ102に返す。

 Webブラウザ102では、返されたページに含� ��れるプログラムを実行する。

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

 実施例2では、Webブラウザ102に表示したWeb ページの取得元(Webサイト処理装置370)とセッ� ��ョンIDの要求先(広告仲介サービス処理装置3 00)のドメインが異なる。現在のWebブラウザ102 では、セキュリティ対策のため、Webページの 取得元以外のドメインにJavaScriptから直接ア� �セスすることは通常できない。他ドメイン� �対してもアクセス可能とするJSONPという方法 を用いたセッションID要求処理について説明� ��る。

 Webページには、下記に示すように広告仲介� ��ービス処理装置からJavaScriptを取得するタグ を記述する。
<script src=“http://koukoku_chuukai_service.com/get_se ssion_id_json?callback=receiveSessionID&shoukaisha_id=sh oukaisha_site_0978”></script>

 callbackパラメータには、セッションIDが取得 されたときにWebブラウザ102によって呼び出し てもらいたいメソッド名を記述する。また、 Webページには下記のように呼び出し先のメソ ッドを定義しておく必要がある。
<script>
function receiveSessionID( data){   // セッション IDを取得した後の処理    ・・・ }
</script>

 上記のように広告仲介サービス処理装置3 00からJavaScriptを取得するタグを含むWebページ を表示するとWebブラウザ102は広告仲介サービ ス処理装置300にHTTPのGETリクエストを送出す� �。

 広告仲介サービス処理装置300がリクエスト� ��受けると、実施例1と同様のセッションID生� ��405、貢献者記録406を実施してレスポンス(セ ッションID703)を返す。レスポンスは下記のよ うになる。
 receiveSessionID( { “session_id” : “0123456789ab cdef” } );

 Webブラウザ102がこのレスポンスを受け取� ��と、上で示したWebページに含まれるreceiveSes sionIDを呼び出す。以上のような処理を実施す ることにより、Webページを取得したドメイン とは違うドメインにアクセスすることを可能 とする。

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

 セッションIDと広告IDを返す例:
 receiveSessionID( { “session_id” : “0123456789ab cdef”、 “koukoku_id” : “0255”} );

 セッションIDとリンク文字列を返す例:
 receiveSessionID( { “session_id” : “0123456789ab cdef”、 “link” : “<a href=http://koukoku_chu ukai_service.com/jump?koukoku_id=0255&session_id=0123456 789abcdef><img src=“http://koukoku_chuukai_service. com/koukoku_gazou?koukoku_id=0255&session_id=0123456789a bcdef”></a>“} );

 次に、Webブラウザ102ではWebAPI呼び出し部� ��用いて、WebAPI呼び出し704を実施する。パラ� ��ータとして、日付とセッションIDを渡す。� �の呼び出しもセッションID要求702と同様、JSO NPを用いて行うが、説明は省略する。WebAPIを� ��び出した後のWebAPI処理装置380の処理は実施� ��1と同じである。

 処理を終えると、呼び出し結果705をWebブ� ��ウザ102に返す。

 Webブラウザ102では、ページ生成部を用い� ��広告の貼り付け及びWebAPIの呼び出し結果の� ��示などのページ生成706を実施する。

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

 本実施例では、セッションID要求、WebAPI� �び出し、ページ生成の処理をWebブラウザで� �施する例を示したが、この中の一部の処理� �みをWebブラウザで実施するようにしても良� �。

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

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

 WebサイトからWebAPIを呼び出すときに、直� ��WebAPI処理装置380を呼ぶのではなく、広告仲� ��サービス処理装置300を介してWebAPIを呼ぶ実� ��例について説明する。

 図7に概念図を示す。太線で図1からの変� �点を示す。

 図1では、API呼び出し114を直接WebAPIに対し て実施していたが、本実施例では広告仲介サ ービス803を介して実施する。広告仲介サービ ス803では、API呼び出し814を受けると、指定さ れたWebAPI呼び出し815を実施して呼び出し結果 816を取得する。呼び出し結果816を取得したら 、その呼び出し結果816をWebサイト801に返す。

 システム構成を図8に示す。広告仲介サー ビス処理装置900に新たにWebAPI仲介部902を設け 、WebAPI処理装置980からセッションID確認要求� ��を削除した構成となる。

 シーケンス図を図9に示す。実施例1と差� �がある箇所を太線で示した。差異のある箇� �を中心に説明する。Webサイト処理装置980は� �WebAPI呼び出し1001を広告仲介サービス処理装� ��900に対して行う。引数として呼び出し方法� ��呼び出し先URL、パラメータ、セッションID� �渡す。ここで、呼び出し方法とは、 HTTPのGE T、POST等である。

 例えば、引数が各々(get、http://webapi_yuumeijin_ birthday.com/get_names、date=0811、0123456789abcdef)であ った場合、広告仲介サービスには次のような リクエストを送出する。
 http://koukoku_chuukai_service.com/call_webapi?method=get& amp;url=http%3A%2F%2Fwebapi_yuumeijin_birthday.com%2Fget_nam es&param=date%3D0811&session_id=0123456789abcdef

 上記で”%xx”はHTTPでパラメータを送付す るときに実施するエンコード後の文字列であ る。

 広告仲介サービス処理装置900では、この� ��クエストを受けるとsession_idパラメータで受 け取ったセッションIDに対してセッションID� �認410を行う。具体的には、セッションIDであ る0123456789abcdefが正しいことを、セッションID 確認部312を用いて確認する。不正であれば、 セッションIDが不正であったことをWebサイト� ��理装置370に通知する。

 セッションIDが正しければWebAPIの紹介者� �別情報取得1002を実施する。WebAPI管理テーブ� ��322の中からWebAPIのURLが、呼び出し先URLと一� ��する(又はURLが含むホスト名(webapi_yuumeijin_bir thday.com)が一致する)行を取得し、その行の紹� ��者識別情報を取得することで実現できる。

 貢献者記録411では、取得したWebAPIの紹介� ��識別情報とセッションIDのペアを、貢献者� �録部313を用いて貢献者記録テーブル324に記� �する。

 次に、WebAPI呼び出し1003を実施する。本実施 例のリクエストを受け取った場合、WebAPI仲介 部902では次に示すURLにHTTPのGETリクエストを� �出する。実施例1とは違い、ここでセッショ� ��IDを送出する必要はない。
 http://webapi_yuumeijin_birthday.com/get_names?date=0811

 WebAPI処理装置980でリクエストを受けると� ��dateパラメータで受け取った日付が誕生日で ある有名人の一覧をWebAPI機能部を実行413して 取得し、広告仲介サービス処理装置900に呼び 出し結果1004として返す。

 広告仲介サービス処理装置900は、取得し� ��有名人の一覧をWebサイト処理装置321に返す� ��

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

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

 実施例3では、Webサイト処理装置370からセ ッションID要求404及びWebAPI呼び出し1001を別々 に実施した。本実施例では、セッションID要� ��とWebAPI呼び出しを統合した場合について説� ��する。

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

 システム構成は、図8の広告仲介サービス 処理装置900からセッションID確認部312を削除� ��た構成となる。

 Webページ要求403を受けたWebサイト処理装� ��370は、まず、WebAPI呼び出し1101を実施する。 引数として、呼び出し方法、呼び出し先URL、 パラメータ、紹介者識別情報を取る。図9で� �、紹介者識別情報ではなく、セッションIDを 引数として渡していた。

 広告仲介サービス処理装置300が、WebAPI呼� ��出し1101を受けると、セッションIDを生成し� ��貢献者記録406を行う。貢献者記録406では引� ��で渡された紹介者識別情報とセッションID� �組み合わせを貢献者記録テーブル324に格納� �る。

 次に、WebAPIの紹介者識別情報取得1002を行 い、取得したWebAPIの紹介者識別情報を貢献者 記録411にて記録する。

 WebAPI呼び出し1003を実施すと、WebAPI処理装 置で引数で渡された日付が誕生日である有名 人のリストを取得し、呼び出し結果1004とし� �返す。

 WebAPIの結果を得たら、呼び出し結果及び� ��ッションID1102をWebサイトに返す。このとき� ��呼び出し結果1004とセッションIDに加え、広� ��IDや広告を表示するためのリンクの文字列� �一緒に返しても良い。

 実施例4の効果について説明する。図10の� ��理では、Webサイト処理装置から広告仲介サ� ��ビスへの一度のアクセスでセッションIDとWe bAPIの呼び出し結果を取得することが可能で� �る。そのため、ネットワークを跨る通信回� �を減らすことが可能である。

 また、実施例1~3では、セッションIDをまず� �得し、同じセッションIDを用いて複数のWebAPI を呼び出すことが可能であった。この場合、 セッションIDを引き回す処理を実装する必要� ��あった。実施例4では、複数のWebAPIを呼び出 した結果、WebAPIの処理結果と、広告のリンク を返すことにすればセッションIDを引き回す� ��理を行わなくても良い。複数のWebAPIを呼び� ��したい場合は呼び出し毎に広告を載せるこ� ��で対応することが可能である。この場合、W ebAPIと広告が一対一の関係になるため、WebAPI� ��に出力したい広告の種類を限定してWebサイ� ��に表示する
ことが可能となる。

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

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

 例えば、WebサイトAに貼り付けた広告によ る今月の収入が5000円だったとする。Webサイ� �AではWebAPIα、WebAPIβを利用しており、各々の 利用回数が6000回、4000回であったとする。こ� ��はWebAPIの全呼び出し回数の60%と40%にあたる� ��め、5000円のうちWebAPIαには3000円、WebAPIβに� ��2000円を分配する。本例は一例であり、5000� �のうちの一部をWebサイトAに分配したりする� ��法も考えられる。

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

 まず、紹介料算出テーブルを作成し、初� ��化する1202。紹介料算出テーブルには、各Web APIの紹介者識別情報と紹介料のペアであり、 紹介料の初期値は0である。

 次に、Webサイト管理テーブルの行を一行� ��つ順に取得する(この取得した行をWCと呼ぶ) 1203。

 呼び出し回数格納テーブル(紹介者識別情 報と呼び出し回数)を作成し、初期化する1204� ��呼び出し回数の初期値は0である。紹介料合 計値を初期化する1205。紹介料合計値の初期� �は0である。紹介料合計値はステップ1203で取 得したWebサイトを経由して発生した紹介料の 合計値を格納する。WebAPI呼び出し合計回数を 初期化する1206。初期値は0である。WebAPI呼び� ��し合計回数は、ステップ1203で取得したWebサ イトが呼び出した全WebAPIの呼び出し回数を格 納する。

 セッション管理テーブルの生成時刻が紹� ��料を算出したい期間である行を一行ずつ順� ��取得する(この取得した行のデータをSCと呼� ��)1208。貢献者記録テーブルを参照し、SCのセ ッションIDを持つ行を全て取得1208する。貢献 者記録テーブルから取得した行の中に紹介者 識別情報がWCの紹介者識別情報と一致する行� ��ある1209かを調べ、なければステップ1208に� �る。あれば、SCの選択有無の欄が有1210であ� �かを調べ、有であれば紹介料合計値に選択� �の紹介料を加える1211。次に、貢献者記録テ� ��ブルから取得した行を一行ずつ順に取得す� ��(この取得した行のデータをCCと呼ぶ)1212。� �び出し回数格納テーブル内のCCの紹介者識別 情報に対応する行の値に1を加算する1213。WebA PI呼び出し合計回数に1を加算する1214。貢献� �記録テーブルから取得した全ての行の処理� �終えた1215かを確認し、終えていなければス� ��ップ1212に戻る。終えていれば、セッション 管理テーブルの生成時刻が紹介料を算出した い期間である全ての行の処理を終えた1216か� �確認し、終えていなければステップ1207に戻� ��。終えていれば、WebAPI毎の紹介料の分配を� ��める。

 呼び出し回数格納テーブルの行を一行ず� ��順に取得する(この取得した行をYCと呼ぶ)121 7。紹介料算出テーブルのYCの貢献者識別情報 の行に、紹介料合計値×YCの呼び出し回数íWeb API呼び出し合計回数を計算して格納する1218� �呼び出し回数格納テーブルの全ての行の処� �を終えた1219かを確認し、終えていなければ� ��テップ1217に戻る。終えていれば、Webサイト 管理テーブルの全ての行の処理を終えた1220� �を確認し、終えていなければステップ1203に� ��り、次のWebサイトについても同様の処理を� ��施する。

 実施例5では、特定のWebサイトを経由して 得た紹介料を、そのWebサイトが利用したWebAPI に、WebAPIの利用率に応じて分配する方法につ いて示した。実施例5では、実施例1~4で示し� �システムに適用可能な紹介料の振り分け方� �を示したが、利用率に応じた分配を実施す� �場合、セッションIDを利用せずに実現できる 。本実施例ではセッションIDを利用しない実� ��方法について説明する。図13に概念図を示� �。

 セッションIDではなく、Webサイト毎に事� �に決められたキーを用いてWebAPI1302を利用し� ��Webサイト1301を特定する。キーとして広告仲 介者が発行した紹介者識別情報を用いても良 い。

 システム構成を図14に示す。図2と異なる� ��を太線で示す。Webサイト管理テーブル1411に キー1401を追加し、貢献者記録テーブル1413に� ��刻1408、キー1404を追加し、広告要求管理テ� �ブル1412を追加して広告要求時刻1402、キー140 3、広告要求元IP1409を管理可能とし、広告選� �管理テーブル1414を追加して、広告選択時刻1 405、キー1406、広告選択元IP1407を管理可能と� �た。セッション管理テーブル323は削除した� �

 図13を用いて流れを説明する。Webブラウ� �102がWebページ要求111をWebサイト1301に送ると� ��Webサイト1301はAPI呼び出し(キー)1311をWebAPI130 2に対して行う。WebAPI1302はWebサイト1301が送出 したキーが正当なものであることを確認する ために、キー確認(紹介者識別情報及びキー� �送出)1312を実施する。広告仲介サービス1303� �キーが正しいかどうか(Webサイト管理テーブ� ��1411に格納されたキーであるかどうか)を確� �し、キーが正当なものであれば、時刻1408と� ��ー1404とWebAPI1302の紹介者識別情報346を貢献� �記録テーブル1413に格納する。そして、キー� ��認結果1313をWebAPI1302に返す。

 WebAPI1302はキーが正当なものであればWebAPI の処理を実行し、呼び出し結果117をWebサイト 1301に返す。Webサイト1301では、呼び出し結果� ��び広告表示のためのHTML等を埋め込んだ広告 付Webページ(HTML)118を構築してWebブラウザ102に 返す。Webブラウザ102では、広告情報を取得す るために、広告情報要求(キーを送出)1314を広 告仲介サービス1303に送付する。広告仲介サ� �ビス1303では、セッション管理テーブル1412に 、広告要求時刻1402、キー1403、広告要求元IP13 4を追加する。そして、広告情報管理テーブ� �325から適切な広告情報120を取得し返す。Web� �ラウザ102では取得した広告情報を表示する� �

 閲覧者101が広告を選択すると、広告選択( キーを送出)121を広告仲介サービス1303に送出� ��る。広告仲介サービス1303では、広告選択管 理テーブル1414に広告選択時刻1405、キー1406、 広告選択元IP1407を追加する。そして、事業者 のWebサイト106にリダイレクト122する。事業者 のWebサイト106では事業者のWebページ123を返し 、Webブラウザ102はそのWebページを表示する。

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

 ステップ1201~1206までは図12と同様である� �

 次に、ステップ1203で取得したWCに対応す� ��Webサイト毎に紹介料合計値を求める。広告� ��択管理テーブルの広告選択時刻が紹介料を� ��出したい期間である行を一行ずつ順に取得� ��る(この取得した行をKCと呼ぶ)1501。KCのキー がWCのキーと一致1502するなら紹介料合計値に 選択毎の紹介料を加える1211。広告選択管理� �ーブルの広告選択時刻が紹介料を算出した� �期間である全ての行の処理を終えた1503かを� ��認し、終えていなければステップ1501に戻る 。終えていればWCに対応するWebサイトの紹介� ��合計値の算出を終わる。

 次に、WCに対応するWebサイトが利用した� �つ又は複数のWebAPIの呼び出し回数を算出す� �。貢献者記録テーブルの時刻が紹介料を算� �したい期間である行を一行ずつ順位取得す� �(この取得した行をCCと呼ぶ)1504。CCのキーがW Cのキーと一致1505するなら呼び出し回数格納� ��ーブル内のCCの紹介者識別情報に対応する� �の値に1を加算する1213。WebAPI呼び出し合計回 数に1を加算する1214。貢献者記録テーブルの� ��刻が紹介料を算出したい期間である全ての� ��の処理を終えた1506かを確認し、終えていな ければステップ1504に戻る。終えていれば図12 と同じである、ステップ1217からステップ1221� ��でを実行し、紹介料を算出する。

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

 なお、本実施例の方式では、Webサイト毎� ��既存となるキーを利用しているが、これに� ��して、実施例1~5では、リクエスト毎に生成� ��るセッションIDを用いていたため、WebAPIが� �ばれていないにも関わらず不正にキー確認� �行い、WebAPIが多く呼ばれていると見せかけ� �、という不正を働くことを困難とする利点� �有する。

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

 図16に概念図を示す。図1ではリクエスト� ��都度、広告仲介サービスにセッションID確� �115及びセッションID確認結果116の取得を行っ ていたが、図16ではWebサイト103、WebAPI104から� ��期的にログを送出1610し、広告仲介サービス 105ではこれを集計することで貢献したWebAPIを 明確にする。

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

 Webサイト処理装置、WebAPI処理装置には、� ��グ管理部1701を配置する。Webサイト処理装置 のログ管理部1701bでは、WebAPIを呼び出したこ� ��をログ1702bとして残す。WebAPI処理装置のロ� �管理部1701cでは、WebAPIが呼び出されたことを ログ1702cに残す。

 ログ1702の例を図18に示す。Webサイトのロ� ��1801、WebAPIのログ1802が各々セッションIDと呼 出時刻、呼出元紹介者識別情報、呼出先紹介 者識別情報をログとして記録する。

 このログ1702は定期的(例えば一ヶ月に一� �等)に広告仲介サービス処理装置に送出する� ��

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

 広告仲介サービス処理装置では、ログ1702 を受け取るとログ集計部1703を用いて集計す� �。

 図19にログ集計部1703のフローチャートを� ��す。ここでは、ログの内容を抽出して、貢� ��者記録テーブル324に格納する作業を行う。� ��ず、WebAPIのログの全行について一行ずつ順� ��取得する(取得した行をLとする)1902。Lの呼� �元紹介者識別情報に対応するWebサイトのロ� �に、LのセッションID、呼出先紹介者識別情� �が一致するログが存在し、お互いの呼出時� �の差が15秒以内1903でないなら不正である可� �性があるため貢献者記録テーブル324には記� �せず、ステップ1902に戻る。ステップ1902に戻 る前に、不正である可能性がある紹介者識別 情報を記録しておき、紹介者識別情報に対応 するWebAPI提供者又はWebサイト運営者に警告を 出したり、WebAPIの利用を停止したりするため に利用しても良い。

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

 ステップ1903が正しいなら、Lのセッショ� �IDと呼出先紹介者識別情報を貢献者記録テー ブルに格納する1904。

 WebAPIのログの全行についての処理を終え� ��1905かを確認し、終えていないならばステッ プ1902に戻る。終えていれば、処理を終了す� �。

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

 また、本実施例ではセッションIDを用い� �が、実施例6と同じくキーを用いる方法も考� ��られる。この場合、ログにはセッションID� �はなく、WebAPIのキーを記録する。キーはWebAP Iの紹介者識別情報と同じであっても良い。

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

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

 WebAPIの種類に応じて広告を変更する方法� ��ついて記述する。

 図20にシステム構成を示す。太枠で囲ん� �部分が新規に追加した箇所である。WebAPI管� �テーブル2010にキーワード2001の欄を追加し、 広告情報格納テーブル2020にもキーワード2002� ��欄を追加した。各キーワードの欄には複数� ��キーワードを登録可能とする。

 WebAPI管理テーブル2010のキーワード2001の� �にはWebAPI毎にそのWebAPIに関連するキーワー� �を登録しておく。例えば、有名人の誕生日� �通知するWebAPIであった場合、キーワードと� �て「有名人」、「誕生日」を登録すること� �考えられる。

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

 例えば、図1における広告情報要求(セッ� �ョンIDを送出)119を広告仲介サービス106が受� �取ると貢献者記録テーブル323から受け取っ� �セッションIDと一致するセッションIDを含む� ��を探し、その行に含まれる紹介者識別情報3 46を求め、WebAPI管理テーブル2010からその紹介 者識別情報を含む行のキーワード2001(複数)を 抽出する。次に、広告情報格納テーブル2020� �ら取得したキーワードの何れかを含む広告� �探し、見つけた行を広告情報120としてWebブ� �ウザに返す。複数の行を見つけた場合は最� �多くのキーワードがマッチするものを採用� �たり、ランダムで選択したりする。

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

 これまでの実施例ではWebAPIの利用状況の� ��てを広告仲介サービスで集計していた。全� ��の利用状況を集計するのではなく、特定の� ��間(毎月の最初の週だけ、毎週水曜日だけ、 毎日10時-12時の間だけ、または不定期等)だけ 利用状況を集計することで集計の負荷を軽減 する方法も考えられる。

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

 以上、本発明には、WebAPI提供者、Webサイ� ��運営者、広告仲介者の3者が登場する。本発 明が、各々にもたらす効果について下記に示 す。

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

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

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