JP6329285B1 - 更新装置、更新方法及び更新プログラム - Google Patents

Abstract

【課題】不正な取引の発生を抑制すること。【解決手段】本願に係る更新装置は、受付部と、判定部と、更新部とを有する。受付部は、所定のサービスを受ける権利の販売に関する通報をユーザから受け付ける。判定部は、受付部によって受け付けられた通報によって特定される権利が、非正規であるか否かを判定する。更新部は、判定部によって判定された結果に基づいて、所定のサービスを受ける権利の枠数を更新する。例えば、判定部は、通報によって特定される権利が、予め当該権利に設定されていた価格よりも、当該権利に対応する商取引において高い価格が設定されていた場合に、当該権利を非正規と判定する。【選択図】図１

Description

本発明は、更新装置、更新方法及び更新プログラムに関する。

近年、インターネットの飛躍的な普及に伴い、オークションサービス等の個人間取引を仲介するサイトが人気を博している。個人間取引サイトでは、例えば、イベントやコンサートなどの興行に関するチケットの売買が行われる。しかしながら、このような個人間取引では、正規の価格よりも高い値段でチケットを転売するような規約に反した行為が行われたり、偽造されたチケットが販売されたりする場合もある。

このような商取引に関する技術として、チケットと生体認証情報とを対応付けることにより、当該チケットに関して正当に権利を有する者のみが所定のサービスを受けることができるようにするための技術が知られている。

特開２０１４−６７１７５号公報

しかしながら、上記の従来技術では、不正な取引の発生を抑制することができるとは限らない。すなわち、上記の従来技術は、チケットと正当なユーザとを紐づけるものであり、チケットの不正取得者による不正使用を防止することは可能となるものの、チケットの取引自体に効果が及ぶものではない。このことから、従来技術によっても、高額転売などの不正な取引や、偽造チケットの販売行為などは発生し得る。このため、誤って不正なチケットを購入した利用者は、認証の結果、正当なユーザではないと判定されてしまい、チケットを購入したにもかかわらずサービスを受けることができないといった事態も起こり得る。また、インターネットを介した商取引は膨大な数に及ぶため、個人間取引を仲介するサイト運営者等が全ての取引を監視することも現実的ではない。

本願は、上記に鑑みてなされたものであって、不正な取引の発生を抑制することができる更新装置、更新方法及び更新プログラムを提供することを目的とする。

本願に係る更新装置は、所定のサービスを受ける権利の販売に関する通報をユーザから受け付ける受付部と、前記受付部によって受け付けられた通報によって特定される権利が、非正規であるか否かを判定する判定部と、前記判定部によって判定された結果に基づいて、前記所定のサービスを受ける権利の枠数を更新する更新部と、を備えたことを特徴とする。

実施形態の一態様によれば、不正な取引の発生を抑制することができるという効果を奏する。

図１は、実施形態に係る更新処理の一例を示す図である。 図２は、実施形態に係る更新処理システムの構成例を示す図である。 図３は、実施形態に係る更新装置の構成例を示す図である。 図４は、実施形態に係るイベントテーブルの一例を示す図である。 図５は、実施形態に係るチケットテーブルの一例を示す図である。 図６は、実施形態に係る商取引情報記憶部の一例を示す図である。 図７は、実施形態に係る特典情報記憶部の一例を示す図である。 図８は、実施形態に係るウェブサーバの構成例を示す図である。 図９は、実施形態に係る処理手順を示すフローチャートである。 図１０は、更新装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係る更新装置、更新方法及び更新プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る更新装置、更新方法及び更新プログラムが限定されるものではない。また、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．更新処理の一例〕
まず、図１を用いて、実施形態に係る更新処理の一例について説明する。図１は、実施形態に係る更新処理の一例を示す図である。図１では、本願に係る更新装置１００が、所定のサービスを受ける権利の販売に関する通報をユーザから受け付け、その通報によって特定された権利が非正規であるか否かを判定し、判定結果に基づいて、その権利の対象物と対応付けられた権利を失効させることで、所定のサービスを受ける権利の枠数を更新する更新処理を実行する一例を示す。

図１に示す更新装置１００は、所定のサービスを受ける権利の枠数を更新する更新処理を実行するサーバ装置である。なお、実施形態では、所定のサービスとして、コンサートやミュージカル等のイベントを例に挙げる。また、実施形態では、所定のサービスを受ける権利の対象物とは、例えばイベントのチケットを示す。すなわち、実施形態では、所定のサービスを受ける権利に関する商取引（権利の販売）とは、個人間の取引を仲介する商取引サイト（例えば、オークションサイトや個人間売買を行うことができるショッピングサイト）等における、チケットを商材とする商取引のことを示す。なお、実施形態では、チケットとして、イベントに関する情報等が印字された紙媒体であるものを例に挙げるが、チケットは電子データ等であってもよい。また、実際には、サービスを受ける権利はチケットのような対象物として具現化されることが一般的であるが、サービスを受ける権利とはユーザに与えられる権限であり、その権限が具現化されたものが対象物（チケット等）であるに過ぎない。このため、実施形態では、このような「権利の対象物」を表記する場合についても、「権利」とのみ表記する場合がある。

図１に示すユーザ端末１０は、ユーザによって利用される情報処理端末である。例えば、ユーザ端末１０は、スマートフォンやタブレット端末である。ユーザ端末１０は、ユーザの操作に従い、ネットワーク上のサービスを利用する。例えば、ユーザ端末１０は、商取引サイトにアクセスし、チケットに関する問い合わせを行ったり、チケットの購買申込みを行ったりする。なお、実施形態では、ユーザ端末１０をユーザと読み替える場合がある。例えば、「ユーザが商取引サイトにアクセスする」という記載は、実際には、「ユーザによって操作されたユーザ端末１０が商取引サイトにアクセスする」という状況を示す場合がある。図１の例では、ユーザ端末１０は、ユーザの一例であるユーザＵ０１によって操作されるものとする。

図１に示した更新装置１００は、例えば、イベントを開催する興行主や、興行主に代理してチケットを販売する事業者等によって管理される。更新装置１００は、例えば、イベントに参加する権利をチケットという態様で発行する。興行主は、発行されたチケットをユーザに販売する。一般に、コンサート等のイベントでは、イベントの開催日の前にチケットが前売りされる。このため、チケットは、イベント開催の前に既にイベントの参加を希望するユーザに渡っているか、もしくは、チケットを受け取る権利がユーザに渡っている状況（発券待ち状態）である。

ここで、このようなイベントのチケットは、様々な理由で転売が行われる。例えば、イベントに参加する予定であったが都合が悪くなったり、イベントに興味を失ったりした等の理由で、イベントに参加しない予定となったユーザは、商取引サイトの商材としてチケットを出品する。一方で、人気のあるイベントの場合、チケットが完売した等の理由により、参加したくてもチケットを購入できなかったユーザも存在する。このようなユーザは、正規な流通経路でないと知りながら、転売されたチケットの購入を希望する場合がある。このような需要と供給の関係から、商取引サイトにおけるチケットの転売は盛んに行われる。

しかしながら、商取引サイトでは価格の設定が出品者に委ねられるため、元の定価を超えた値段が付けられたチケットが出品されること（以下、「高額転売」と表記する）がある。このような高額転売が許容される場合、転売自体を目的としてチケットを購入する者が増加し、イベントに参加を希望していたユーザがチケットを購入できなくなるおそれがある。また、何としてもイベントに参加を希望するユーザは、定価よりも高額で出品されたチケットを購入するしか手段がなくなるため、正規な流通経路で購入するよりも不利益が生じる。

このようなことから、一般にチケットの高額転売は興行主側の規約で禁止されていたり、法的な規制が掛けられていたりする。なお、チケットには識別子（バーコードやＱＲコード（登録商標）等）が印字されることから、転売されたチケットが特定できれば、そのチケットを無効化するなどの対策をとることができる。しかし、このような規約に反する不正な転売チケットは、上記のように一定の需要もあることから商取引サイト等に出品される数も多く、全てを興行主側で特定して排除することは困難な状態にある。また、人気のあるイベントでは、悪意のある者によって精巧な偽造チケットが発行され、偽造チケットが商取引サイトに出回ることがある。このようなチケットの商取引についても、全てを興行主側で特定するよう監視することは困難である。

そこで、実施形態に係る更新装置１００は、以下に説明する更新処理を実行することで、このような高額転売チケットや偽造チケット等に関する商取引を抑制する。以下、図１を用いて、更新装置１００によって行われる更新処理の一例を流れに沿って説明する。

図１に示す例において、ユーザＵ０１は、所定のイベントに参加することを希望し、イベントのチケットを商取引サイトで探しているユーザであるものとする。例えば、ユーザＵ０１は、公演名が「ＸＸＸ」であるイベントのチケットを購入しようとしたものの、正規な流通経路によるチケットが売り切れていたため、イベントのチケットを購入できていないユーザである。

そこで、ユーザＵ０１は、ユーザ端末１０を操作し、ウェブサーバ３０（図１での図示は省略）にアクセスすることで、ウェブサーバ３０が提供する商取引サイトを利用する（ステップＳ１１）。そして、ユーザＵ０１は、例えば公演名である「ＸＸＸ」を検索クエリとして商取引サイト内で行われている商取引を検索し、イベントのチケットの出品状況を閲覧する。

図１の例では、ユーザＵ０１は、商取引Ａ０１において、自身が所望するイベントのチケットが出品されていることを発見したものとする。商取引Ａ０１には、イベントの公演名や開催日時等の情報や、チケットの価格等の出品情報が含まれる。また、商取引Ａ０１には、出品者がチケットを撮像した画像Ｐ０１が含まれる。例えば、出品者は、自身が本当にチケットを所有していることや、チケットが不正なものでないことをユーザに提示するために、チケットの識別子（図１の例ではバーコード）が撮像された画像Ｐ０１をアップロードする。すなわち、商取引Ａ０１では、このような出品者からアップロードされた画像Ｐ０１がユーザＵ０１に提示されることで、当該チケットが不正なものでないことを担保する。

ここで、ユーザＵ０１は、商取引Ａ０１に関するチケットが、定価よりも高い価格で販売されていることを知得したものとする。例えば、ユーザＵ０１は、公演名が「ＸＸＸ」であるイベントのチケットの正規価格（定価）が「８０００円」であるのに対して、商取引Ａ０１に関するチケットの価格には「５００００円」が付けられていることを知得する。

この場合、ユーザＵ０１は、商取引Ａ０１が高額転売であり、不正な取引であると認定する。すなわち、ユーザＵ０１は、商取引Ａ０１が非正規な商取引であるものと認定する。この場合、ユーザＵ０１は、かかる情報を更新装置１００に通報する。具体的には、ユーザＵ０１は、商取引Ａ０１を示すウェブページ内に含まれるボタンであって、「このチケットを通報する」というメッセージが付与されたボタンＱ０１を選択（クリックやタッチ）することにより、商取引Ａ０１に関するチケットが不正である旨を通報する（ステップＳ１２）。

更新装置１００は、ユーザＵ０１から通報があった場合、まず、通報に係るチケットを識別する。例えば、更新装置１００は、通報された商取引Ａ０１に関する情報を取得し、取得した情報に基づいて、通報に係るチケットを識別する。一例として、更新装置１００は、商取引Ａ０１に含まれる情報として、画像Ｐ０１を利用する。例えば、更新装置１００は、画像Ｐ０１に対して画像認識処理を行い、画像Ｐ０１に含まれる識別子（バーコード）を読み取る。そして、更新装置１００は、自身が発行した際に付与した識別子と、画像Ｐ０１に含まれる識別子とを対照させることにより、商取引Ａ０１に関するチケットを識別する。そして、更新装置１００は、識別されたチケットが、商取引Ａ０１のイベントに対応したチケットであるという整合性がとれるか否かを判定する。

例えば、商取引Ａ０１において出品されたチケットが偽造チケットであったり、そもそも商取引Ａ０１のイベントに対応していないチケットであったり（例えば、画像Ｐ０１に写っているチケットが、異なるイベントのチケットであった場合等）する場合がありうる。この場合、更新装置１００は、商取引Ａ０１のイベントと、商取引Ａ０１のチケットとは整合性がとれないものと判定する。更新装置１００は、整合性がとれないと判定した場合には、例えば、商取引サイト側に警告を送信したり、商取引Ａ０１を停止させたりする処理を行う。

一方、更新装置１００は、通報によって特定されたチケットと、商取引Ａ０１に記載されたイベントとの対応について整合性がとれた場合には、さらに、チケットが不正なものであるか否かを判定する（ステップＳ１３）。具体的には、更新装置１００は、もともと発行時にデータベース化されていた情報であって、商取引Ａ０１のチケットに含まれる情報（イベントの公演名や、イベントの開催日時や、チケットに設定されていた定価等）を参照する。さらに、更新装置１００は、チケットに設定されていた定価と、商取引Ａ０１において設定されていた価格とを比較する。そして、更新装置１００は、商取引Ａ０１において設定されていた価格が、チケットに設定されていた定価よりも高額である場合、商取引Ａ０１を非正規な取引と判定する。言い換えれば、更新装置１００は、商取引Ａ０１において出品されていたチケットを不正なチケットと判定する。

この場合、更新装置１００は、不正と判定したチケットから、チケットが有する効力を失効させる。具体的には、更新装置１００は、管理するデータベースにおいて、商取引Ａ０１に係るチケットが、有していた権利を失効したことを示す情報を付与する。すなわち、商取引Ａ０１に係るチケットは、当該チケットに対応するイベントにユーザを参加させることができないチケットとして扱われる。さらに、更新装置１００は、商取引Ａ０１のチケットを無効とすることで発生した余剰分を、イベントの本来の枠数に追加するよう更新する（ステップＳ１４）。

具体的には、更新装置１００は、無効とした商取引Ａ０１のチケット分の余剰枠について、さらにイベントに参加するユーザを募ることができるよう、イベントの枠数（すなわち、余剰枠）を更新する。例えば、更新装置１００は、商取引Ａ０１のチケットが「１人分」のチケットであった場合、イベントの余剰枠を「１人分」増加させる。これにより、更新装置１００は、高額転売等の不正な取引を発生させた出品者（もしくは、高額転売されたチケットを購入した購入者）に代わり、新たにイベントに参加するユーザを募ることができる。

さらに、更新装置１００は、不正な取引を通報したユーザＵ０１に対して所定の特典を生成する。すなわち、更新装置１００は、通報によって特定されたチケットが非正規であると判定された場合に、当該通報を行ったユーザＵ０１に対して付与される特典であって、通報したイベントに関する特典を生成する。例えば、更新装置１００は、特典として、通報したユーザＵ０１に、その通報に係るチケットの申し込み権利を付与する（ステップＳ１５）。

具体的には、更新装置１００は、ユーザＵ０１が通報したチケットを無効にするとともに、無効にしたことにより発生した余剰分のチケットを定価で購入する権利をユーザＵ０１に優先的に付与する。そして、更新装置１００は、その旨をユーザＵ０１に通知する。ユーザＵ０１は、購入を希望する場合には、通報したことにより発生した余剰分のチケットを定価で購入することができる。

このように、実施形態に係る更新装置１００は、所定のサービスを受ける権利に関する商取引（すなわち、イベントのチケットに関する販売）のうち、当該権利が非正規である旨を示す通報をユーザＵ０１から受け付ける。そして、更新装置１００は、受け付けられた通報によって特定される権利が非正規であるか否かを判定する。さらに、更新装置１００は、非正規と判定された権利から、所定のサービスを受ける権利を失効させることにより、所定のサービスを受ける権利の枠数を更新する。

すなわち、更新装置１００は、商取引サイトを利用するユーザＵ０１から通報を受け付ける構成を有することにより、全ての商取引サイトの商取引情報を監視することなく、不正な取引を特定することができる。例えば、商取引サイトを利用するユーザＵ０１とは、自身がイベントに参加することを希望するユーザであることが想定される。そして、このようにイベントに参加することを希望するユーザは、１つでもイベントに参加するための枠が空くことを期待する。そして、更新装置１００は、このようなユーザからの通報を受け付けるとともに、通報されたチケットを不正と判定した場合、そのチケットを無効とすることで余剰枠を発生させるよう、イベントの参加枠数を更新する。このような処理により、ユーザＵ０１は積極的に通報を行うことになるため、更新装置１００は、自身が全ての商取引情報を監視することなく不正な取引を精度良く抽出することができるとともに、本来の金額でイベントに参加できる余剰枠を増やすことができる。また、更新装置１００は、不正な取引であると判定した場合、チケットの識別子等に基づいて、転売者や、高額転売されたチケットを購入したユーザから、イベントに参加する権利を失効させる。これにより、更新装置１００は、そもそも高額転売をしようとしたり、高額転売されたチケットを購入しようとしたりする行動を抑えることができる。結果として、更新装置１００は、不正な取引の発生を抑制することができる。以下、このような処理を行う更新装置１００、及び、更新装置１００を含む更新処理システム１の構成等について、詳細に説明する。

〔２．更新処理システムの構成〕
次に、図２を用いて、実施形態に係る更新装置１００が含まれる更新処理システム１の構成について説明する。図２は、実施形態に係る更新処理システム１の構成例を示す図である。図２に例示するように、実施形態に係る更新処理システム１には、ユーザ端末１０と、ウェブサーバ３０と、更新装置１００とが含まれる。これらの各種装置は、ネットワークＮを介して、有線又は無線により通信可能に接続される。なお、図２に示した更新処理システム１には、複数台のユーザ端末１０や、複数台のウェブサーバ３０が含まれてもよい。

ユーザ端末１０は、例えば、スマートフォンや、デスクトップ型ＰＣ（Personal Computer）や、ノート型ＰＣや、タブレット型端末や、携帯電話機、ＰＤＡ（Personal Digital Assistant）、ウェアラブルデバイス（Wearable Device）等の情報処理装置である。ユーザ端末１０は、ユーザによる操作に従って商取引サイトにアクセスし、商取引サイトを介して、不正な商取引を更新装置１００に通報する処理を行う。

ウェブサーバ３０は、ユーザ端末１０からアクセスされた場合に、コンテンツ（例えば、ウェブページ）を提供するサーバ装置である。実施形態では、ウェブサーバ３０は、所定の商取引サイトを提供する。例えば、ウェブサーバ３０は、オークションサイトや、個人間取引が可能なショッピングサイト等を提供する。また、ウェブサーバ３０は、例えば個人間取引に限らず、転売されるチケット等を商材として取り扱うショッピングサイト等を提供してもよい。

なお、ウェブサーバ３０によって提供されるウェブページには、広告を表示するための表示領域である広告枠や、商材に関するレコメンドを表示するための表示領域であるレコメンド枠が含まれてもよい。

更新装置１００は、所定のサービスを受ける権利に関する商取引情報のうち、権利が非正規である旨を示す通報をユーザから受け付け、受け付けられた通報によって特定される権利が非正規であるか否かを判定し、非正規と判定した場合には、当該権利を失効させることにより、所定のサービスを受ける権利の枠数を更新する更新処理を行うサーバ装置である。

なお、実施形態に係る更新装置１００は、商取引サイトを運営や管理したり、事業者からアップロードされた情報を管理したりするような、ウェブサーバ３０としての構成を兼ねてもよい。すなわち、更新装置１００とウェブサーバ３０とは、別個の装置であってもよいし、双方の機能を兼ねる装置によって実現されてもよい。

〔３．更新装置の構成〕
次に、図３を用いて、実施形態に係る更新装置１００の構成について説明する。図３は、実施形態に係る更新装置１００の構成例を示す図である。図３に示すように、更新装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、更新装置１００は、更新装置１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。かかる通信部１１０は、ネットワークＮと有線又は無線で接続され、ネットワークＮを介して、ユーザ端末１０や、ウェブサーバ３０との間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１２０は、イベント情報記憶部１２１と、商取引情報記憶部１２５と、特典情報記憶部１２６とを有する。

（イベント情報記憶部１２１について）
イベント情報記憶部１２１は、商取引サイトにアップロードされる商材に関する情報を記憶する。図３に示すように、イベント情報記憶部１２１は、データテーブルとして、イベントテーブル１２２と、チケットテーブル１２３とを有する。以下、各データテーブルについて順に説明する。

（イベントテーブル１２２について）
イベントテーブル１２２は、イベントに関する情報を記憶する。ここで、図４に、実施形態に係るイベントテーブル１２２の一例を示す。図４は、実施形態に係るイベントテーブル１２２の一例を示す図である。図４に示した例では、イベントテーブル１２２は、「イベントＩＤ」、「イベント名」、「開催日時」、「開催地」、「会場」、「定員」、「販売済みチケット」、「余剰枠」といった項目を有する。

「イベントＩＤ」は、イベントを識別するための識別情報を示す。なお、実施形態において、イベントＩＤのような識別情報は、説明で用いる参照符号と共通するものとする。例えば、イベントＩＤが「Ｅ０１」であるイベントを「イベントＥ０１」と表記する場合がある。

「イベント名」は、イベントの名称を示す。「開催日時」は、イベントが開催される日時を示す。「開催地」は、イベントが開催される地名を示す。「会場」は、イベントが開催される会場名を示す。「定員」は、イベントの定員を示す。「販売済みチケット」は、現時点において販売されたチケットの枚数を示す。

「余剰枠」は、現時点で余っているイベントへの参加枠の数を示す。通常、イベントにおける余剰枠とは、定員から販売済みチケットの数を引くことによって算出されるが、実施形態では、後述する更新処理によってイベントへの参加枠が追加される場合がある。このため、実施形態では、全てのチケットが販売済みとなった後でも余剰枠が「０」とならない場合がある。図４に示す例では、余剰枠が「１５」となっているが、この数値は、あと「１５」人が、イベントＥ０１に新たに参加する権利を取得する可能性があることを示している。

すなわち、図４に示したデータの一例は、イベントＩＤ「Ｅ０１」によって識別されるイベントＥ０１におけるイベント名は「ＸＸＸ」であり、開催日時は「２０１７年２月１０日」であり、開催地は「東京」であり、会場は「ＹＹＹ」であり、イベントの定員は「３００００人」であり、販売済みチケットは「３００００枚」であり、現時点での余剰枠が「１５」であることを示している。

（チケットテーブル１２３について）
チケットテーブル１２３は、各イベントにおけるチケットの情報を記憶する。ここで、図５に、実施形態に係るチケットテーブル１２３の一例を示す。図５は、実施形態に係るチケットテーブル１２３の一例を示す図である。図５に示した例では、チケットテーブル１２３は、「イベントＩＤ」、「定価」、「チケット情報」といった項目を有する。また、チケット情報は、「チケットＩＤ」、「販売状況」、「購入者情報」、「バーコード情報」、「効力」、「無効理由」といった小項目を有する。

「イベントＩＤ」は、図４に示した同一の項目に対応する。「定価」は、興行主等によって予め設定された定価を示す。「チケット情報」は、チケットに関する情報を示す。

「チケットＩＤ」は、チケットを識別する識別情報を示す。「販売状況」は、チケットの販売状況を示す。「購入者情報」は、チケットを購入したユーザの情報（ユーザを識別する識別情報）を示す。

「バーコード情報」は、チケットに印字されたバーコードに関する情報を示す。なお、図５に示した例では、バーコード情報を「Ｂ０１」のような概念で示しているが、実際には、バーコード情報の項目には、例えばチケットを一意に特定する情報（イベントＩＤや開催日時等）が紐づけられて記憶されるものとする。なお、チケットを一意に特定する情報は、バーコードに限られなくてもよい。例えば、チケットを一意に特定する情報は、バーコードでなく、所定数の数値の羅列や、ＱＲコード（登録商標）等であってもよい。すなわち、チケットを一意に特定する情報は、チケットを識別するための識別子であればいずれの情報であってもよい。また、識別子は、視認可能なものでなくてもよい。例えば、識別子は、更新装置１００による画像解析であれば識別可能な情報であって、視認のできない識別子（いわゆるステガノグラフ等）であってもよい。

「効力」は、イベントに参加する権利としての効力をチケットが有しているか否かを示す。チケットが、イベントに対して効力を有する場合、すなわち、チケットが「イベントに参加する権利」としての効力を有している場合、「効力」の項目には「１」が記憶される。しかし、上述のように、更新装置１００は、チケットの効力を失効させる場合がある。更新装置１００がチケットの効力を失効させた場合、「効力」の項目は、「１」から「０」に情報が更新される。効力の項目に「０」が記憶されたチケットは「イベントに参加する権利」を失うため、そのチケットを所有するユーザは、イベントに参加することができなくなる。「無効理由」は、チケットが効力を失うことになった理由を示す。

すなわち、図５に示したデータの一例は、イベントＩＤ「Ｅ０１」によって識別されるイベントＥ０１におけるチケットの定価は「８０００円」であることを示している。また、イベントＥ０１におけるチケットの一例として、チケットＩＤ「Ｔ０１」で識別されるチケットＴ０１は、販売状況が「販売済み」であり、購入者は「Ｕ１１」であり、バーコード情報は「Ｂ０１」であり、効力は「０」であり、効力が「０」となった無効理由は「高額転売」であったことを示している。

（商取引情報記憶部１２５について）
商取引情報記憶部１２５は、チケットを商材とする商取引に関する情報を記憶する。ここで、図６に、実施形態に係る商取引情報記憶部１２５の一例を示す。図６は、実施形態に係る商取引情報記憶部１２５の一例を示す図である。図６に示した例では、商取引情報記憶部１２５は、「商取引ＩＤ」、「商取引サイトＩＤ」、「通報者ＩＤ」、「チケットＩＤ」、「特定情報」、「商取引情報」、「判定結果」といった項目を有する。

「商取引ＩＤ」は、個々の商取引を識別する識別情報を示す。「商取引サイトＩＤ」は、商取引が行われているサイトを識別する識別情報を示す。なお、実施形態では、商取引が行われる媒体の一例として商取引サイトを挙げているが、媒体は、ウェブサイトに限られない。例えば、媒体は、個人間取引を仲介するアプリ等であってもよい。この場合、商取引サイトＩＤには、個人間取引を仲介するアプリを識別する情報が記憶される。

「通報者ＩＤ」は、チケットの不正を通報した通報者（ユーザ）を識別する識別情報を示す。「チケットＩＤ」は、図５に示した同一の項目に対応する。「商取引情報」は、商取引に関する種々の情報を示す。なお、図６に示した例では、商取引情報を「Ｃ０１」のような概念で示しているが、実際には、商取引情報の項目には、商取引においてチケットに付けられた価格や、チケットへの入札状況や、チケットの落札情報や、チケットを落札したユーザの識別情報や、商取引が開始された日時や、商取引の終了日時等、商取引に関するあらゆる情報が記憶される。

「特定情報」は、更新装置１００がチケットを特定する契機となった情報の種別を示す。例えば、更新装置１００が商取引サイトに掲載された画像Ｐ０１を画像解析することによってチケットを特定した場合、特定情報は、「画像Ｐ０１」（より詳細には、画像Ｐ０１に含まれるバーコード）となる。

「判定結果」は、後述する判定処理によってチケットが正規か非正規かが判定された結果を示す。判定は、例えば興行主や更新装置１００の管理者によって予め定められた所定の規約（ポリシー）に基づいて行われ、規約に従っている商取引に係るチケットは「正規」とされ、規約に反している商取引に係るチケットは「非正規」とされる。例えば、高額転売等が行われている商取引は、規約に反している商取引であるとされ、当該商取引に係るチケットは、「非正規」と判定される。

すなわち、図６に示したデータの一例は、商取引ＩＤ「Ａ０１」で識別される商取引Ａ０１は、商取引サイトＩＤ「Ｗ０１」で識別される商取引サイトＷ０１で行われている商取引であることを示している。また、商取引Ａ０１を通報したユーザは「Ｕ０１」であり、商取引Ａ０１に係るチケットＩＤは「Ｔ０１」であり、チケットＴ０１を特定するために利用された特定情報は「画像Ｐ０１」であることを示している。また、商取引Ａ０１に関する商取引情報は「Ｃ０１」であり、商取引Ａ０１（及び、商取引Ａ０１に係るチケットＴ０１）は、通報における判定結果として「非正規」と判定されたことを示している。

（特典情報記憶部１２６について）
特典情報記憶部１２６は、不正な商取引を通報したユーザに対して生成される特典に関する情報を記憶する。ここで、図７に、実施形態に係る特典情報記憶部１２６の一例を示す。図７は、実施形態に係る特典情報記憶部１２６の一例を示す図である。図７に示した例では、特典情報記憶部１２６は、「特典ＩＤ」、「ユーザＩＤ」、「商取引ＩＤ」、「通報回数」、「特典内容」といった項目を有する。

「特典ＩＤ」は、特典を識別する識別情報を示す。「ユーザＩＤ」は、ユーザを識別する識別情報を示す。なお、ユーザＩＤは、図６で示した通報者ＩＤと共通するものとする。「商取引ＩＤ」は、ユーザが通報した商取引を識別する識別情報を示す。「通報回数」は、ユーザが通報を行った数を示す。なお、実施形態では、通報回数は、イベントごと、かつ、ユーザごとに集計されるものとする。しかし、更新装置１００は、イベントによらず、通報回数をユーザごとに累積的に集計してもよい。

「特典内容」は、特典の内容を示す。例えば、特典内容は、通報したイベントのチケットを定価で購入する権利であったり、通報したイベントに関連するイベントのチケットを優先的に購入する権利であったりする。なお、特典内容は、例えば、イベントや通報回数に応じて、異なる内容が生成されてもよい。

すなわち、図７に示したデータの一例は、特典ＩＤ「Ｆ０１」で識別される特典Ｆ０１は、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１に対して生成された特典であり、その特典が生成される契機となった商取引の商取引ＩＤは「Ａ０１」であり、ユーザＵ０１の通報回数が「１」回目の際に生成された特典であることを示している。また、その特典内容は、「イベントＥ０１のチケット購入」であることを示している。また、図７に示したデータの他の一例は、特典ＩＤ「Ｆ１１」で識別される特典Ｆ１１であり、特典Ｆ１１はユーザＵ０１が通報を「７」回行った際に生成された特典であり、その特典内容は、「イベントＥ０１の関連イベントのチケット優先購入」であることを示している。

（制御部１３０について）
制御部１３０は、例えば、コントローラ（controller）であり、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、更新装置１００内部の記憶装置に記憶されている各種プログラム（更新プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、コントローラであり、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図３に示すように、制御部１３０は、受付部１３１と、取得部１３２と、判定部１３３と、更新部１３４と、生成部１３５と、送信部１３６とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図３に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図３に示した接続関係に限られず、他の接続関係であってもよい。

（受付部１３１について）
受付部１３１は、種々の情報を受け付ける。例えば、受付部１３１は、所定のサービスを受ける権利に関する商取引情報のうち、当該権利の販売が非正規である旨を示す通報をユーザから受け付ける。

具体的には、受付部１３１は、イベントに参加する権利に関する商取引（すなわち、チケットの売買）のうち、当該商取引や、当該商取引に係る対象物（）が非正規である旨を示す通報をユーザから受け付ける。例えば、受付部１３１は、図１に示すボタンＱ０１をユーザが選択（クリックやタッチ）したことを契機として、ボタンＱ０１が設置されている商取引Ａ０１に係るチケットが非正規である旨の通報をユーザから受け付ける。

受付部１３１は、受け付けた情報を取得部１３２等の処理部に送る。なお、受付部１３１は、受け付けた情報を記憶部１２０に格納するようにしてもよい。

（取得部１３２について）
取得部１３２は、各種情報を取得する。例えば、取得部１３２は、受付部１３１によってユーザからの通報が受け付けられた場合に、当該通報に関する情報を取得する。

例えば、取得部１３２は、通報を行ったユーザに関する情報を取得する。例えば、取得部１３２は、ウェブサーバ３０を介して、ユーザのクッキー情報等の識別情報を取得する。そして、取得部１３２は、当該識別情報に基づいて、ユーザを特定する情報を取得する。また、取得部１３２は、ユーザを識別した場合、当該ユーザが通報を行なった回数や、通報を行ったイベントなど、過去の通報履歴を取得する。

また、取得部１３２は、ユーザが通報を行った商取引に関する情報を取得する。例えば、取得部１３２は、通報された商取引を特定する情報や、商取引を仲介しているサイトに関する情報等を取得する。

また、取得部１３２は、商取引に係るチケットに関する情報を取得する。例えば、取得部１３２は、チケットを特定する情報を取得する。一例として、取得部１３２は、商取引サイトに掲載された画像を取得する。そして、取得部１３２は、当該画像にチケットの識別子が含まれる場合、当該識別子に関する情報を取得する。例えば、取得部１３２は、画像に含まれるバーコード情報を取得する。

また、取得部１３２は、チケットを特定する情報として、商取引に関するテキスト情報を取得してもよい。例えば、商取引では、チケットを説明するための説明文を出品者が付与することがある。このため、取得部１３２は、かかる説明文のテキストデータを取得してもよい。

例えば、取得部１３２は、テキスト情報に含まれる情報として、チケットを識別するための識別子や、チケットに対応するイベントの開催地や開催日時、及び、イベントにおける当該チケットに対応する座席情報等を取得する。この場合、取得部１３２は、商取引に付与された説明文を形態素解析する等、既知の技術を適宜利用するようにしてもよい。

また、取得部１３２は、商取引に関する情報として、商取引に係るチケットに付与されている価格を取得する。また、取得部１３２は、後述する判定部１３３によってチケットが特定された場合、当該チケットに予め設定されている価格（定価）を取得する。これにより、判定部１３３は、当該チケットが、定価よりも高く転売されているチケットであるか否かを判定することができる。

また、取得部１３２は、上記の各種情報について、興行主や、更新装置１００の管理者から取得してもよい。取得部１３２は、取得した情報を記憶部１２０内に適宜格納する。例えば、取得部１３２は、商取引に係るイベントに関する情報をイベント情報記憶部１２１に格納する。

（判定部１３３について）
判定部１３３は、受付部１３１によって受け付けられた通報によって特定される権利（例えば、権利の対象物であるチケット）が非正規であるか否かを判定する。

例えば、判定部１３３は、興行主や更新装置１００の管理者等によって予め定められた所定の規約に基づいて、通報された商取引や、商取引に係るチケットが非正規であるか否かを判定する。具体的には、判定部１３３は、規約に従っている商取引や、当該商取引に係るチケットは「正規」と判定し、規約に反している商取引や、当該商取引に係るチケットは「非正規」と判定する。なお、更新装置１００は、このような規約を格納するデータテーブルを記憶部１２０内に備えていてもよいし、ネットワークを介して、このような規約が記憶されたメモリ等を参照するようにしてもよい。

一例として、判定部１３３は、商取引に係るチケットが転売されている行為を規約に反する行為と判定し、チケットが転売されていると判定した時点で、当該商取引に係るチケットを「非正規」と判定してもよい。

あるいは、判定部１３３は、定価以下で転売する行為は許容するものの、チケットが定価を超えた価格で転売されている（高額転売されている）と判定した時点で、当該商取引に係るチケットを「非正規」と判定してもよい。すなわち、判定部１３３は、通報によって特定されるチケットが、予め当該チケットに設定されていた価格よりも、当該チケットに対応する商取引情報において高い価格が設定されていた場合に、当該チケットを非正規と判定する。なお、このような規約はあくまで一例であり、判定部１３３は、興行主の設定や、イベント等に応じて、規約（すなわち、判定基準）を柔軟に変更してもよい。

また、判定部１３３は、通報によって特定されるチケットが、イベントを提供する提供側から正規に発行されたチケットでない場合に、当該チケットを非正規と判定するようにしてもよい。具体的には、判定部１３３は、通報された商取引に係るチケットが、偽造チケットである場合に、当該チケットを非正規と判定する。

例えば、判定部１３３は、受付部１３１によって受け付けられた通報によって特定される商取引情報に対応付けられた画像に基づいて、通報によって特定されるチケットを識別する。具体的には、判定部１３３は、画像に含まれる識別子であって、チケットを識別するための識別子に基づいて、通報によって特定されるチケットを識別する。すなわち、判定部１３３は、通報された商取引における画像を解析し、チケットの識別子（例えばバーコード）から、チケットを識別（特定）する。そして、判定部１３３は、チケットの識別子がチケットテーブル１２３に記憶されているチケットの識別子と整合性がとれない場合等（例えば、チケットがコピーされたものであり、他のチケットと重複した識別子を当該チケットが有している場合など）に、当該チケットが偽造されたものと判定する。そして、判定部１３３は、商取引に係るチケットを偽造チケットと判定した場合、チケットを非正規と判定して、チケットから効力を失効させる。

なお、判定部１３３は、受付部１３１によって受け付けられた通報によって特定される商取引情報に対応付けられたテキスト情報に基づいて、通報によって特定されるチケットを識別してもよい。具体的には、判定部１３３は、テキスト情報に含まれる情報であって、チケットを識別するための識別子、チケットに対応するイベントの開催地、開催日時、及び、イベントにおけるチケットに対応する座席情報の少なくとも一つの情報に基づいて、通報によって特定されるチケットを識別する。

例えば、判定部１３３は、商取引情報に記載されたテキストによって示される情報と、データベースに記憶されているチケットの情報とに齟齬が生じる場合、当該チケットについての整合性がとれないと判定する。そして、判定部１３３は、整合性のとれないチケットを取り扱う商取引は非正規なものであると判定する。この場合、判定部１３３は、例えば、チケットや商取引が不正なものである可能性がある旨を商取引サイトの管理者に警告したり、商取引を停止させるようにしたりしてもよい。

（更新部１３４について）
更新部１３４は、判定部１３３によって非正規と判定された権利から、所定のサービスを受ける権利を失効させることにより、所定のサービスを受ける権利の枠数を更新する。なお、権利の枠数とは、所定のサービスを受ける権利の定数と言い換えることもできる。すなわち、権利の枠数とは、例えばイベントに参加するための権利の総数であり、例えば、イベント会場の施設の定員やイベント主催側で定められるイベントの参加人数に基づいて発行されたチケットの数である。権利の枠数を更新するとは、非正規と判定された権利が発生した場合に、その数を更新することを意味する。例えば、現状で「３００００」枚のチケットが発行されていた場合に、１枚の非正規と判定された権利が生じた場合には、更新部１３４は、新たに１枚のチケットを発行することで、イベントに係るチケットの発行数を「３０００１」枚に更新する。すなわち、更新部１３４は、判定部１３３によって判定された結果に基づいて、所定のサービスを受ける権利の対象物の発行数を更新するものでもあり、また、所定のサービスを受ける権利の販売数を更新するものともいえる。

具体的には、更新部１３４は、判定部１３３によって非正規と判定されたチケットと同じ数だけの余剰枠を、当該チケットに対応するイベントの枠に追加する。言い換えれば、更新部１３４は、判定部１３３によって権利が失効させられたことにより、イベントにおいて余ることとなった座席数や入場者数について、そのイベントに参加できる枠を追加する。

例えば、更新部１３４は、判定部１３３によって失効させられたチケットが発生したタイミングで、イベントテーブル１２２に記憶されている余剰枠の項目を更新する。

（生成部１３５について）
生成部１３５は、通報によって特定される権利が非正規であると判定された場合に、当該通報を行ったユーザに対して付与される特典であって、所定のサービスに関する特典を生成する。例えば、生成部１３５は、通報された商取引におけるチケットが非正規と判定された場合、その通報を行ったユーザに対して付与する特典を生成する。

具体的には、生成部１３５は、特典として、通報した商取引におけるイベントに参加するためのチケットを、通報したユーザが新たに購入することのできる権利を生成する。すなわち、生成部１３５は、通報を行ったユーザが、いわば通報を行ったことの褒賞として、通報した商取引に係るイベントに参加するためのチケットを購入するための権利を生成する。一般に、チケットに係る商取引サイトを閲覧するユーザは、そのチケットに対応するイベントへの参加を所望しているユーザであると想定される。生成部１３５は、そのようなユーザへの特典として、新たにチケットを購入するための機会を特典として生成することで、通報することへの動機付けをユーザに与えることができる。

また、生成部１３５は、特典として、所定のサービスに関連するサービスを受ける権利をユーザが優先的に購入する権利を生成してもよい。具体的には、生成部１３５は、通報に係るイベントとは異なるイベントであって、共通する出演者が出演するイベントのチケットを優先的に購入する権利を生成する。

上述のように、チケットに係る商取引サイトを閲覧するユーザは、そのチケットに対応するイベントへの参加を所望しているユーザであると想定される。ここで、イベントに出演する出演者を見たいという思いでイベントへの参加を所望するユーザは、当該イベントに限らず、同じ出演者を別のイベントでも見たいという思いを有していると想定される。このため、生成部１３５は、通報されたチケットに係るイベントに限らず、そのイベントと何らかの関連性を有するイベント（例えば、出演者、イベントのカテゴリ、上演される演目のカテゴリ等が共通したり類似したりするイベント）に参加するためのチケットを優先的に購入することのできる権利を特典として生成してもよい。これにより、生成部１３５は、さらに通報することへの動機付けをユーザに与えることができる。

なお、生成部１３５は、通報によって特定される権利が非正規であると判定された数に応じて、通報を行ったユーザに対して、所定のサービスに関する特典を生成してもよい。例えば、生成部１３５は、１回目に通報を行ったユーザと、複数回の通報を行ったユーザとでは、異なる特典を生成するようにしてもよい。

例えば、ユーザは、同じイベントのチケットを複数枚取得したいという要望は有していないと想定される。すなわち、通報に係るイベントのチケットを既に有しているユーザは、さらに通報に係るイベントのチケットを多く取得したいとは考えず、代わりに、通報に係るイベントに関連するイベントのチケットを取得したいと考えると想定される。このため、頻繁に通報を行うユーザに対して、通報に係るイベントのチケットを取得する機会を何度も与えても、通報を行うことへの動機付けを向上させにくい。代わりに、頻繁に通報を行うユーザに対して、通報に係るイベントとは異なるイベントのチケットの購入機会等が与えられれば、新たな動機付けになりうると想定される。

このため、生成部１３５は、例えば１回目に通報を行ったユーザには、通報に係るイベントのチケットを購入する権利を特典として生成し、例えば複数回通報を行ったユーザには、通報に係るイベントとは異なるイベントであって、通報に係るイベントと関連性のあるイベントのチケットを購入する権利を特典として生成してもよい。

また、生成部１３５は、通報に係るイベント、又は、通報を行ったユーザに関する情報に基づいて、特典を生成してもよい。例えば、生成部１３５は、チケットテーブル１２３等を参照し、通報を行ったユーザが既に通報に係るイベントに参加するためのチケットを有していると判定した場合には、そのイベントに参加するためのチケットを購入する権利を特典として生成しなくてもよい。また、生成部１３５は、通報を行ったユーザの属性情報（性別、年齢等）に応じて、当該ユーザが好みにあうと想定されるイベントのチケットを購入する権利を特典として生成してもよい。

（送信部１３６について）
送信部１３６は、各種情報を送信する。例えば、送信部１３６は、生成部１３５によって生成された特典の内容をユーザに伝達する通知をユーザ端末１０に送信する。また、送信部１３６は、例えば、判定部１３３によって判定された結果をユーザ端末１０に送信してもよい。

また、送信部１３６は、ユーザが出品したチケットに対して通報が行われたことや、ユーザが出品したチケットが非正規であったと判定されたことや、当該チケットが無効になったこと等の通知をユーザ端末１０に送信してもよい。

また、送信部１３６は、商取引サイトを提供するウェブサーバ３０や、ウェブサーバ３０の管理者に対して、商取引に対して通報が行われたことや、商取引に係るチケットが非正規であったと判定されたことや、当該チケットが無効になったこと等の通知を送信してもよい。また、送信部１３６は、商取引において出品されているチケットと、商取引情報に記載されているイベントとの整合性がとれない場合、当該チケットは、偽造チケットであったり、誤った情報に基づく商取引であったりするものとして、警告や商取引の中止を伝達する旨の通知を送信してもよい。

〔４．ウェブサーバの構成〕
次に、図８を用いて、実施形態に係るウェブサーバ３０の構成について説明する。図８は、実施形態に係るウェブサーバ３０の構成例を示す図である。図８に示すように、ウェブサーバ３０は、通信部３１と、コンテンツ記憶部３２と、制御部３３とを有する。

通信部３１は、例えば、ＮＩＣ等によって実現される。そして、通信部３１は、ネットワークＮと有線または無線で接続され、ユーザ端末１０や更新装置１００との間で情報の送受信を行う。

コンテンツ記憶部３２は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。そして、コンテンツ記憶部３２は、コンテンツの一例であるウェブページ（例えば、商取引サイトに関するウェブページ）を記憶する。例えば、コンテンツ記憶部３２は、ウェブページを形成するＨＴＭＬファイルや、ウェブページに表示される静止画像や動画像を記憶する。なお、コンテンツ記憶部３２に記憶されるウェブページには、ウェブページ上に表示させる広告コンテンツを取得するための広告取得命令が含まれる場合がある。

制御部３３は、コントローラであり、例えば、ＣＰＵやＭＰＵ等によって、ウェブサーバ３０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部３３は、コントローラであり、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

図８に示すように、制御部３３は、受付部３４と、配信部３５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部３３の内部構成は、図８に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部３３が有する各処理部の接続関係は、図８に示した接続関係に限られず、他の接続関係であってもよい。

受付部３４は、ユーザ端末１０からウェブページの取得要求を受け付ける。例えば、受付部３４は、ウェブページの取得要求として、ＨＴＴＰリクエストを受け付ける。また、受付部３４は、チケットを出品しようとする出品者から、商取引に関する情報を受け付けてもよい。例えば、受付部３４は、チケットを出品するために商取引サイトにアップロードする情報（チケットに記載されたイベント名や開催日時、チケットに設定する価格等）を受け付ける。また、受付部３４は、出品者が撮像したチケットの画像を受け付ける。受付部３４は、受け付けた情報をコンテンツ記憶部３２に記憶する。

配信部３５は、受付部３４によってウェブページ（コンテンツ）の取得要求が受け付けられた場合に、ウェブページをユーザ端末１０に配信する。具体的には、配信部３５は、コンテンツ記憶部３２から取得要求対象のウェブページを取得し、取得したウェブページをユーザ端末１０に配信する。上記の通り、コンテンツ記憶部３２に記憶されているウェブページは、広告取得命令が含まれてもよい。この場合、ユーザ端末１０は、取得したウェブページを表示する際に、ウェブページに含まれる広告取得命令に従い、所定の広告サーバに対して広告コンテンツの配信要求を送信する。

〔５．処理手順〕
次に、図９を用いて、実施形態に係る更新装置１００による処理の手順について説明する。図９は、実施形態に係る処理手順を示すフローチャートである。

図９に示すように、更新装置１００は、商取引サイトを利用するユーザから、所定の商取引において、通報を受け付けたか否かを判定する（ステップＳ１０１）。通報を受け付けていない場合（ステップＳ１０１；Ｎｏ）、更新装置１００は、通報を受け付けるまで待機する。

一方、通報を受け付けた場合（ステップＳ１０１；Ｙｅｓ）、更新装置１００は、通報されたチケットを特定する（ステップＳ１０２）。そして、更新装置１００は、通報によって特定されたチケットと、当該チケットが掲載されていた商取引における商取引情報との整合性がとれたか否かを判定する（ステップＳ１０３）。

チケットと商取引情報との整合性がとれている場合（ステップＳ１０３；Ｙｅｓ）、更新装置１００は、さらに、当該チケットが非正規なものであるか否かを判定する（ステップＳ１０４）。判定の結果、チケットが正規なものであれば（ステップＳ１０４；Ｎｏ）、更新装置１００は、処理を終了する。

一方、チケットが非正規なものであれば（ステップＳ１０４；Ｙｅｓ）、更新装置１００は、当該チケットを無効化する（ステップＳ１０５）。そして、更新装置１００は、無効化したチケットに対応する分の枠数をイベントに追加するよう、余剰枠を更新する（ステップＳ１０６）。

そして、更新装置１００は、通報者への特典を生成する（ステップＳ１０７）。続けて、更新装置１００は、生成した特典の内容を伝達するための通知を通報者に送信する（ステップＳ１０８）。

なお、更新装置１００は、ステップＳ１０３において、チケットと商取引情報との整合性がとれていない場合（ステップＳ１０３；Ｎｏ）、当該チケットが偽造チケットであるか否かを判定する（ステップＳ１０９）。

チケットが偽造チケットであると判定した場合（ステップＳ１０９；Ｙｅｓ）、更新装置１００は、偽造チケットに関する商取引が非正規なものであり、不正なものと判定し、商取引サイトに対して警告したり、商取引停止を通知する旨を送信したりする（ステップＳ１１０）。

一方、チケットが偽造チケットでないと判定した場合（ステップＳ１０９；Ｎｏ）、更新装置１００は、処理を終了する。なお、チケットと商取引との整合性がとれない場合とは、出品されたチケットが誤っている等の事態が推測されるため、更新装置１００は、出品されたチケットが誤っている等の旨を示す通知を商取引サイト（もしくは出品者）に送信してもよい。

〔６．変形例〕
上述した更新装置１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、更新装置１００の他の実施形態について説明する。

〔６−１．通報回数に応じた特典〕
上記実施形態では、更新装置１００は、イベントごと、また、ユーザごとの通報回数に応じた特典を生成することを説明した。ここで、更新装置１００は、ユーザごとに、更に異なる情報と対応付けて通報の履歴を記憶し、累積された通報回数に応じた特典を生成するようにしてもよい。

例えば、更新装置１００は、出演者と対応付けて通報の履歴を記憶するようにしてもよい。例えば、商取引サイト等を利用するユーザは、自身が好きなアーティストが出演するイベントに関してチケットの商取引情報を頻繁に閲覧することが想定される。このため、このようなユーザは、非正規な商取引を発見する可能性も高いと想定されるので、このようなユーザが積極的に通報を行うことが望ましい。

そこで、更新装置１００は、通報したユーザと、通報に係るイベントに出演するアーティストとを対応付けた通報履歴を記憶し、その通報回数に応じた特典を生成してもよい。例えば、更新装置１００は、所定回数を超える通報を行ったユーザに対して、特典として、当該アーティストが出演するイベントのチケットを優先的に購入する権利を生成する。これにより、更新装置１００は、通報を行う動機付けをより強くユーザに与えられるので、積極的に通報を行わせることができる。

この場合、更新装置１００は、例えば、好きなアーティスト等の登録をユーザから事前に受け付けるようにしてもよい。また、更新装置１００は、例えば、ユーザの通報履歴に基づいてユーザが好むアーティストを推定し、ユーザとアーティストとを対応付けるようにしてもよい。

なお、更新装置１００は、通報を受けても余剰枠が追加できない場合もありうる。例えば、偽造チケットが通報された場合には、偽造チケットにはもともと枠が割り当てられていないため、その分の余剰枠は追加されない場合がある。このため、更新装置１００は、余剰枠に応じた特典を生成するようにしてもよい。すなわち、更新装置１００は、通報を受け付けたものの、当該ユーザに提供できる余剰枠がない場合には、通報に係るイベントに関連するイベントであって、余剰枠のあるイベントに対する購入権を特典として生成してもよい。あるいは、更新装置１００は、特典として、余剰枠の購入権ではなく、例えば、所定の商品等をユーザが受け取ることのできる権利等を生成してもよい。

〔６−２．イベントの種類〕
上記実施形態では、所定のサービスとして、出演者等が存在するイベント（コンサート等）を一例として挙げた。しかし、実施形態に係る更新処理において、所定のサービスとは、当該所定のサービスに参加する権利が商取引として扱われるものであり、また、参加する権利の枠数の上限が定められているものであれば、コンサート等に限られない。例えば、所定のサービスは、スポーツの試合でもよいし、展覧会や博覧会等であってもよい。

〔６−３．ユーザインターフェース〕
上記実施形態では、ユーザは、図１に示したボタンＱ０１のようなユーザインターフェースを利用して通報を行う例を示した。しかし、ユーザは、ボタンＱ０１に限らず、種々の手段によって通報を行ってもよい。例えば、ユーザは、メールソフトやチャットソフト等を利用して通報を行ってもよい。

また、更新装置１００は、ユーザから通報を受けた場合、通報された商取引であることがわかるような表示を商取引サイトに表示させてもよい。例えば、更新装置１００は、「このチケットはユーザから通報されました」といった表示を商取引サイトに表示させてもよい。これにより、他のユーザは、当該商取引が通報されたものであることを知得できるので、警戒して商取引に臨むことができる。

また、更新装置１００は、チケットを無効にした場合、通報された商取引に係るチケットが無効にされたことがわかるような表示を商取引サイトに表示させてもよい。例えば、更新装置１００は、「このチケットは不正なチケットと判定されたため無効となりました」といった表示を商取引サイトに表示させてもよい。これにより、更新装置１００は、商取引サイトを利用するユーザに対して、個人間での商取引ではチケットの効力が取り消される可能性があることを認識させることができる。このため、更新装置１００は、チケットの売買を健全なものにすることができる。

〔６−４．転売者や偽造者の特定〕
更新装置１００は、チケットを無効化した場合、無効化されたチケットを出品したユーザや、無効化されたチケット（例えば転売されたチケット）を購入したユーザ等を特定してもよい。そして、更新装置１００は、そのようなユーザが、今後正規なルートでチケットを購入しようとしても、チケットを販売しないようにしてもよい。これにより、更新装置１００は、転売等の規約に反した行動をとるユーザをチケット売買から排除できるので、チケットの売買を健全なものにすることができる。

〔６−５．判定処理〕
上記実施形態では、更新装置１００は、チケットの画像データ等から識別子を特定し、当該チケットが不正なものであるか否かを判定する例を示した。ここで、チケットの判定においては、学習データが蓄積されるまでは、人手によって行われてもよい。例えば、更新装置１００は、人手によって判定された情報であって、商取引に係るチケットが不正であるか否かを判定した結果情報と、結果を導出するのに寄与した情報とを対応付けた情報を取得する。そして、更新装置１００は、取得した情報を学習データとして、所定の学習処理を行う。例えば、更新装置１００は、商取引情報にいずれの情報が含まれていた場合に、当該商取引が非正規なものであると判定されるか、といった情報を学習する。かかる学習が進むにつれ、更新装置１００は、通報によって特定された商取引情報と、データベースに記憶されたチケットの情報とに基づいて、商取引に係るチケットが非正規であるか否かを判定することができるようになる。

また、更新装置１００は、高額転売や偽造といった理由以外であっても、チケットや商取引を非正規と判定してもよい。例えば、更新装置１００は、商取引に係るチケットが窃盗によるものであったり（すなわち、購入者以外の者から出品されていたり）、例えば株主など特定の者のみが使用可能なチケットが販売されていたりする場合には、当該チケットが非正規なものであると判定してもよい。

〔７．ハードウェア構成〕
上述してきた実施形態に係る更新装置１００やユーザ端末１０やウェブサーバ３０は、例えば図１０に示すような構成のコンピュータ１０００によって実現される。以下、更新装置１００を例に挙げて説明する。図１０は、更新装置１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に記憶されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を記憶する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（図２に示したネットワークＮに対応）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを、通信網５００を介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に記憶されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態に係る更新装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内のデータが記憶される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から通信網５００を介してこれらのプログラムを取得してもよい。

〔８．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図３に示した受付部１３１と、取得部１３２とは統合されてもよい。また、例えば、記憶部１２０に記憶される情報は、ネットワークＮを介して、外部に備えられた所定の記憶装置に記憶されてもよい。

また、上記実施形態では、更新装置１００が、例えば、通報を受け付ける受付処理と、通報に係るチケットが非正規であるか否かを判定する判定処理と、イベントの余剰枠を更新する更新処理とを行う例を示した。しかし、上述した更新装置１００は、受付処理を行う受付装置と、判定処理を行う判定装置と、更新処理を行う更新装置とに分離されてもよい。この場合、受付装置は、少なくとも受付部１３１を有する。判定装置は、少なくとも判定部１３３を有する。更新装置は、少なくとも更新部１３４を有する。そして、上記の更新装置１００による処理は、受付装置と、判定装置と、更新装置との各装置を有する更新処理システム１によって実現される。

また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔９．効果〕
上述してきたように、実施形態に係る更新装置１００は、受付部１３１と、判定部１３３と、更新部１３４とを有する。受付部１３１は、所定のサービスを受ける権利の販売に関する通報をユーザから受け付ける。判定部１３３は、受付部１３１によって受け付けられた通報によって特定される権利が、非正規であるか否かを判定する。更新部１３４は、判定部１３３によって判定された結果に基づいて、所定のサービスを受ける権利の枠数を更新する。

このように、実施形態に係る更新装置１００は、ユーザが不正な取引であると判断した権利の販売（チケット販売等）に対する通報を受け付け、かかるチケットに対する判定を行い、例えば非正規であった場合には、当該チケット分の余剰枠をイベントに追加する。すなわち、更新装置１００は、イベントに参加することを希望しつつも正規のルートではチケットを購入できなかったユーザ等からの通報に基づいて、非正規なチケットを判定することができる。これにより、更新装置１００は、高い精度で非正規なチケットを抽出することができる。また、更新装置１００は、非正規と判定した分の余剰枠を更新することで、より多くのユーザがイベントに参加できるように枠数を追加で設けることができるため、通報を行ったユーザにとってメリットのある処理を行うことができる。結果として、更新装置１００は、ユーザからの通報を促進することができるので、不正な取引の発生を抑制することができる。

また、実施形態に係る更新装置１００は、通報によって特定される権利が非正規であると判定された場合に、通報を行ったユーザに対して付与される特典であって、所定のサービスに関する特典を生成する。

このように、実施形態に係る更新装置１００は、通報を行ったユーザに対する褒賞となるような特典を生成することで、通報に対する動機付けを与える。これにより、更新装置１００は、通報の数や率を高めることができるため、不正な取引の発生を抑制することができる。

また、生成部１３５は、特典として、所定のサービスを受ける権利をユーザが新たに購入する権利を生成する。

このように、実施形態に係る更新装置１００は、通報を行ったユーザに対して、通報した分のチケットの購入権を特典として生成してもよい。これにより、更新装置１００は、例えばチケットを正規なルートで取得できなかったユーザに対してもイベントに参加する機会を与えることができるため、通報に対する動機付けをより強くユーザに与えることができる。

また、生成部１３５は、特典として、所定のサービスに関連するサービスを受ける権利をユーザが優先的に購入する権利を生成する。

このように、実施形態に係る更新装置１００は、通報に係るイベントのみならず、関連するイベントについての特典を生成してもよい。これにより、更新装置１００は、既に当該イベントのチケットを有しているユーザ等に対しても、通報に対する褒賞として満足度の高い特典を生成することができる。

また、生成部１３５は、通報によって特定される権利が非正規であると判定された数に応じて、通報を行ったユーザに対して、所定のサービスに関する特典を生成する。

このように、実施形態に係る更新装置１００は、通報回数に応じた特典を生成してもよい。これにより、更新装置１００は、より多く通報を行う動機付けをユーザに与えることができるので、結果として、不正な取引の発生を抑制することができる。

また、判定部１３３は、通報によって特定される権利が、予め権利に設定されていた価格よりも、権利に対応する商取引において高い価格が設定されていた場合に、権利を非正規と判定する。

このように、実施形態に係る更新装置１００は、高額転売されたチケットを非正規なものと判定する。これにより、更新装置１００は、不当に高額な値段が付けられたチケットが流通するのを防止できるので、健全なチケットの取引に貢献することができる。

また、判定部１３３は、通報によって特定される権利が、所定のサービスを提供する提供側から正規に発行された権利でない場合に、権利を非正規と判定する。

このように、実施形態に係る更新装置１００は、例えば偽造チケット等の正規に発行されたものではないチケットを非正規なものと判定する。これにより、更新装置１００は、実際には効力を有しない不正チケット等に関する商取引をサイトから排除することができるので、健全なチケットの取引に貢献することができる。

また、判定部１３３は、通報によって特定される権利に対応付けられた画像に基づいて、通報によって特定される権利を識別する。

このように、実施形態に係る更新装置１００は、商取引情報のうち、画像に基づいてチケットを識別することで、チケットの判定処理を行ってもよい。例えば、更新装置１００は、識別したチケットにおいて、データベースで予め対応付けられた情報と、商取引において宣伝されている情報（イベント名や開催日時等）に齟齬があることや、データベースにおいて設定されていた価格と、商取引において設定された価格との間に齟齬があること等を高い精度で判定できる。

また、判定部１３３は、画像に含まれる権利を識別するための識別子に基づいて、通報によって特定される権利を識別する。

このように、実施形態に係る更新装置１００は、例えば画像解析等によって判明する識別子（バーコード等）に基づいてチケットを識別してもよい。これにより、更新装置１００は、高い精度でチケットを識別できるので、結果として、判定処理の精度を向上させることができる。

また、判定部１３３は、通報によって特定される権利に対応付けられたテキスト情報に基づいて、通報によって特定される権利を識別する。

このように、実施形態に係る更新装置１００は、権利に対応付けられたテキスト情報（例えば、商取引における説明文や、チケットの説明に用いられるテキストデータ）に基づいてチケットを識別してもよい。これにより、更新装置１００は、画像のみによらず、多様な観点から、通報されたチケットを識別することができる。

また、判定部１３３は、テキスト情報に含まれる情報であって、権利を識別するための識別子、権利に対応する所定のサービスの開催地、開催日時、及び、所定のサービスにおける権利に対応する座席情報の少なくとも一つの情報に基づいて、通報によって特定される権利を識別する。

このように、実施形態に係る更新装置１００は、通報されたチケットにおいて、商取引に関する種々の情報に基づいてチケットを識別するようにしてもよい。そして、更新装置１００は、識別されたチケットに関する情報と、データベースに保持された情報とを照合することにより、当該チケットが非正規なものであるか否かを高い精度で判定することができる。

以上、本願の実施形態を図面に基づいて詳細に説明したが、これは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１ 更新処理システム
１０ ユーザ端末
３０ ウェブサーバ
１００ 更新装置
１１０ 通信部
１２０ 記憶部
１２１ イベント情報記憶部
１２２ イベントテーブル
１２３ チケットテーブル
１２５ 商取引情報記憶部
１２６ 特典情報記憶部
１３０ 制御部
１３１ 受付部
１３２ 取得部
１３３ 判定部
１３４ 更新部
１３５ 生成部
１３６ 送信部

Claims (11)

1. 所定のサービスを受ける権利の販売に関する通報をユーザから受け付ける受付部と、
   前記受付部によって受け付けられた通報によって特定される権利が、非正規であるか否かを判定する判定部と、
   前記判定部によって判定された結果に基づいて、前記所定のサービスを受ける権利の枠数を、非正規であると判定された数だけ追加するよう更新する更新部と、
   前記通報によって特定される権利が非正規であると判定された場合に、当該通報を行ったユーザに対して付与される特典として、前記所定のサービスに関連するサービスであって予め当該ユーザに対応付けて登録された所定の情報に基づいて選択されたサービスを受ける権利を、当該ユーザが優先的に購入する権利を生成する生成部と、
   を備えることを特徴とする更新装置。
2. 前記生成部は、
   前記特典として、前記所定のサービスを受ける権利を前記ユーザが新たに購入する権利をさらに生成する、
   ことを特徴とする請求項１に記載の更新装置。
3. 前記生成部は、
   前記通報によって特定される権利が非正規であると判定された数に応じて、当該通報を行ったユーザに対して、前記特典を生成する、
   ことを特徴とする請求項１又は２に記載の更新装置。
4. 前記判定部は、
   前記通報によって特定される権利が、予め当該権利に設定されていた価格よりも、当該権利に対応する商取引において高い価格が設定されていた場合に、当該権利を非正規と判定する、
   ことを特徴とする請求項１〜３のいずれか一つに記載の更新装置。
5. 前記判定部は、
   前記通報によって特定される権利が、前記所定のサービスを提供する提供側から正規に発行された権利でない場合に、当該権利を非正規と判定する、
   ことを特徴とする請求項１〜４のいずれか一つに記載の更新装置。
6. 前記判定部は、
   前記通報によって特定される権利に対応付けられた画像に基づいて、当該通報によって特定される権利を識別する、
   ことを特徴とする請求項１〜５のいずれか一つに記載の更新装置。
7. 前記判定部は、
   前記画像に含まれる前記権利を識別するための識別子に基づいて、前記通報によって特定される権利を識別する、
   ことを特徴とする請求項６に記載の更新装置。
8. 前記判定部は、
   前記通報によって特定される権利に対応付けられたテキスト情報に基づいて、当該通報によって特定される権利を識別する、
   ことを特徴とする請求項１〜７のいずれか一つに記載の更新装置。
9. 前記判定部は、
   前記テキスト情報に含まれる情報であって、前記権利を識別するための識別子、当該権利に対応する所定のサービスの開催地、開催日時、及び、当該所定のサービスにおける当該権利に対応する座席情報の少なくとも一つの情報に基づいて、当該通報によって特定される権利を識別する、
   ことを特徴とする請求項８に記載の更新装置。
10. コンピュータが実行する更新方法であって、
    所定のサービスを受ける権利の販売に関する通報をユーザから受け付ける受付工程と、
    前記受付工程によって受け付けられた通報によって特定される権利が、非正規であるか否かを判定する判定工程と、
    前記判定工程によって判定された結果に基づいて、前記所定のサービスを受ける権利の枠数を、非正規であると判定された数だけ追加するよう更新する更新工程と、
    前記通報によって特定される権利が非正規であると判定された場合に、当該通報を行ったユーザに対して付与される特典として、前記所定のサービスに関連するサービスであって、予め当該ユーザに対応付けて登録された所定の情報に基づいて選択されたサービスを受ける権利を、当該ユーザが優先的に購入する権利を生成する生成工程と、
    を含んだことを特徴とする更新方法。
11. 所定のサービスを受ける権利の販売に関する通報をユーザから受け付ける受付手順と、
    前記受付手順によって受け付けられた通報によって特定される権利が、非正規であるか否かを判定する判定手順と、
    前記判定手順によって判定された結果に基づいて、前記所定のサービスを受ける権利の枠数を、非正規であると判定された数だけ追加するよう更新する更新手順と、
    前記通報によって特定される権利が非正規であると判定された場合に、当該通報を行ったユーザに対して付与される特典として、前記所定のサービスに関連するサービスであって、予め当該ユーザに対応付けて登録された所定の情報に基づいて選択されたサービスを受ける権利を、当該ユーザが優先的に購入する権利を生成する生成手順と、
    をコンピュータに実行させることを特徴とする更新プログラム。

Images