2022-700393

特許第６９６２５９４号発明「プログラム」の特許異議申立事件について、次のとおり決定する。

結 論 特許第６９６２５９４号の特許請求の範囲を訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項〔１、２〕、〔４、５〕について訂正することを認める。 特許第６９６２５９４号の請求項３、５、６、７に係る特許を維持する。 同請求項１、２、４に係る特許について特許異議の申立てを却下する。

理 由 第１ 手続の経緯 特許第６９６２５９４号の請求項１～７に係る特許についての出願は、令和元年１１月２９日（優先権主張 令和元年７月４日）の出願であって、令和３年１０月１８日にその特許権の設定登録がされ、同年１１月５に特許掲載公報が発行された。その後、その特許に対して、令和４年５月２日に特許異議申立人遠藤眞理子（以下、「特許異議申立人」という。）により、特許異議の申立てがされ（以下、この特許異議の申立てが記載された特許異議申立書を、「特許異議申立書」という。）、当審は、令和４年８月２５日付けで取消理由（以下、「取消理由」という。）を通知した。特許権者は、その指定期間内である令和４年１０月４日に意見書（以下、「意見書」という。）の提出及び訂正の請求（以下、「本件訂正請求」という。）を行った。 第２ 訂正の適否についての判断 １ 訂正の内容 本件訂正請求による訂正の内容は、以下のとおりである。 （１）一群の請求項１、２に係る訂正 ア 訂正事項１ 特許請求の範囲の請求項１を削除する。 イ 訂正事項２ 特許請求の範囲の請求項２を削除する。 ウ 訂正事項１、２は、一群の請求項〔１、２〕に対してされたものである。 （２）一群の請求項４、５に係る訂正 ア 訂正事項３ 特許請求の範囲の請求項４を削除する。 イ 訂正事項４ 特許請求の範囲の請求項５に「請求項４記載のプログラム」と記載されているのを、独立形式に改める。 ウ 訂正事項３、４は、一群の請求項〔４、５〕に対してされたものである。 ２ 訂正の目的の適否、新規事項の有無、特許請求の範囲の拡張・変更の存否、及び特許出願の際に独立して特許を受けることができることについて （１）一群の請求項１、２に係る訂正 ア 訂正事項１について （ア）訂正の目的について 訂正事項１は、請求項１を削除するものであるから、特許法第１２０条の５第２項ただし書第１号に掲げる「特許請求の範囲の減縮」を目的とするものである。 （イ）願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であることについて 訂正事項１は、請求項１を削除するものであるから、願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であり、特許法第１２０条の５第９項で準用する同法第１２６条第５項に適合するものである。 （ウ）実質上特許請求の範囲を拡張し、又は変更する訂正ではないことについて 訂正事項１は、請求項１を削除するものであるから、カテゴリーや対象、目的を変更するものではない。 したがって、訂正事項１は、実質上特許請求の範囲を拡張し、又は変更するものではないため、特許法第１２０条の５第９項で準用する同法第１２６条第６項に適合するものである。 （エ）特許出願の際に独立して特許を受けることができることについて 本特許異議申立事件において、全ての請求項について特許異議申立ての対象とされているため、訂正事項１に関して、特許法第１２０条の５第９項で準用する同法第１２６条第７項の独立特許要件は課されない。 イ 訂正事項２について （ア）訂正の目的について 訂正事項２は、請求項２を削除するものであるから、特許法第１２０条の５第２項ただし書第１号に掲げる「特許請求の範囲の減縮」を目的とするものである。 （イ）願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であることについて 訂正事項２は、請求項２を削除するものであるから、願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であり、特許法第１２０条の５第９項で準用する同法第１２６条第５項に適合するものである。 （ウ）実質上特許請求の範囲を拡張し、又は変更する訂正ではないことについて 訂正事項２は、請求項２を削除するものであるから、カテゴリーや対象、目的を変更するものではない。 したがって、訂正事項２は、実質上特許請求の範囲を拡張し、又は変更するものではないため、特許法第１２０条の５第９項で準用する同法第１２６条第６項に適合するものである。 （エ）特許出願の際に独立して特許を受けることができることについて 本特許異議申立事件において、全ての請求項について特許異議申立ての対象とされているため、訂正事項２に関して、特許法第１２０条の５第９項で準用する同法第１２６条第７項の独立特許要件は課されない。 ウ 一群の請求項について 訂正前の請求項１、２について、請求項２は、請求項１を直接的に引用しているものであって、訂正事項１によって記載が訂正される請求項１に連動して訂正されるものである。 したがって、訂正前の請求項１、２に対応する訂正後の請求項１、２は、特許法第１２０条の５第４項に規定する一群の請求項である。 （２）一群の請求項４、５に係る訂正 ア 訂正事項３について （ア）訂正の目的について 訂正事項３は、請求項４を削除するものであるから、特許法第１２０条の５第２項ただし書第１号に掲げる「特許請求の範囲の減縮」を目的とするものである。 （イ）願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であることについて 訂正事項３は、請求項４を削除するものであるから、願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であり、特許法第１２０条の５第９項で準用する同法第１２６条第５項に適合するものである。 （ウ）実質上特許請求の範囲を拡張し、又は変更する訂正ではないことについて 訂正事項３は、請求項４を削除するものであるから、カテゴリーや対象、目的を変更するものではない。 したがって、訂正事項３は、実質上特許請求の範囲を拡張し、又は変更するものではないため、特許法第１２０条の５第９項で準用する同法第１２６条第６項に適合するものである。 （エ）特許出願の際に独立して特許を受けることができることについて 本特許異議申立事件において、全ての請求項について特許異議申立ての対象とされているため、訂正事項３に関して、特許法第１２０条の５第９項で準用する同法第１２６条第７項の独立特許要件は課されない。 イ 訂正事項４について （ア）訂正の目的について 訂正事項４は、訂正前の請求項５が「請求項４に記載のプログラム」であるところ、請求項間の引用関係を解消し、請求項４の記載を引用しないものとし、独立形式へ改めるための訂正であって、特許法第１２０条の５第２項ただし書第４号に掲げる「他の請求項の記載を引用する請求項の記載を当該他の請求項の記載を引用しないものとすること」を目的とする訂正である。 （イ）願書に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内の訂正であることについて 訂正事項４は、何ら実質的な内容の変更を伴うものではないから、特許法第１２０条の５第９項で準用する同法第１２６条第５項に適合するものである。 （ウ）実質上特許請求の範囲を拡張し、又は変更する訂正ではないことについて 訂正事項４は、何ら実質的な内容の変更を伴うものではないから、特許法第１２０条の５第９項で準用する同法第１２６条第６項に適合するものである。 （エ）特許出願の際に独立して特許を受けることができることについて 訂正事項４は、第１２０条の５第２項ただし書第４号に掲げる「他の請求項の記載を引用する請求項の記載を当該他の請求項の記載を引用しないものとすること」を目的とする訂正であって、同第１号又は第２号に掲げる事項を目的とする訂正ではないから、請求項５に係る訂正事項４に関して、特許法第１２０条の５第９項で読み替えて準用する特許法第１２６条第７項の独立特許要件は課されない。 ウ 一群の請求項について 訂正前の請求項４、５について、請求項５は、請求項４を直接的に引用しているものであって、訂正事項３によって記載が訂正される請求項４に連動して訂正されるものである。 したがって、訂正前の請求項４、５に対応する訂正後の請求項４、５は、特許法第１２０条の５第４項に規定する一群の請求項である。 （３）小括 以上のとおり、本件訂正請求による訂正は、特許法第１２０条の５第２項ただし書第１号又は第４号に掲げる事項を目的とするものであり、かつ、同条第１２６条第５項及び第６項の規定に適合するので、本件特許の特許請求の範囲を、訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項〔１、２〕、〔４、５〕について訂正することを認める。 第３ 訂正後の本件訂正発明 本件訂正により訂正された請求項１、２、４、５に係る発明（以下、「本件訂正発明１」等という。）及び、請求項３、６、７に係る発明（以下、「本件発明３」等という。）は、訂正特許請求の範囲の請求項１～７に記載された次の事項により特定されるとおりのものである。 なお、請求項３、６、７については訂正の請求がされていない。 本件訂正発明１ （削除） 本件訂正発明２ （削除） 本件発明３ 「各ユーザの端末装置と通信可能なコンピュータを、 或る移動経路の現在又は将来の混雑状況値を取得する取得手段、 前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信し、且つ、前記要請を承諾したユーザに対して、報酬を付与する要請手段、 予め定められた情報に基づき、前記報酬を変更する変更手段、 として機能させ、 前記予め定められた情報は、前記要請を送信してから承諾するまでの経過時間を含む、 プログラム。」 本件訂正発明４ （削除） 本件訂正発明５ 「各ユーザの端末装置と通信可能なコンピュータを、 或る移動経路の現在又は将来の混雑状況値を取得する取得手段、 前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信し、且つ、前記要請を承諾したユーザに対して、報酬を付与する要請手段、 予め定められた情報に基づき、前記報酬を変更する変更手段、 として機能させ、 前記予め定められた情報は、現在の天候情報を含み、 前記変更手段は、前記天候情報が雨を示す場合、屋内施設で利用可能な報酬に変更し、前記天候情報が晴れを示す場合、野外施設で利用可能な報酬に変更する、 プログラム。」 本件発明６ 「各ユーザの端末装置と通信可能なコンピュータを、 各ユーザのスケジュールを記憶する記憶手段、 或る移動経路の現在又は将来の混雑状況値を取得する取得手段、 前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信し、且つ、前記要請を承諾したユーザに対して、報酬を付与する要請手段、 予め定められた情報に基づき、前記報酬を変更する変更手段、 として機能させ、 前記予め定められた情報は、前記要請を承諾したユーザのスケジュールを含む、 プログラム。」 本件発明７ 「前記変更手段は、前記要請を承諾したユーザのスケジュールを変更する、 請求項６に記載のプログラム。」 第４ 取消理由通知に記載した取消理由の概要 訂正前の請求項１～７に係る特許に対して、当審が令和４年８月２５日付けで特許権者に通知した取消理由の要旨は、次のとおりである。 理由１ （進歩性）請求項１、２、４に係る発明は、本件特許出願前に日本国内又は外国において、頒布された特開２０１７－５９０９９号公報（以下、「引用文献１」という。特許異議申立書に記載の甲第２号証。）に記載された発明に基いて、本件特許出願前にその発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、請求項１、２、４に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 理由２ （実施可能要件）本件特許は、発明の詳細な説明の記載が不備のため、特許法第３６条第４項第１号に規定する要件を満たしていない特許出願に対してされたものである。 第５ 取消理由についての当審の判断 １ 理由１（特許法第２９条第２項）について （１）請求項１、２、４について 上記第２で示したように、本件訂正請求による訂正は認められ、本件特許の請求項１、２、４は削除されたため、訂正前の請求項１、２、４に係る発明についての、進歩性要件違反の取消理由は、その対象が存在しないものとなった。 ２ 理由２（特許法第３６条第４項第１号）について（下線は、当審で付した。以下、同じ。） （１）訂正前の請求項１～７に係る発明の「或る移動経路」について、本件特許明細書の発明の詳細な説明には、「各ユーザの識別情報（ユーザＩＤ）に対応付け」られる「ユーザ情報５０Ａ」に含まれる「スケジュール」に、「ユーザが利用予定である移動経路」として、当該「或る移動経路」が含まれていないユーザが、当該「或る移動経路」を特定することができることは、明確かつ十分に記載されておらず、「或る移動経路」の定義がないため、取り得る範囲が不明であり、また、これらの特定が技術常識であるとはいえないから、訂正前の請求項１～７に係る発明は、「或る移動経路」を特定できない場合を含むものであり、本件特許明細書の発明の詳細な説明は、訂正前の請求項１～７に係る発明を、その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載したものであるとはいえないとの取消理由について、本件特許明細書の発明の詳細な説明に、「第一実施形態では、取得手段５２は、或る移動経路の現在および／又は将来の混雑状況値を、随時又は定期的（例えば１時間毎）に所定の機関から取得する。」（【００３８】）と記載されているように、本件特許明細書の発明の詳細な説明に、「或る移動経路」は、所定の機関から取得されるものとして定義されており、現在および／又は将来の混雑状況値に係るものであることが具体的に説明されている。 そうすると、本件発明３、本件訂正発明５、本件発明６、７の「或る移動経路」は、所定の機関から取得される混雑値に係るものであり、ユーザ情報に含まれるユーザが利用予定である移動経路により特定されるものでないから、本件特許明細書の発明の詳細な説明は、本件発明３、本件訂正発明５、本件発明６、７について、その実施をすることができる程度に明確かつ十分に記載したものであるというべきである。 （２）訂正前の請求項１～７に係る発明の「或る移動経路の利用を控える要請」について上記（１）に示したように「或る移動経路」について、本件特許明細書の発明の詳細な説明に明確かつ十分に記載されていないため、訂正前の請求項１～７に係る発明の「前記或る移動経路の利用を控える要請」の「要請」が、どのようなものであるのか、本件特許明細書の発明の詳細な説明からは特定できない。そのため、本件特許明細書の発明の詳細な説明は、訂正前の請求項１～７に係る発明を、その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載したものであるとはいえないとの取消理由について、本件特許明細書の発明の詳細な説明には、上記（１）で示した記載に加え、「また、取得手段５２は、各ユーザの端末装置（第二端末装置１２Ｂ）の現在位置情報（例えば、緯度経度や住所）を取得する。」（【００３８】）、「選択手段５４は、ユーザおよび機関を選択する機能手段である。第一実施形態では、選択手段５４は、或る移動経路の混雑状況値が目標値を超えている場合、すなわち要請ユーザ数が１以上である場合、当該或る移動経路に関連するユーザを選択する。この関連するユーザとしては、・・・当該或る移動経路から第一の所定範囲内（例えば半径５００ｍ以内）に位置するユーザが挙げられ、これらの両方に当てはまるユーザであってもよい。」（【００３９】）、「要請手段５６は、各ユーザの端末装置（第二端末装置１２Ｂ）に対して要請を行う機能手段である。第一実施形態では、要請手段５６は、選択手段５４により選択されたユーザの端末装置に、或る移動経路の利用を控える要請を送信する。」（【００４１】）と記載されているように、「或る移動経路の利用を控える要請」は、所定の機関から取得される混雑状況値が目標値を超えている「或る移動経路」から、第一の所定範囲内に位置するユーザの端末装置対して、当該「或る移動経路」の利用を控える要請であるということが具体的に記載されている。 そうすると、本件特許明細書の発明の詳細な説明は、本件発明３、本件訂正発明５、本件発明６、７について、その実施をすることができる程度に明確かつ十分に記載したものであるというべきである。 第６ 特許異議申立理由について １ 特許法第２９条第２項について （１）証拠方法 甲第１号証：特開２０１１－８５９８０号公報 甲第２号証：特開２０１７－５９０９９号公報（取消理由通知における引用文献１。） 甲第３号証：特開２０１８－１０９８４０号公報 甲第４号証：特開２０１８－１３２８２５号公報 甲第５号証：国際公開２０１７／０８６０６１号 甲第６号証：特開２００９－１６３６４９号公報 甲第７号証：特開２０１５－８４２２０号公報 以下、「甲第１号証」～「甲第７号証」を、それぞれ、「甲１」～「甲７」という。 （２）特許異議申立書における特許異議申立人の主張の概要 訂正前の請求項１～７係る特許に対する、特許異議申立人の主張は以下のとおりである。なお、この項においては、訂正前の請求項１～７を、「請求項１」～「請求項７」と表記する。 ア 請求項１に係る発明は、甲２に記載された発明及び甲１、３、４に記載された事項に基づいて、当業者が容易に発明をすることができたものであるから、請求項１に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 イ 請求項２に係る発明は、甲２に記載された発明及び甲１、３、４に記載された事項に基づいて、当業者が容易に発明をすることができたものであるから、請求項２に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 ウ 請求項３に係る発明は、甲５若しくは甲２に記載された発明並びに甲１に記載された事項に基づいて、当業者が容易に発明をすることができたものであるから、請求項３に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 エ 請求項４に係る発明は、甲６若しくは甲２に記載された発明並びに甲１に記載された事項に基づいて、当業者が容易に発明をすることができたものであるから、請求項４に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 オ 請求項５に係る発明は、甲６若しくは甲２に記載された発明並びに甲１に記載された事項に基づいて、当業者が容易に発明をすることができたものであるから、請求項５に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 なお、当審において、異議申立書３７頁の「甲第５号証」は、「甲第６号証」の誤記であると解釈をした。 カ 請求項６に係る発明は、甲７若しくは甲２に記載された発明並びに甲１に記載された事項に基づいて、当業者が容易に発明をすることができたものであるから、請求項６に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 キ 請求項７に係る発明は、甲７若しくは甲２に記載された発明並びに甲１に記載された事項に基づいて、当業者が容易に発明をすることができたものであるから、請求項７に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 （３）甲号証の記載事項について ア 甲１（特開２０１１－８５９８０号公報）に記載された事項 甲１には、以下の記載がある。 「【技術分野】 【０００１】 本発明は、交通流分散装置に関する。」 「【００１９】 本実施の形態では、本発明を、車両間でのインセンティブ（ポイント）の授受や迂回車の募集などをセンタを介して行う交通流分散システムに適用する。本実施の形態に係る交通流分散システムは、ポイントの管理などを行うセンタのサーバと各車両に搭載される車載機からなり、サーバと各車載機とは無線通信可能である。また、本実施の形態に係る交通流分散システムでは、目的地までのルート探索で演算された最短ルートを走行することを希望する車両（希望車）とその最短ルート上における渋滞区間周辺を走行している迂回候補車との間でセンタを介して情報を遣り取りする。」 「【００２７】 周辺迂回候補車把握部２０ｃでは、最短ルート希望車３Ａから迂回車募集要請を受信した場合、車載機３０を搭載した車両の中から、各車両の位置情報に基づいて、最短ルート希望車３Ａの最短ルート上に存在しかつ渋滞区間周辺（特に、最短ルート希望車３Ａ側）に存在する車両（迂回候補車３Ｂ，・・・）を選択する。図２の例の場合、前方が渋滞している高速道路上を走行中の最短ルート希望車３Ａは最短ルート（高速道路上）に従って走行することを希望しており、その最短ルート希望車３Ａの現在位置から数ｋｍ先にある次の高速出口までに存在する車両群３Ｇが迂回候補車３Ｂ，・・・として選択される。 【００２８】 空間分散／時間分散演算部２０ｄでは、迂回候補車３Ｂ，・・・からの迂回希望通知に対する回答として迂回ＯＫの車両が存在する場合、リアルタイムプローブ交通情報データベース２０ｊに格納されている渋滞情報やＶＩＣＳ交通情報データベース２０ｋに格納されている渋滞情報に基づいて、最短ルート希望車３Ａの最短ルートにおける渋滞区間を迂回するための迂回ルートを演算する。ここでは、地図データベース２０ｉに格納されている最短ルート希望車３Ａの最短ルートにおける渋滞区間周辺の地図情報に基づいて、空間分散による迂回ルートを演算したり、時間分散による迂回ルートを演算する。時間分散では、休憩を推奨するなどして、車両を時間的に分散する。演算する迂回ルートは、１つだけでもよいし、あるいは、複数でもよい。 【００２９】 渋滞縮小演算部２０ｅでは、周辺迂回候補車把握部２０ｃで迂回候補車３Ｂ，・・・を把握すると、迂回車の数に応じて最短ルート希望車３Ａの最短ルートにおける渋滞区間の縮小度合いを演算する。この迂回車の数としては、例えば、迂回候補車３Ｂ，・・・のうちの何割の台数を対象とするかを予め決めておき、その何割の段階が１段階（例えば、５割）でもよいし、数段階（例えば、３段階の場合、７割、５割、３割）でもよい。さらに、渋滞縮小演算部２０ｅでは、その演算した渋滞区間の縮小度合いに応じて、最短ルート希望車３Ａが渋滞区間を通過する旅行時間を演算する。そして、渋滞縮小演算部２０ｅでは、迂回車がない場合の通常の旅行時間（ＶＩＣＳの渋滞情報、プローブカーによる旅行時間）から迂回車がある場合の旅行時間（迂回車の数に応じた旅行時間）を減算し、その減算値が閾値以上か否かを判定する。この閾値は、付与するポイントに対する旅行時間の短縮効果があるか否かを判断するための閾値であり、予め設定される。閾値は、付与するポイントに応じた可変値でもよく、ポイントが多いほど大きな値とする。その減算値が閾値以上の場合、渋滞縮小演算部２０ｅでは、旅行時間の短縮効果があると判断する。一方、その減算値が閾値未満の場合、渋滞縮小演算部２０ｅでは、旅行時間の短縮効果がないと判断し、迂回車の募集を中止する。なお、渋滞縮小演算部２０ｅでは、旅行時間の短縮効果を得るために最低限必要な迂回車の台数を演算するようにしてもよい。 【００３０】 ポイント管理部２０ｆでは、ポイントデータベース２０ｌに格納されている車載機３０を搭載する全車両（全ユーザ）のポイントの残数や入出力を管理する。ポイント管理部２０ｆでは、迂回実施監視部２０ｇでの迂回ＯＫ車に対する監視が終了すると、迂回ＯＫ車毎に、迂回ＯＫ車が実際に迂回した場合にはポイントを付与し、その迂回ＯＫ車に対して付与したポイント情報を通信機２０ａで送信する。ここでは、迂回した場合には設定されているポイントの全てを付与するようにしてもよいし、あるいは、迂回した場合でも設定されているポイントうち迂回ルートに対する順守率に応じてポイントを付与してもよい。そして、ポイント管理部２０ｆでは、迂回ＯＫ車毎に、付与されたポイント数に応じて、ポイントデータベース２０ｌに格納されているポイントの残数や入力情報を更新する。また、ポイント管理部２０ｆでは、使用したポイント数に応じて、ポイントデータベース２０ｌに格納されている最短ルート希望車３Ａのポイントの残数や出力情報を更新する。なお、ここで利用されるポイントが既存の他のポイントと連動可能なポイントの場合、ポイント管理部２０ｆでは、既存のポイントと連動させてポイントを管理する。 【００３１】 迂回実施監視部２０ｇでは、迂回ＯＫ車毎に、迂回ルートを送信後、その迂回ＯＫ車の定期的な位置情報に基づいて、迂回ＯＫ車の走行軌跡が迂回ルートに従っているかを監視する。そして、迂回ルート終了後、迂回実施監視部２０ｇでは、迂回ＯＫ車が実際に迂回しか否かを判定する。ここでは、迂回ＯＫ車が迂回ルートに従って走行した順守率を演算してもよい。順守率は、迂回ルートを全て走行した場合を１００％として、迂回ルートのうちの何％を走行したかを演算する。 【００３２】 情報通知部２０ｈでは、通信機２０ａを利用して、車載機３０を搭載した各車両に情報を通知する。情報通知部２０ｈでは、周辺迂回候補車把握部２０ｃで迂回候補車３Ｂ，・・・を把握すると、その迂回候補車３Ｂ，・・・に対して迂回希望通知を通信機２０ａからそれぞれ送信する。この迂回希望通知の情報としては、例えば、後方を走行している他の車両（最短ルート希望車３Ａ）が迂回してくれることを希望していること、迂回した場合にもらえるポイント数がある。この迂回車の募集は、必要な迂回車数に達した場合、最短ルート希望車３Ａのポイントを使いきった場合、タイムアウトなどで終了する。また、情報通知部２０ｈでは、空間分散／時間分散演算部２０ｄで迂回ルートを演算すると、迂回ＯＫ車に対して迂回ルートを通信機２０ａからそれぞれ送信する。また、情報通知部２０ｈでは、全ての迂回が終了し、ポイントの付与が終了した場合、最短ルート希望車３Ａに対してその結果を通信機２０ａから送信する。迂回完了の結果としては、例えば、迂回してくれた車両の台数、その各車両に付与したポイント数、付与した全ポイント数がある。また、情報通知部２０ｈでは、迂回の募集を行わなかった場合、最短ルート希望車３Ａに対してその結果を通信機２０ａから送信する。」 「【００７９】 また、本実施の形態では付与するポイントを最短ルート希望車（ユーザ）あるいはセンタで設定する構成としたが、迂回候補車側で設定する構成としてもよい。例えば、迂回候補車から何ポイントでなら迂回するという要求を出す。また、最短ルート希望車あるいはセンタ側で、必要な迂回車が集まるまで、ポイントを徐々に上げていくなどしてもよい。」 イ 甲２（特開２０１７－５９０９９号公報）に記載された事項 甲２には、以下の記載がある。 「【０００１】 本発明は、多数のユーザの行動の全体状況を最適化するために、個別ユーザの行動制御をする技術に関する。」 「【００１６】 なお、本発明は、上記構成ないし機能の少なくとも一部を有する行動制御システムとして捉えることができる。また、本発明は、上記処理の少なくとも一部を含む行動制御方法、又は、かかる方法をコンピュータに実行させるためのプログラム、又は、そのようなプログラムを非一時的に記録したコンピュータ読取可能な記録媒体として捉えることもできる。上記構成及び処理の各々は技術的な矛盾が生じない限り互いに組み合わせて本発明を構成することができる。」 「【００２２】 （システムの概要） 図１は、実施例１に係る行動制御システム（以下、単に「システム」とも呼ぶ）の概要を示している。行動制御システムは、インターネット上のサーバ装置により構成されており、各ユーザがもつ端末装置や、他の装置（交通情報などを提供するサーバ、データベース、センサなど）とインターネットを通じて通信可能である。」 「【００２４】 システムは、各ユーザの特性および状態のデータと、他の装置から取得できる交通状況関連情報（例えば、カレンダー情報、近隣のイベント情報、道路に設置されたセンサの情報、気象情報、渋滞予測情報など）に基づいて、当該地域内の現時点および近い将来の交通状況を推定する。渋滞が発生している場合、又は、渋滞発生が予測できた場合、システムは、地域内の車を時間的・空間的に分散させるため、ユーザに対し行動変更をレコメンドするコンテンツを提供する。端末装置で受信したコンテンツを見たユーザが、そのコンテンツのレコメンドを受け入れ、行動を変更（迂回路の選択、行き先や出発時刻の変更、他の交通機関や徒歩の利用など）すると、渋滞の緩和や防止を実現できる。」 「【００２９】 行動を変更した人に対しインセンティブを授与してもよい。インセンティブは、ユーザが喜ぶであろう情報、モノ、金銭、権利などである。例えば、「情報」の例として、詳細な道路交通情報、シークレットセールの情報など、「モノ」の例として、電車移動時の快適グッズなど、「金銭」の例として、キャッシュ、有料道路や駐車場や店舗での割引券、無料券、クーポン券、パーキングメータ延長券、ポイント、デジタルマネーなど、「権利」の例として、優先レーン利用、車両入場規制のある地域や道路の利用、商品の先行購買権などが例示できる。蓄積ポイント数に応じて上記の情報、モノ、金銭、権利に交換可能にしてもよい。これによりコンテンツ受入率を向上し、渋滞緩和や渋滞防止の効果を高めることができる。ただし、インセンティブの授与は、道路管理者やシステム運営者の運用コストを増大させるため、提供コンテンツに優先順位を設け、コストがかからないものから優先してコンテンツ提供していくとよい。なお、ユーザの特性や状態に応じて授与するインセンティブの種類や内容を変更してもよい。また、コンテンツをよく受け入れてくれる人（受入ｘ回以上、受入率ｘ％）や、あまり人気のないコンテンツを受け入れてくれる人（電車に乗ったり、時間差で移動してくれる）などは、別途ポイントがたまったり、ポイントの累積率が上がったり、また次回以降の適切なタイミングでインセンティブ付きコンテンツが配信される確率が高くなるような仕組みを採用することも好ましい。 【００３０】 （システム構成） 図２は、実施例１の行動制御システムの全体構成を示すブロック図である。行動制御システム１００は、ユーザの端末装置２００や他の装置３００とインターネットを通じて通信可能である。図２では、端末装置２００と他の装置３００が１台ずつしか示されていないが、実際のシステムでは、地域内の登録ユーザ（例えば数百人から数万人）全員の端末装置２００が存在し、また、他の装置３００も複数存在し得る。 【００３１】 行動制御システム１００は、ＣＰＵ、メモリ、大容量の記憶装置、通信装置などを備えた汎用のコンピュータシステムにより構成可能である。複数台のサーバ装置により冗長かつ堅牢な構成としたり、分散処理を実現したりすることが望ましい。後述する行動制御システム１００の処理及び機能は、記憶装置に格納されたプログラムがＣＰＵによって実行されることでソフトウェア的に実現されるものである。また、端末装置２００は、ＣＰＵ、メモリ、大容量の記憶装置、通信装置、入力装置、表示装置などを備える汎用のコンピュータシステムにより構成可能である。具体的には、スマートフォン、タブレットＰＣ、モバイルＰＣ、カーナビゲーション装置、ウェアラブル端末などが想定される。行動制御システム１００を利用する際には、専用のアプリケーションプログラム（以下、単に「アプリ」とも呼ぶ）を端末装置２００にインストールすることで、個人の特性や状態の通知、センサデータの送信、コンテンツの受信・閲覧などが可能となる。」 「【００３８】 コンテンツ効果管理ＤＢ１３５は、過去に提供したコンテンツの行動変更率が記録されるデータベースである。図６と図７にコンテンツ効果管理ＤＢ１３５のデータ構造の一例を示す。図６は、個人特性や状態に基づき登録ユーザを複数の集団（クラスタ）に分け、クラスタ別、コンテンツの内容別に、行動変更率（受入率とも呼ぶ）を記録したデータベースである。行動変更率とは、コンテンツを提供したユーザの総数に対する、コンテンツに従って実際に行動を変更したユーザの割合である。図７は、各コンテンツの提供優先順位、コンテンツの内容（種類）、受入条件（受入上限数など）を記録したデータベースである。 【００３９】 交通状況履歴ＤＢ１５１は、過去の交通状況（渋滞状況）の履歴を記録するデータベースである。また、交通状況予測ＤＢ１５２は、端末装置２００や他の装置３００から集めたデータをもとに予測した現在から将来の交通状況（渋滞状況）を記録するデータベースである。」 「【００４２】 （１）端末装置２００の動作 ユーザが車での移動を開始する際に、端末装置２００の専用アプリを起動し、目的地、出発予定時刻、到着予定時刻、経路、同乗者の有無などの個人状態値を入力する（ステップＳ１００）。すると、端末装置２００が、現在のユーザの状態を把握するため、端末装置２００に搭載されたセンサから、ＧＰＳ情報、加速度情報、時刻情報などのセンサデータを取得し（ステップＳ１０１）、専用アプリで取得したユーザの状態とセンサデータを、行動制御システム１００に送信する（ステップＳ１０２）。行動制御システム１００は、地域内の複数のユーザから収集したデータをもとに交通状況の変化を随時予測し、必要に応じてユーザに対しコンテンツ提供を行う（詳しくは後述）。なお、ユーザが車での移動を開始する際に、ユーザ自身がアプリの起動操作をするのではなく、カレンダーの予定、ＧＰＳでの場所情報、ユーザの普段の行動履歴などに基づき、アプリが自動で起動するようにしてもよい。 【００４３】 端末装置２００の専用アプリは、行動制御システム１００からコンテンツを受信するのを待ち受ける（ステップＳ１０３、Ｓ１０４；Ｎｏ）。移動が終了（目的地に到着または目的地を変更）するまでの間（ステップＳ１０５；Ｎｏ）、端末装置２００は、ユーザの個人状態値とセンサデータを定期的に行動制御システム１００に通知する（ステップＳ１０１、Ｓ１０２）。このような仕組みにより、ユーザの状態がリアルタイムに行動制御システム１００に収集・蓄積されていく。 【００４４】 端末装置２００の専用アプリは、行動制御システム１００からコンテンツを受信すると（ステップＳ１０４；Ｙｅｓ）、そのコンテンツをユーザに提示する（ステップＳ１０６）。図１１は、端末装置２００の画面に表示されたコンテンツの例である。迂回路をレコメンドする情報が表示されるとともに、このコンテンツを受け入れるか否かを選択させるボタンが表示される。ユーザは、コンテンツを受け入れレコメンドに従う場合には、「受入」ボタンを押し、レコメンドに従いたくない場合には、「拒否」ボタンを押す（ステップＳ１０７）。ユーザの選択結果は行動制御システム１００に送られる（ステップＳ１０８）。 【００４５】 ユーザがコンテンツに気づかない場合、あるいは、興味のないコンテンツである場合には、ボタンが押されない可能性もある。所定の時間、ボタンが押されなければ、専用アプリはコンテンツがスルーされたと判断し、コンテンツを非表示にするかボタンを選択不可にする。また、コンテンツ受入上限数が決められているコンテンツの場合には、コンテンツを受け入れたユーザの数が上限数に到達すると、その情報が行動制御システム１００から端末装置２００に通知され、コンテンツが非表示（またはボタンが選択不可）となる。 【００４６】 ユーザがコンテンツを受け入れた場合（ステップＳ１０９；Ｙｅｓ）、ステップＳ１１０へと進む。端末装置２００は、移動が終了（目的地に到着または目的地を変更）するまでの間（ステップＳ１１２）、ＧＰＳや加速度などのセンサデータを定期的に取得し（ステップＳ１１０）、行動制御システム１００へ送信する（ステップＳ１１１）。これにより、コンテンツ受入後のユーザの移動経路や交通手段などを行動制御システム１００が把握することができる。 【００４７】 移動終了後、行動制御システム１００から、ユーザが実際に採った移動経路や移動手段、あるいは移動時刻が、ユーザが受け入れたコンテンツの条件を満たしていたかどうかの結果が送信されてくるので、端末装置２００はその結果情報を受信する（ステップＳ１１３）。なお本実施例では、コンテンツの条件を満たしたかどうか（ユーザがコンテンツのレコメンド通りに行動を変更したかどうか）の判断を行動制御システム１００側で行ったが、端末装置２００側で行い、その結果を端末装置２００から行動制御システム１００に通知してもよい。 【００４８】 ユーザがコンテンツの条件を満たす移動を実行していた場合には（ステップＳ１１４；Ｙｅｓ）、専用アプリにユーザの行動変更を賞賛するメッセージなどを表示する（ステップＳ１１５）。また、コンテンツがインセンティブを授与する内容のものであった場合には、ユーザに対してインセンティブを授与する。例えば、店舗で利用できるクーポンを表示したり、ＥＴＣの割引コードを表示したり、ポイントやデジタルマネーを付与したりなど、インセンティブの授与方法はどのようなものでもよい。」 【００４９】 （２）行動制御システム１００の動作 行動制御システム１００（ユーザ情報登録部１２１）は、各ユーザの端末装置２００から初期設定値（個人特性値）を受信すると、そのデータをユーザ特性管理ＤＢ１３１に保存する（ステップＳ２００）。ユーザの新規登録時（専用アプリのインストール時）、ユーザの個人特性に変更があった時などに、この処理が実行される。 【００５０】 また、行動制御システム１００（ユーザ情報登録部１２１）は、各ユーザの端末装置２００から個人状態値とセンサデータを受信すると、そのデータをユーザ状態管理ＤＢ１３２およびユーザセンサデータ管理ＤＢ１３４に保存する（ステップＳ２０１）。この処理は、端末装置２００からデータが送られてくるたびに（図９のステップＳ１０２、Ｓ１１１参照）実行される。 【００５１】 行動制御システム１００（交通状況把握・予測／渋滞判定部１４１）は、ユーザから収集した個人状態値およびセンサデータと、他の装置３００から収集した交通状況関連情報に基づいて、現在の交通状況を把握するとともに、近い将来（例えば数十分から数時間後）の交通状況を予測する（ステップＳ２０２）。交通状況関連情報としては、例えば、カレンダー情報（日付、曜日、祝日、季節など）、地域のイベント情報、道路に設置されたセンサの情報（トラフィックカウンタなど）、気象情報、工事情報、渋滞予測情報など、交通状況の把握や予測に利用可能な情報であればどのような情報を用いてもよい。ステップＳ２０２で把握ないし予測された結果は、交通状況履歴ＤＢ１５１および交通状況予測ＤＢ１５２に保存される。 【００５２】 行動制御システム１００（交通状況把握・予測／渋滞判定部１４１）は、ステップＳ２０２の結果をもとに、地域内の道路ですでに渋滞が発生しているか、または渋滞が発生する可能性が高いかを判断する。当分のあいだ渋滞が発生しそうになければ、対策を打たなくてよいので、なにもしない（ステップＳ２０３；Ｎｏ）。渋滞が発生している、またＳは、近い将来渋滞が発生しそうだと判断であれば（ステップＳ２０３；Ｙｅｓ）、ステップＳ２０４に進む。 【００５３】 ステップＳ２０４では、行動制御システム１００（平準化モデル生成部１４２）が、地域内の車をどのように空間的・時間的に分散したり、車の数をどの程度減らしたりすれば、渋滞が緩和または渋滞発生を防止できるか計算する。地域内の人ができるだけ希望どおりの移動手段や経路で移動でき、かつ渋滞が発生しない状態が理想である。 【００５４】 例えば、対象となる地域内に、図８に示すように、一般道の本線と迂回路があり、電車も利用可能である状況を想定する。各道路の許容車両台数（渋滞が発生しない上限の車両台数）は、本線が７０台、迂回路が３０台であるとする。ステップＳ２０２において、１５時に各道路を走行しているであろう車両の台数が、本線：１００台（渋滞）、迂回路：１０台（非渋滞）と予測されたとする。このような場合、地域内の渋滞を緩和ないし防止するため、１５時に本線を走行する車両台数を７０台以下にすることが行動制御システム１００の目的となる。このとき、車両を迂回路に誘導してもよいが、迂回路を渋滞させてはならない。そうすると、上記目的を達成するための平準化モデルは、「本線から迂回路に２０台移動し、残り１０台は通行時間または交通手段を変更する」という対策となる。 【００５５】 図１２は、平準化モデル生成処理（ステップＳ２０４）の詳細フローである。平準化モデル生成部１４２は、走行中または走行開始予定の車のなかから、対象時刻（渋滞緩和させたい時刻）に、対象道路（渋滞緩和させたい道路）を走行する予定の車を抽出する（ステップＳ３００）。上記の想定例では、１５時に本線を走行すると予想される車が抽出され、その数が１００台であることがわかる。次に、平準化モデル生成部１４２は、対象道路から、当該時刻に何台の車を減らすべきかを計算する（ステップＳ３０１）。上記の想定例では、本線の許容車両台数が７０台であるため、１５時に本線から３０台の車を減らすべきであると計算される。次に、平準化モデル生成部１４２は、地域内に他の経路や他の移動手段がないか探索する（ステップＳ３０２）。具体的には、地域内交通経路ＤＢ１５３の地図情報および許容台数情報を参照し、代替経路や代替移動手段を選択する。このとき、移動時間や移動距離がより短いもの、有料道路より一般道、道幅がより広い道、という基準で代替経路や代替移動手段を選ぶとよい。次に、平準化モデル生成部１４２は、代替経路や代替移動手段ごとに、受入許容台数を算出する（ステップＳ３０３）。上記の想定例では、迂回路に２０台、電車または時間差移動に１０台、と計算される。 【００５６】 以上のとおり平準化モデルが生成されると、図１０のステップＳ２０５に進み、行動制御システム１００（コンテンツ選択／提供部１４３）が、コンテンツの提供先および提供コンテンツの内容（種類）などを決定し、必要なユーザにコンテンツを送信する。このとき、ユーザ特性管理ＤＢ１３１、ユーザ状態管理ＤＢ１３２、コンテンツ効果管理ＤＢ１３５の情報に基づき、コンテンツ選択／提供部１４３は、地域内のどのユーザに対し、どのような内容のコンテンツを提供するとよいかを判断する。ユーザの特性や状態などを考慮することで、実行が不可能なコンテンツ、ユーザにストレスや安全面での不安を与えるコンテンツなどが提供されないようにする一方で、過去のコンテンツ受入率などを考慮することで、コンテンツを受け入れ、行動を変更してくれる可能性の高いユーザに優先的にコンテンツを提供する。 【００５７】 図１３は、コンテンツ提供処理（ステップＳ２０５）の詳細フローである。コンテンツ選択／提供部１４３は、まず、コンテンツ提供優先順位を０で初期化する（ステップＳ４００）。コンテンツ選択／提供部１４３は、コンテンツ提供優先順位をインクリメントしながら（ステップＳ４０１）、コンテンツ効果管理ＤＢ１３５（図７参照）に登録されているコンテンツを提供優先順位の高いものから順に注目する（ステップＳ４０２）。コンテンツ選択／提供部１４３は、注目したコンテンツが現在の環境下で受け入れ可能なコンテンツか否かを判断し（ステップＳ４０３）、受け入れ可能性のあるコンテンツであれば、その注目したコンテンツを提供コンテンツとして選択する（ステップＳ４０４）。例えば、迂回路のない地域で迂回路利用をレコメンドするコンテンツを提供したり、電車やバスなどがない地域で代替交通手段をレコメンドするコンテンツを提供しても、ユーザは受け入れ不可能なため、ステップＳ４０３では、そのようなコンテンツが提供コンテンツから外される。ステップＳ４０１～Ｓ４０３の処理が、全体状況を全体最適の状態に近づけるためにユーザが行うべき行動を決定する行動決定手段の処理に該当する。 【００５８】 提供コンテンツが選択されると、コンテンツ選択／提供部１４３は、その提供コンテンツの提供先となるユーザを選択し、そのユーザの端末装置２００にコンテンツを送信する（ステップＳ４０５）。 ・・・ 中 略 ・・・ 【００６６】 その後、コンテンツ選択／提供部１４３は、コンテンツ受入人数を予測し（ステップＳ５０８）、図１３のステップＳ４０６に進む。ステップＳ４０６では、コンテンツ選択／提供部１４３は、コンテンツの受入予測人数（複数種類のコンテンツ提供を行った場合は、その合計人数）が、渋滞緩和させたい道路から減らすべき車の数に達したかを確認する（ステップＳ４０６）。必要な台数分、車が減らせると予想できたら（ステップＳ４０６；Ｙｅｓ）、ステップＳ４０７に進み、受入予測人数が必要な台数に達してなければ（ステップＳ４０６；Ｎｏ）、ステップＳ４０１に戻って別のコンテンツの提供を検討する。 【００６７】 コンテンツ提供後、コンテンツ選択／提供部１４３は、一定時間、ユーザの端末装置２００からの選択結果（受入／拒否）を受け付ける（ステップＳ４０７、Ｓ４０８）。タイムアウト、もしくはコンテンツの受入上限数に到達した場合は、受付を締め切り、ステップＳ４０９に進む。コンテンツを受け入れてくれたユーザの数が、渋滞緩和させたい道路から減らすべき車の数に到達していれば（ステップＳ４０９；Ｙｅｓ）、図９のステップＳ２０６へ進む。一方、受け入れ人数が足りない場合は（ステップＳ４０９；Ｎｏ）、ステップＳ４００に戻り、コンテンツの再配信を行う。再配信の場合は、すでに提供したコンテンツと同じものを選んでもよいし、別のコンテンツを優先的に選んでもよい。また、コンテンツの提供先（ユーザ）を選ぶ際は、前回コンテンツを提供したユーザとは別のユーザを優先的に選ぶとよい。 【００６８】 図９のステップＳ２０６では、ユーザ情報登録部１２１が、コンテンツを受け入れたユーザの端末装置２００から個人状態値とセンサデータを受信し、そのデータをユーザ状態管理ＤＢ１３２およびユーザセンサデータ管理ＤＢ１３４に保存する。センサデータに基づき、ユーザが目的地に到着したか（あるいは目的地を変更したか）を判断し、目的地に到着（あるいは目的地を変更）するまで、当該ユーザのセンサデータ（つまり移動の履歴）を記録し続ける（ステップＳ２０７）。 【００６９】 ステップＳ２０８では、コンテンツ効果判定部１４４が、コンテンツの提供を受けたユーザがコンテンツに従って実際に行動を変更したか否かを確認する。具体的には、コンテンツ効果判定部１４４は、ユーザのセンサデータの記録（移動履歴）に基づき、当該ユーザが実際に採った移動経路や移動手段、あるいは移動時刻が、当該ユーザが受け入れたコンテンツの条件を満たしていたかを判定し、その判定結果をユーザの端末装置２００に送信する。 【００７０】 最後に、コンテンツ効果判定部１４４が、各ユーザがどのような特性・状態のときに、コンテンツ通りに行動を変えたかどうかを分析し、その分析結果をユーザ行動パターン管理ＤＢ１３３に記録する。また、コンテンツ効果判定部１４４は、データマイニングにより、交通デマンド制御の効果測定を行い、地域全体の行動パターンを分析する。例えば、コンテンツ効果判定部１４４は、システムに登録されている全ユーザを特性・状態の共通性に基づきクラスタリングし、どのような特性・状態の人が、どのような内容のコンテンツを提供されたら、何％程度の行動変化が期待できるかを整理し、その情報をコンテンツ効果管理ＤＢ１３５に保存する。効果判定の結果は、前述のように、コンテンツの提供先の選択に利用される。ユーザが行動を変えるたび、または定期的にコンテンツ効果の判定を行うことで、より適切なコンテンツ提供先の選択が可能となり、コンテンツ受入率の向上を期待できる。」 「【００７１】 （コンテンツ提供の例） 次に、コンテンツ提供の具体例を説明する。図８に示す地域において、１５時に本線に１００台、迂回路に１０台の車両が走行することが予測された場合に、「１５時に本線から迂回路に２０台移動し、残り１０台は通行時間または交通手段を変更してもらう」という交通デマンド制御を行う例を想定する。図１５は、コンテンツ提供の流れを示すフロー図である。図１５の横軸は時間軸であり、左側のコンテンツ提供から順に実行される様子を示している。 【００７２】 （１）「迂回」コンテンツの提供 まずは、提供優先順位の最も高い「迂回」コンテンツが選択される。「迂回」コンテンツは、迂回への協力をお願いするコンテンツである。「迂回」コンテンツは、インセンティブ授与が無い分コストが安いので、優先的に実行される。 【００７３】 各種ＤＢに基づき、「クラスタ番号ａ，ｂ，ｃに当てはまる人は、迂回をお願いすると、１０％の確率でコンテンツを受け入れる」こと、「１５時に本線走行予定で、クラスタ番号ａ，ｂ，ｃに当てはまり、運転レベルやストレスレベルに問題のない人は、２０人いる」ことが確認できたとする。２０人×１０％＝２人は協力してくれると予測した上で、その２０人に対し「迂回」コンテンツが配信される。システムは、この２０人から選択結果（受入／拒否）を受信するのを待ち、コンテンツを受け入れた人数が受入予測人数（ここでは２人）に達するか、一定時間が経過したら、受付を終了する。図１５の例では、１人のユーザがコンテンツを受け入れたと仮定する。 【００７４】 （２）「駐車場割引＋迂回」コンテンツの提供 「迂回」コンテンツの受入予測人数は２人であり、目的達成（２０台を迂回路にまわす）のためには、残り１８人の行動変更が必要である。そこで、次に提供優先順位の高い「駐車場割引＋迂回」コンテンツが提供される。駐車場割引券というインセンティブが付加されたコンテンツである。 【００７５】 各種ＤＢに基づき、「クラスタ番号ｄ，ｅ，ｆに当てはまる人は、迂回してくれたら駐車場割引券を提供するという提案に対し、５０％の確率でコンテンツを受け入れる」こと、「１５時に本線走行予定で、クラスタ番号ｄ，ｅ，ｆに当てはまり、（１）で既にコンテンツを配信した２０人とは異なり、運転レベルやストレスレベルに問題のない人は、８０人いる」ことが確認できたとする。８０人×５０％＝４０人は協力してくれると予測される。駐車場割引券は発行枚数制限が特にない。しかし、４０人全員に迂回されると、迂回路が状態を起こしていまう。そこで、８０人から３６人を無作為抽出し、その３６人に対し「駐車場割引＋迂回」コンテンツが配信される。システムは、この４０人から選択結果（受入／拒否）を受信するのを待ち、コンテンツを受け入れた人数が１８人に達するか、一定時間が経過したら、受付を終了する。図１５の例では、１８人のユーザがコンテンツを受け入れたと仮定する。 【００７６】 （３）「時間差移動」コンテンツの提供 ここまでのコンテンツ提供により、２０台の車が本線から迂回路へ移ると期待できる。目的達成のためには、残り１０台を本線から減らさなければならない（但し、迂回路にはもう移せないので、通行時間又は交通手段の変更が必要である）。そこで、迂回以外のコンテンツのうち次に提供優先順位の高い「時間差移動」コンテンツが提供される。 【００７７】 各種ＤＢに基づき、「クラスタ番号ｇ，ｈ，ｉに当てはまる人は、時間差移動をお願いすると、５％の確率でコンテンツを受け入れる」こと、「１５時に本線走行予定で、クラスタ番号ｇ，ｈ，ｉに当てはまり、（１）と（２）で既にコンテンツを配信した人とは異なり、運転レベルやストレスレベルに問題のない人は、６０人いる」ことが確認できたとする。６０人×５％＝３人は協力してくれると予測した上で、その６０人に対し「時間差移動」コンテンツが配信される。システムは、この６０人から選択結果（受入／拒否）を受信するのを待ち、一定時間が経過したら、受付を終了する。何人が時間差移動しても構わないので、特に受入人数の上限を設けなくてよい。図１５の例では、５人のユーザがコンテンツを受け入れたと仮定する。 【００７８】 （４）「飲食店無料券＋電車」コンテンツの提供 「時間差移動」コンテンツの受入予測人数は３人であり、目的達成（１０人の通行時間又は交通手段を変更）のためには、残り７人の行動変更が必要である。そこで、迂回以外のコンテンツのうち次に提供優先順位の高い「飲食店無料券＋電車」コンテンツが提供される。飲食店無料券というインセンティブが付加されたコンテンツである。 【００７９】 各種ＤＢに基づき、「クラスタ番号ｊ，ｋ，ｌに当てはまる人は、電車移動してくれたら飲食店無料券を提供するという提案に対し、６０％の確率でコンテンツを受け入れる」こと、「１５時に本線走行予定で、クラスタ番号ｊ，ｋ，ｌに当てはまり、（１）、（２）、（３）で既にコンテンツを配信した人とは異なり、運転レベルやストレスレベルに問題のない人は、３００人いる」ことが確認できたとする。３００人×６０％＝１８０人は協力してくれると予測される。飲食店無料券の発行には管理者の経費コストがかかるため、その発行枚数は３０枚までに制限されているとする。また、「時間差移動」に３人が協力してくれると期待できるため、残り７人が「飲食店無料券＋電車」コンテンツを受け入れてくれればよい。そこで、３００人から３０人を無作為抽出し、その３０人に対し「飲食店無料券＋電車」コンテンツが配信される。システムは、この３０人から選択結果（受入／拒否）を受信するのを待ち、コンテンツを受け入れた人数が７人に達するか、一定時間が経過したら、受付を終了する。図１５の例では、７人のユーザがコンテンツを受け入れたと仮定する。」 「【図２】 ［図：0001397186000001.jpg］ 」 「【図７】 ［図：0001397186000002.jpg］ 」 「【図１１】 ［図：0001397186000003.jpg］ 」 段落【００２４】【００７２】【００７４】【００７６】【００７８】及び図７の記載から、地域内の車を時間的・空間的に分散させるため、ユーザに対し行動変更をレコメンドするコンテンツの内容は、「迂回」「時間差移動」「電車」のいずれかを含むものであるとともに、インセンティブが付加されたコンテンツを含むことが見て取れる。 また、図７の記載から、「コンテンツ管理ＤＢ１３５」には、「提供優先順位」の順位情報と、「コンテンツ内容」の「インセンティブが付加されたコンテンツを含むコンテンツ」が登録されていることが見て取れる。 段落【００４４】及び図１１から、コンテンツには「本日１５時頃、国道Ａ号のＢ交差点付近で渋滞の発生が予想されますので、迂回路（県道Ｃ号）の通行をお願いします。」との文章が含まれていることが、見て取れる。 上記記載から、甲２には、以下の発明（以下、「引用発明２」という。）が記載されている。 「ユーザの端末装置２００や他の装置３００とインターネットを通じて通信可能である、行動制御システム１００の、処理及び機能をソフトウェア的に実現させるプログラムであって、（【００３０】、【００３１】） ユーザから収集した個人状態値およびセンサデータと、他の装置３００から収集した交通状況関連情報に基づいて、現在の交通状況を把握するとともに、近い将来（例えば数十分から数時間後）の交通状況を予測（ステップＳ２０２）し、（【００５１】） ステップＳ２０２の結果をもとに、地域内の道路ですでに渋滞が発生しているか、近い将来渋滞が発生しそうだと判断であれば、ステップＳ２０４に進み、（【００５２】） ステップＳ２０４（平準化モデル生成処理）では、走行中または走行開始予定の車のなかから、対象時刻（渋滞緩和させたい時刻）に、対象道路（渋滞緩和させたい道路）を走行する予定の車を抽出（ステップＳ３００）、対象道路から、当該時刻に何台の車を減らすべきかを計算し（ステップＳ３０１）、地域内に他の経路や他の移動手段がないか探索し（ステップＳ３０２）、代替経路や代替移動手段ごとに、受入許容台数を算出する（ステップＳ３０３）ことにより平準化モデルが生成され、（【００５５】） 対象となる地域内に、一般道の本線と迂回路があり、電車も利用可能である状況を想定し、各道路の許容車両台数（渋滞が発生しない上限の車両台数）は、本線が７０台、迂回路が３０台であるとし、ステップＳ２０２において、１５時に各道路を走行しているであろう車両の台数が、本線：１００台（渋滞）、迂回路：１０台（非渋滞）と予測され、地域内の渋滞を緩和ないし防止するため、１５時に本線を走行する車両台数を７０台以下にすることを行動制御システム１００の目的とし、この目的を達成するための平準化モデルは、「本線から迂回路に２０台移動し、残り１０台は通行時間または交通手段を変更する」（迂回路に２０台、電車または時間差移動に１０台）であり、（【００５４】【００５５】） ステップＳ２０４で平準化モデルが生成されると、「迂回」「時間差移動」「電車」のいずれかを含む、地域内の車を時間的・空間的に分散させるため、ユーザに対し行動変更をレコメンドするコンテンツを提供するコンテンツ提供処理（ステップＳ２０５）に進み、「コンテンツ管理ＤＢ１３５」には、「提供優先順位」の順位情報と、「コンテンツ内容」の「インセンティブが付加されたコンテンツを含むコンテンツ」が登録されており、（【００２４】【００５６】【００７２】【００７４】【００７６】【００７８】及び図７） コンテンツ提供処理（ステップＳ２０５）では、 コンテンツ提供優先順位を０で初期化し（ステップＳ４００）、コンテンツ提供優先順位をインクリメントしながら（ステップＳ４０１）、コンテンツ効果管理ＤＢ１３５に登録されている、「提供優先順位」と、「インセンティブが付加されたコンテンツを含むコンテンツ」から、提供優先順位の高いものから順に注目（ステップＳ４０２）し、注目したコンテンツが現在の環境下で受け入れ可能なコンテンツか否かを判断し（ステップＳ４０３）、受け入れ可能性のあるコンテンツであれば、その注目したコンテンツを提供コンテンツとして選択し（ステップＳ４０４）、（【００５７】） 提供コンテンツが選択されると、その提供コンテンツの提供先となるユーザを選択し、そのユーザの端末装置２００にコンテンツを送信し（ステップＳ４０５）、（【００５８】） コンテンツの受入予測人数（複数種類のコンテンツ提供を行った場合は、その合計人数）が、渋滞緩和させたい道路から減らすべき車の数に達したかを確認し（ステップＳ４０６）、必要な台数分、車が減らせると予想できたら（ステップＳ４０６；Ｙｅｓ）、ステップＳ４０７に進み、受入予測人数が必要な台数に達してなければ（ステップＳ４０６；Ｎｏ）、ステップＳ４０１に戻って別のコンテンツの提供を検討し、（【００６６】） コンテンツ提供後、一定時間、ユーザの端末装置２００からの選択結果（受入／拒否）を受け付け（ステップＳ４０７、Ｓ４０８）、タイムアウト、もしくはコンテンツの受入上限数に到達した場合は、受付を締め切り、ステップＳ４０９に進み、コンテンツを受け入れてくれたユーザの数が、渋滞緩和させたい道路から減らすべき車の数に到達していれば（ステップＳ４０９；Ｙｅｓ）、ステップＳ２０６へ進み、受け入れ人数が足りない場合は（ステップＳ４０９；Ｎｏ）、ステップＳ４００に戻り、コンテンツの再配信を行い、（【００６７】） ステップＳ２０６で、ユーザ情報登録部１２１が、コンテンツを受け入れたユーザの端末装置２００から個人状態値とセンサデータを受信し、そのデータをユーザ状態管理ＤＢ１３２およびユーザセンサデータ管理ＤＢ１３４に保存し、センサデータに基づき、ユーザが目的地に到着したか（あるいは目的地を変更したか）を判断し、目的地に到着（あるいは目的地を変更）するまで、当該ユーザのセンサデータ（つまり移動の履歴）を記録し続け（ステップＳ２０７）、（【００６８】） ステップＳ２０８では、コンテンツ効果判定部１４４が、コンテンツの提供を受けたユーザがコンテンツに従って実際に行動を変更したか否かを確認し、当該ユーザが受け入れたコンテンツの条件を満たしていたかを判定し、その判定結果をユーザの端末装置２００に送信する、（【００６９】） プログラムであり、 車で移動をするユーザの端末装置２００では、（【００４２】） 端末装置２００の専用アプリが、行動制御システム１００からコンテンツを受信するのを待ち受け（ステップＳ１０３、Ｓ１０４；Ｎｏ)、行動制御システム１００からコンテンツを受信されると（ステップＳ１０４；Ｙｅｓ）、そのコンテンツをユーザに提示し（ステップＳ１０６）、（【００４３】、【００４４】） ユーザが、コンテンツを受け入れレコメンドに従う場合には、「受入」ボタンを押し、ユーザの選択結果は行動制御システム１００に送られ（ステップＳ１０８）、（【００４４】）コンテンツには「本日１５時頃、国道Ａ号のＢ交差点付近で渋滞の発生が予想されますので、迂回路（県道Ｃ号）の通行をお願いします。」との文章が含まれており、（【００４４】図１１） ユーザがコンテンツを受け入れた場合（ステップＳ１０９；Ｙｅｓ）、移動が終了（目的地に到着または目的地を変更）するまでの間（ステップＳ１１２）、ＧＰＳや加速度などのセンサデータが定期的に取得され（ステップＳ１１０）、行動制御システム１００へ送信し（ステップＳ１１１）、（【００４６】） 移動終了後、行動制御システム１００から、ユーザが実際に採った移動経路や移動手段、あるいは移動時刻が、ユーザが受け入れたコンテンツの条件を満たしていたかどうかの結果情報が受信され（ステップＳ１１３）、（【００４７】） ユーザがコンテンツの条件を満たす移動を実行していた場合には（ステップＳ１１４；Ｙｅｓ）、ユーザに対してインセンティブが授与され（ステップＳ１１５）、インセンティブは、例えば、店舗で利用できるクーポンを表示したり、ＥＴＣの割引コードを表示したり、ポイントやデジタルマネーである、（【００４８】） プログラム。」 また、段落【００５１】の記載から、甲２には以下の事項（以下、「甲２記載事項」という。）が記載されている。 「行動制御システム１００は、気象情報を考慮すること。」 ウ 甲３（特開２０１８－１０９８４０号公報）に記載された事項 甲３には、以下の記載がある。 「【０００１】 本発明は、ゲームにおいて所与の広告を出力制御させるコンピュータシステム等に関する。」 「【００４１】 ［ハードウェア構成の説明］ 先ず、本実施形態におけるハードウェアの構成例について説明する。 図１は、本実施形態における広告出力制御システムとして機能するゲームシステムの構成の一例を示す図である。本実施形態のゲームシステム１０００は、通信回線９に接続することで相互にデータ通信が可能なサーバシステム１１００とユーザ端末１５００とを含むコンピュータシステムである。図示の例では、ユーザ端末１５００を１台としているが、実際の運用に当たってはプレーヤであるユーザ別（以下、単に「プレーヤ」と言う。）に複数のユーザ端末１５００が存在し、各々がサーバシステム１１００と通信接続可能な状態となり得る。ゲームシステム１０００全体をコンピュータシステムと呼ぶこともできるが、サーバシステム１１００やユーザ端末１５００それぞれを個別のコンピュータシステムと呼ぶこともできる。」 「【００７５】 そして、広告視聴可能なタイミングと判定されると、ユーザ端末１５００にて、例えば図４に示すような広告オファー画面Ｗ３が表示される。広告オファー画面Ｗ３は、広告視聴の承認操作を受け付ける画面であって、画面説明２０と、視聴予定広告説明部２１と、視聴拒否操作アイコン２２と、第１承認操作アイコン２３と、第２承認操作アイコン２４と、画面消去操作アイコン２５と、を有する。」 「【００８２】 そして、第２承認操作アイコン２４への操作が検出されると、図５に示すような設定画面Ｗ４がユーザ端末１５００にて表示される。 本実施形態の設定画面Ｗ４は、画面説明２０と、視聴予定広告説明部２１と、画面消去操作アイコン２５と、入力要素候補提示部３０と、入力要素説明部３１と、出力要素とされるアイテムを予告表示する予告部７０と、変換スキップ操作アイコン７１と、変換実行操作アイコン７２と、を有する。」 「【００８７】 予告部７０には、本設定によりプレーヤが得られる強化・進化の結果を予告表示する。 本実施形態では、ユーザは広告の視聴を途中で中止・中断することが可能であり、その場合、当該広告の視聴所要時間に対する実視聴時間の割合に応じて、向上制御の程度、換言すると強化・進化の度合が低減される。例えば、視聴所要時間に対して実視聴時間の割合が１００％ならば、レベル「２」からレベル「４」へ性能が向上するところが、割合が５０％であれば、レベル「２」からレベル「３」への性能向上に低減される。そこで、本実施形態の予告部７０では、視聴対象広告を１００％視聴した完了時に獲得できる出力要素と、視聴を５０％で中断した場合に獲得される出力要素とについての情報を表示することとする。なお、実視聴時間の割合と低減度合の関係は、ここで例示した関係に限らず、入力要素とされたアイテムの内容に応じて適宜設定可能である。」 「【００８９】 変換実行操作アイコン７２は、当該設定画面の設定を適用して、広告視聴とアイテム変換とを実行させる操作を入力するためのアイコンである。変換実行操作アイコン７２への操作が検出されると、設定画面Ｗ４が消えて広告視聴が開始され、視聴完了後或いは視聴が中断されると、設定画面Ｗ４で選択設定した入力要素１０に代えて（入力要素１０が消費されて、と言うこともできる）、出力要素１４がプレーヤに付与される（図３参照）。なお、出力要素１４の付与は、入力要素１０に紐付けられている能力のパラメータ値や、表示形態に係るデータを書き換えにより実現するとしてもよい。」 「【０１３８】 広告情報条件５７２は、視聴対象広告に関する要件を定義する。本実施形態では、例えば図１１に示すように、 １）特定の広告を示す広告ＩＤのリストが設定される広告ＩＤ条件５７２ａと、 ２）広告内容についての特定のカテゴリーのリストが設定されるカテゴリー条件５７２ｂと、 ３）特定の広告の出稿者のリストが設定される出稿者条件５７２ｃと、 ４）広告の視聴所要時間の範囲が設定される視聴所要時間条件５７２ｄと、 ５）視聴対象広告の視聴回数についての条件、例えば、今回を含めた視聴回数又は過去の視聴回数の範囲が設定される同一広告視聴回数条件５７２ｅと、 を含むアンド条件として定義されている。そして、広告ＩＤ条件５７２ａ～同一広告視聴回数条件５７２ｅの何れについても「設定無し」が選択肢として含まれる。 なお、広告情報条件５７２には、これら以外の項目の条件も適宜含めることができる。 【０１３９】 広告情報条件５７２を適当に設定することによって、アイテム変換の内容、すなわちアイテムの強化・進化といった向上制御の程度を、どの広告を視聴するかに応じて変更することができる。具体的な例としては、特定の広告や、特定の広告カテゴリー、特定の出稿者の広告、が視聴された場合に、特別な出力要素とする、といった変換内容の差別化が可能になる。また、視聴所要時間が長い広告を視聴するほど、より高価値な出力要素とする、といった差別化が可能になる。また、同一広告を何度も見ると、より高価値な出力要素（或いは低価値な出力要素）とする、といった差別化も可能になる。」 エ 甲４（特開２０１８－１３２８２５号公報）に記載された事項 甲４には、以下の記載がある。 「【技術分野】 【０００１】 本開示は、通信機器管理装置、通信機器管理方法及び通信機器管理システムに関する。」 「【００１９】 〔通信機器管理システム〕 図１に示すように、通信機器管理システム１は、インターネット等の通信ネットワーク９０を介して互いに接続された複数の通信機器１０、利用者端末２０、金融機関サーバ３０、及び通信機器管理装置４０を備える。」 「【００３５】 暫定金額は、印刷回数に応じて（例えば比例して）定まる金額である。割引金額は、利用者情報に基づいて通信機器１０に広告情報が送信された回数に応じて定まる金額である。例えば割引金額は、上記広告受信回数に応じて（例えば比例して）定まる。第一請求金額は、割引金額を暫定金額から差し引いた金額である。第二請求金額は、利用者情報に基づいて通信機器１０に広告情報が送信された回数に応じて定まる金額である。例えば第二請求金額は、上記広告送信回数に応じて（例えば比例して）定まる。」 オ 甲５（国際公開２０１７／０８６０６１号）に記載された事項 甲５には、以下の記載がある。 「 技術分野 [0001] 本発明は、回答情報収集方法、回答情報収集システム、回答情報収集装置及びプログラム、並びに、クーポンの付与方法、クーポン付与システム、クーポン付与装置及びプログラムに関する。」 「[0150] ＜第７実施形態＞ まず、図１３を参照して、本発明の第７実施形態に係るクーポン付与システム１１の全体構成を説明する。図１３は、第７実施形態に係るクーポン付与システム１１の構成の一例を示す図である。クーポン付与システム１１においては、クーポン付与装置１２とユーザ端末１３がネットワーク１４を介して通信可能に接続されている。なお、図１３ではユーザ端末１３を３つ図示しているが、ユーザ端末の数は３つに限られない。 [0151] 本発明は、クーポン付与システム１１に含まれるクーポン付与装置１２及びユーザ端末１３などのコンピュータによって実行される各種の処理（ステップ）を含むクーポン付与方法の発明として捉えることも可能である。また、少なくとも本発明の目的を達成することが可能であれば、本実施形態で説明する各種の処理（ステップ）の一部が省略されてもよい。さらに、回答情報収集システム１及びクーポン付与システム１１が同一のシステムで構成されていてもよく、即ち、一つのシステムが回答情報収集システム１及びクーポン付与システム１１の両方の機能を備える構成も考えられる。 [0152] クーポン付与装置１２は、プログラムの演算処理を実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの演算装置、コンピュータプログラム又はデータなどを記憶するＲＡＭ、ＲＯＭ及びハードディスクドライブなどの記憶装置、インターネット又はＬＡＮなどのネットワーク１４を介してデータを送受信する通信装置などを備えるコンピュータである。クーポン付与装置１２では、前記演算装置によって各種の処理が実行されることにより当該クーポン付与装置１２の動作が制御される。 [0153] ユーザ端末１３は、ユーザが所有する通信端末であり、例えば、スマートフォン、携帯電話、タブレット型コンピュータ、パーソナルコンピュータなどである。 [0154] 次に、引き続き図１３を参照して、本実施形態に係るクーポン付与装置１２の機能構成について説明する。図１３に示すように、クーポン付与装置１２は、権限付与部１２１、条件判定部１２２及び追加権限付与部１２３を備える。具体的に、クーポン付与装置１２は、前記記憶装置に記憶されているプログラムに従って各種の処理を実行することにより、権限付与部１２１、条件判定部１２２及び追加権限付与部１２３として機能する。また、権限付与部１２１、条件判定部１２２及び追加権限付与部１２３の一部又は全部が回路モジュールで構成されていてもよい。なお、クーポン付与装置１２は、１台のコンピュータに限らず、複数台のコンピュータが協働して動作するコンピュータシステムであってもよい。また、クーポン付与装置１２が複数の演算装置を備えており、当該回答情報収集装置２で実行される各種の処理は、複数の演算装置によって分散して実行されてもよい。 [0154] 次に、引き続き図１３を参照して、本実施形態に係るクーポン付与装置１２の機能構成について説明する。図１３に示すように、クーポン付与装置１２は、権限付与部１２１、条件判定部１２２及び追加権限付与部１２３を備える。具体的に、クーポン付与装置１２は、前記記憶装置に記憶されているプログラムに従って各種の処理を実行することにより、権限付与部１２１、条件判定部１２２及び追加権限付与部１２３として機能する。また、権限付与部１２１、条件判定部１２２及び追加権限付与部１２３の一部又は全部が回路モジュールで構成されていてもよい。なお、クーポン付与装置１２は、１台のコンピュータに限らず、複数台のコンピュータが協働して動作するコンピュータシステムであってもよい。また、クーポン付与装置１２が複数の演算装置を備えており、当該回答情報収集装置２で実行される各種の処理は、複数の演算装置によって分散して実行されてもよい。 [0155] 権限付与部１２１は、ユーザに対してクーポンの取得権限を付与する。より詳細には、権限付与部１２１は、ユーザ端末１３に対してクーポンの取得権限を付与するために必要な情報を送信することにより、ユーザに対してクーポンの取得権限を付与する。 [0156] 「クーポンの取得権限の付与」とは、クーポンを取得することができる権限をユーザに付与することであり、クーポンそのものをユーザに付与することではない。クーポンを実際に取得するか否かは、取得権限を付与されたユーザが任意で決定することができる。 ・・・ 中 略 ・・・ [0158] 条件判定部１２２は所定条件に該当するか否かの判定を行う。また、条件判定部１２２は、１又は２以上の目標時間を記憶することができ、当該目標時間に応じた判定を行うことができる。 [0159] より短期間に客を集めるため、上記所定条件は、第一の目標時間以内に次の（Ａ）～（Ｄ）のいずれか一つに該当するときであることが考えられる。 [0160] （Ａ）ユーザからクーポンを取得した旨の情報又は取得権限を放棄した旨の情報を受信しなかった場合。 （Ｂ）ユーザからクーポンを取得した旨の情報を受信した場合。 （Ｃ）ユーザから取得権限を放棄した旨の情報を受信した場合。 （Ｄ）ユーザに対して取得権限を付与できなかった場合。 ・・・ 中 略 ・・・ [0177] また、クーポン付与装置１２は、特典付与部１２６を備えることができる。特典付与部１２６は、クーポンを取得したユーザに対して特典を付与する。特典の内容は特に限定されないが、例えば、ノベルティの提供、商品の無料提供、商品の割引提供、無料クーポンの付与、割引クーポンの付与、ポイントの付与、サービス内容のグレードアップ、サービス時間の延長などが挙げられる。 ・・・ 中 略 ・・・ [0209] また、特典は、第二の目標時間以内にクーポンを取得したユーザに対して一律に付与してもよいが、クーポン取得権限を付与された時点からクーポンを取得するまでの時間に応じて、ユーザに付与する特典の内容を変更してもよい。短期的な集客効果を上げる観点からは、クーポンを取得するまでの時間が短いほど、より大きな特典を付与することが考えられる。大きな特典を目当てとしたユーザが、より迅速にクーポンを取得するようになるからである。」 上記記載から甲５には第７実施形態として、以下の発明（以下、「引用発明５」という。）が記載されている。 「プログラムに従って各種の処理を実行するクーポン付与装置１２のプログラムにおいて、（[0154]） ユーザ端末１３がネットワーク１４を介して通信可能に接続され、（[0150]） ユーザ端末１３に対してクーポンの取得権限を付与するために必要な情報を送信し、（[0154][0155]） ユーザからクーポン取得した旨の情報を受信したかを判定し、（[0154][0158]～［0160］） クーポンを取得したユーザに対して、ノベルティの提供、商品の無料提供、商品の割引提供、無料クーポンの付与、割引クーポンの付与、ポイントの付与、サービス内容のグレードアップ、サービス時間の延長などの特典を付与し、（[0177]） 上記特典は、クーポン取得権限を付与された時点からクーポンを取得するまでの時間が短いほど、より大きな特典を付与することを特徴とする、（[0209]） プログラム。」 カ 甲６（特開２００９－１６３６４９号公報）に記載された事項 甲６には、以下の記載がある。 「【技術分野】 【０００１】 本発明は、クーポン発行システムにおける発行管理サーバに関するものである。」 「【０００８】 以下、図面を参照しながら本発明を実施するための最良の形態について説明する。図１は本発明を実施するための最良の形態に係る特典情報、即ちクーポンの発行システムの全体を示す構成図である。本図において、クーポン発行システム１は、ネットワーク４にクーポン管理サーバ５、販売管理サーバ２及びクライアントとしての複数の利用者の携帯電話３が接続されて構成される。」 「【００２９】 図１１は売上管理テーブル１８の内容を示す説明図である。利用者のインセンティブを生じさせるところの商品の割引率４２を導出する際に使用される。当該売上管理テーブル１８は店舗別商品別月日時別に売上管理が可能となっている。売上管理テーブル１８は商品コード５１をキーとして商品管理ＤＢ１１の情報から作成することができる。同図において、店舗コード５８は、当該の利用者が商品を購入する店舗を表すコードである。商品コード５１は、本クーポン４１の対象となっている対象商品名２４を表すコードである。当該商品の売上高８１は、月次、日次又は時間帯８２で集計されている。 【００３０】 例えば、日時集計されている売上高８１を分析した結果、休日の売上が平日の売上に比較し多い場合、当該商品の休日の割引率４２を２０％とし、平日の割引率４２を３０％とし、利用者に対して平日の本クーポン４１の使用を促す。図４に示す本クーポン４１の例では、１２月２日（日）に本クーポン４１の発行がなされる。過去の日次売上高データを分析し、休日の売上が平日の売上に比較し多いので、１２月３日（月）から１２月７日（金）の割引率４２を３０％、１２月２日（日）と１２月８日（土）の割引率４２を２０％に設定する。売上高８１が時間帯で集計されている場合も同様に繁忙時間帯と閑散時間帯により割引率４２を動的に変化させることができる。 【００３１】 また、当該商品又は役務の過去の売行き状況又は将来の売行き予想により、割引率を変化させてもよく、更に、当該前記利用者が特典を利用する時が前記商品又は役務に関する繁忙期又は閑散期により前記割引率を変化させてもよい。 【００３２】 更にまた、本クーポンの内容に、前記利用者が特典を利用する予定の商品又は役務の注文量が含めることができる場合は、当該注文量により、前記割引率を変化させてもよい。 【００３３】 さらに、仮クーポン２１発行から本クーポン４１への切り替えまでの時間経過の長さにより割引率４２を動的に変化させることもできる。例えば、仮クーポン２１から本クーポン４１までの切り替え時間が一定時間、例えば３日間を超えた場合は、前記の例の割引率４２が３０％であったものを２５％と変化させることができる。なお、仮クーポン２１発行から本クーポン４１への切り替えまでの時間経過の長さは、仮クーポン２１の発行年月日２８と本クーポン４１の発行年月日４５との差分による。 【００３４】 また、仮クーポン２１又は本クーポン４１の発行から前記利用者が当該本クーポン４１を利用するまでの時間経過の長さにより、前記割引率４２を動的に変化させることもできる。即ち、仮クーポン２１又は本クーポン４１の発行から７日以内に本クーポンを利用する場合は、割引率４２が３０％であるが、これを過ぎると割引率が１５％となることを図１５に示す割引率管理テーブル１９に格納しておく。 【００３５】 更に、利用者が本クーポン４１を利用する日の天候によって、前記割引率を変化させることもできる。即ち、仮に本クーポン４１の利用日の天候が晴れ又は曇りであれば割引率１０％であるところ、雨であれば割引率２５％となることを前記割引率管理テーブル１９に格納しておく。」 「【００４１】 続いて図１３により、仮クーポン２１取得のシーケンスを説明する。不特定の利用者の携帯電話３には、クーポン管理サーバ５が管轄する会社や営業店舗が扱う商品やサービス（役務）に関する電子広告３１（図３を参照）が配信される。なお、広告の配信は必ずしも販売管理サーバ２から配信されることを要しない。例えば、利用者が自らあるＷｅｂサイトをアクセスして興味のある商品の広告を取得して表示することもある。 【００４２】 利用者は、携帯電話３に表示された電子広告３１の仮クーポン請求マーク３２を操作することで、クーポン管理サーバ５にアクセスし、クーポン種別２２、利用者携帯電話番号６６及び利用者メールアドレス６７（携帯電話３のメールアドレス）を送信し、仮クーポン２１の取得要求をする（Ｓ２０１）。なお、この例では、携帯電話３に表示された電子広告３１からクーポンを請求しているが、利用者は、新聞広告や雑誌の広告からクーポンのメールアドレス（又はそのＱＲコードやバーコード）を取得して携帯電話３を操作し、クーポン管理サーバ５にアクセスすることもできる。 【００４３】 クーポン管理サーバ５は、仮クーポン２１の取得要求を受信すると、受信したクーポン種別２２をキーに、仮クーポン管理ＤＢ１４をサーチし、該当する仮クーポン２１の情報を取得し（Ｓ２０２）、利用者の携帯電話３にクーポン種別２２、コメント情報２３、対象商品名２４、割引情報２５、仮クーポンＩＤ２７、発行年月日２８及び本クーポンダウンロードＵＲＬ２９を返信する（Ｓ２０３）。なお、割引情報２５は、前記割引率管理テーブル１９に予め格納してある一定の条件に従った割引率４２を読み出す。 【００４４】 続いて、クーポン管理サーバ５は、当該仮クーポン２１の情報を発行済仮クーポンＤＢ１５に登録する（Ｓ２０４）。登録する情報には、クーポン種別２２、仮クーポンＩＤ２７、コメント情報２３、本クーポンダウンロードＵＲＬ２９、発行年月日２８、利用者メールアドレス６７、対象商品名２４及び有効期間２６がある。 【００４５】 仮クーポンＩＤ２７、コメント情報２３、本クーポンダウンロードＵＲＬ２９、対象商品名２４及び有効期間２６は、仮クーポン管理ＤＢ１４から転記される。発行年月日２８は、仮クーポン２１発行時の年月日を表し、クーポン管理サーバ５によって設定される。利用者メールアドレス６７は、利用者によって仮クーポン２１が要求されたときに当該の携帯電話３から受信した携帯電話３のメールアドレスである。 【００４６】 携帯電話３は、仮クーポン２１を受信すると当該情報を携帯電話３内の図示しない不揮発性メモリに格納する（Ｓ２０５）。 【００４７】 図１４において本クーポン４１の取得のシーケンスを説明する。本説明においては、すでにクーポン使用のサービスの利用登録がなされていることを前提とするが、仮クーポン２１取得時に利用登録がなされていない場合は、本クーポン４１の取得直前に利用者登録を行ってもよい。 【００４８】 さて前記ステップ２０５において、利用者は携帯電話３に仮クーポン２１を受信すると、それをメモリに記憶、保持する。買い物を実行しようとするときは、仮クーポン２１を携帯電話３の画面上に呼び出し、本クーポンダウンロードＵＲＬ２９を用いて仮クーポン２１を送信し、本クーポン４１の取得要求を行う（Ｓ３０１）。 【００４９】 クーポン管理サーバ５は、仮クーポン２１を受信すると有効期間２６が期限切れでないかを確認し（Ｓ３０２）、携帯電話３に入力画面を送信する（Ｓ３０３）。 【００５０】 携帯電話３は入力画面を受信すると、利用者は利用登録時に取得した利用者ＩＤ６１とサービス利用パスワード６２を入力し（Ｓ３０４）、これらをクーポン管理サーバ５に送信する（Ｓ３０５）。 【００５１】 クーポン管理サーバ５は、利用者ＩＤ６１とサービス利用パスワード６２を受信すると、先に受信した仮クーポン２１の利用者携帯電話番号６６又は利用者メールアドレス６７をキーとして利用者ＤＢ１３をサーチし当該の利用者ＩＤ６１及びサービス利用パスワード６２を読み出す。読み出したサービス利用パスワード６２と受信したサービス利用パスワード６２を比較し仮クーポン２１の正当性をチェックする（Ｓ３０６）。 【００５２】 仮クーポン２１の正当性が確認されると、クーポン管理サーバ５は、利用者ＤＢ１３に記憶する店舗コード５８と仮クーポン管理ＤＢ１４に記憶する商品コード５１を販売管理サーバ２に送信し店舗別商品別月日時別売上データを要求する（３０７)。 【００５３】 販売管理サーバ２は、前記店舗別商品別月日時別の売上データの要求を受けると当該店舗の商品管理ＤＢ１１を集計し、店舗別商品別月日時別の前記売上管理テーブル１８を作成し、クーポン管理サーバ５に返送する（Ｓ３０９）。 【００５４】 クーポン管理サーバ５は、売上管理テーブル１８を受信すると本クーポン４１を生成する（Ｓ３１０）。すなわち、本クーポンＩＤ４４を採番し、発行年月日４５として当日の年月日を設定する。クーポン種別２２、コメント情報２３、クーポンの対象商品名２４は、仮クーポン２１と同様の情報が引き継がれる。 【００５５】 割引率４２及び有効期間４３は、すでに図１１の説明で述べたとおり、本クーポン４１発行時に、仮クーポン２１発行から本クーポン４１発行までの経過日数、当該商品の時間帯別、日別、月別の売上数量５４等から一定の条件に従って決定され、前記割引率管理テーブル１９に予め格納してある。 【００５６】 生成された本クーポン４１の情報は、発行済本クーポンＤＢ１６に登録し、当該の携帯電話３に返送される（Ｓ３１１）。」 段落【００４２】【００４３】の記載から、クーポン管理サーバ５は、利用者の携帯電話３から「携帯電話３に表示された電子広告３１の仮クーポン請求マーク３２を操作することで」送信される、「クーポン種別２２、利用者携帯電話番号６６及び利用者メールアドレス６７（携帯電話３のメールアドレス）」からなる「仮クーポン２１の取得要求」を受信していることが理解できる。 段落【００４３】【００４６】の記載から、クーポン管理サーバ５から利用者の携帯電話３に返信される、「クーポン種別２２、コメント情報２３、対象商品名２４、割引率管理テーブル１９に予め格納してある一定の条件に従った割引率４２である割引情報２５、仮クーポンＩＤ２７、発行年月日２８及び本クーポンダウンロードＵＲＬ２９」からなる情報は、「仮クーポン２１」であることが理解できる。 段落【００５４】【００５５】の記載から、「本クーポン４１」の「割引率４２」は、「一定の条件に従って決定され、前記割引率管理テーブル１９に予め格納してある」割引率であることが理解できる。 上記記載から甲６には、以下の発明（以下、「引用発明６」という。）が記載されている。 「ネットワーク４にクーポン管理サーバ５、販売管理サーバ２及びクライアントとしての複数の利用者の携帯電話３が接続されクーポン発行システムにおいて、（【０００８】） クーポン管理サーバ５は、 利用者の携帯電話３からの、クーポン種別２２、利用者携帯電話番号６６及び利用者メールアドレス６７（携帯電話３のメールアドレス）からなる、仮クーポン２１の取得要求を受信し、（【００４２】【００４３】） 仮クーポン２１の取得要求を受信すると、受信したクーポン種別２２をキーに、仮クーポン管理ＤＢ１４をサーチし、該当する仮クーポン２１の情報を取得し（Ｓ２０２）、利用者の携帯電話３に、クーポン種別２２、コメント情報２３、対象商品名２４、割引率管理テーブル１９に予め格納してある一定の条件に従った割引率４２である割引情報２５、仮クーポンＩＤ２７、発行年月日２８及び本クーポンダウンロードＵＲＬ２９からなる仮クーポンを返信し、（【００４３】） 買い物を実行しようとするときに利用者の携帯電話３から送信された仮クーポン２１を受信すると、有効期間２６が期限切れでないかを確認し（Ｓ３０２）、携帯電話３に入力画面を送信し（Ｓ３０３）、（【００４８】【００４９】） 利用者ＩＤ６１とサービス利用パスワード６２を受信すると、先に受信した仮クーポン２１の利用者携帯電話番号６６又は利用者メールアドレス６７をキーとして利用者ＤＢ１３をサーチし当該の利用者ＩＤ６１及びサービス利用パスワード６２を読み出し、読み出したサービス利用パスワード６２と受信したサービス利用パスワード６２を比較し仮クーポン２１の正当性をチェックし（Ｓ３０６）、（【００５１】） 仮クーポン２１の正当性が確認されると、利用者ＤＢ１３に記憶する店舗コード５８と仮クーポン管理ＤＢ１４に記憶する商品コード５１を、販売管理サーバ２に送信し、店舗別商品別月日時別売上データを要求し（３０７)、（【００５２】） 販売管理サーバ２が作成した、売上管理テーブル１８を受信すると、一定の条件に従って決定され、前記割引率管理テーブル１９に予め格納してある割引率４２を適用した、本クーポン４１を生成し（Ｓ３１０）、（【００５３】【００５４】【００５５】） 当該の携帯電話３に返送される（Ｓ３１１）、（【００５６】） ものであって、 前記割引率管理テーブル１９に格納されている割引率は、仮に本クーポン４１の利用日の天候が晴れ又は曇りであれば割引率１０％であるところ、雨であれば割引率２５％となるものである、（【００３５】） クーポン管理サーバ５。」 キ 甲７（特開２０１５－８４２２０号公報）に記載された事項 甲７には、以下の記載がある。 「【技術分野】 【０００１】 本開示は、携帯端末のマーケティングに関し、より具体的には、販売店からの地域サービス券のターゲットを正確に絞り分配する方法およびシステムに関する。」 「【００２３】 リアルタイムターゲッティングモードでは、その顧客にサービス券を受信するための受け取り時間があるとき、バスの停留所および電車の駅、または駐車場などの交通拠点、または商業地域に居る潜在的顧客に、システムがサービス券を送信する。サービス券を受信するための受け取り時間とは、潜在的顧客がサービス券を受信する可能性のある時間のことである。サービス券に対して行動するための受け取り時間とは、潜在的顧客がサービス券に対して行動する機会がある時間である。例えば、乗客が電車に乗っていて、この電車が目的地に到着するまでにあと数分あるとき、この交通機関の利用者には、サービス券を受信するための受け取り時間があり得る。サービス券を受信するための受け取り時間は、例えば、乗客が電車を待っているとき、または乗客が交通機関を利用し、その乗客がサービス券を受信する好適な候補に変わる、パターンによって買い物をするときなどである。例えば、いつも午前１１時３０分に地域のレストランで食事をとる乗客が、午前６時３０分に構内に到着した場合、その乗客には午前６時３０分にサービス券を受信するための受け取り時間があり得る。」 「【００３１】 予測ターゲッティングモードを用いることにより、このシステムは、潜在的な顧客の、予測されるイベントまたは行動に関する情報を得ることができ、それらには、公共交通を利用すること、および／または、記念日をお祝いすること、またはディナーを食べることといったその他の行動が含まれる。このシステムでは、予測された、すなわち予定された顧客の将来のイベントの間で受け取り時間を予測して、潜在的顧客にサービス券を送信する。例えば、このシステムは、顧客が朝自宅を出る前に、その潜在的顧客の事務所の近辺のレストランの特別ディナーに関するサービス券を送信することができる。このシステムは、やることリスト、またはタスクリマインダリスト、あるいは、いくつかのアクセス可能な、またはシステムに組み込まれたカレンダアプリケーションから予測される行動に関するデータを取得可能である。このシステムは、潜在的顧客の一般的な移動パターンまたは通勤パターンを学習し、交通機関から潜在的顧客の予測される通勤ルートにおける遅れを示すリアルタイムデータを取得することができる。このような遅れも、この予測ターゲッティングモードでは、受け取り時間として利用することができる。このシステムはまた、やることリスト／タスクリマインダリストを分析し、事務所／自宅からやることリスト／タスクリマインダリストから項目を実行することができる場所への方向を送信することができる。販売店はまた、そのルートに沿った自分たちの店舗に基づいて、サービス券を送信することができる。 【００３２】 このシステムは、サービス券を受信するための受け取り時間として、決定を下す処理に関連する時間を特定し、その時に、有効期間／有効期限に先んじて、サービス券を送信することができる。例えば、このシステムは、潜在的顧客がディナーをとると決めた時間として、朝の早い時間、または夜の時間を特定することができる。この時間の中で、この潜在的顧客は、家族とのディナーの予定を調整することができる。この決定時間が、その潜在的顧客のサービス券を受信するための受け取り時間である。潜在的顧客がディナーを決定すると、このシステムは、午後５時から午後６時の時間帯にその潜在的顧客に対して有効なレストランのサービス券（例えば、ディスカウントされたテイクアウト食事）を送信することができる。次いで、この潜在的顧客は、午後５時から午後６時の有効期間中にサービス券を商品に引き換えることができる。さらに、このシステムは、潜在的顧客に移動の予定を変更するよう促すようなサービス券を潜在的顧客に送信することもできる。」 「【００４１】 図１には、一実施形態に従った、地域サービス券のターゲットを絞る分配システム１００の例示的なアーキテクチャのブロック図が示されている。システム１００は、推薦実体１０１を含むことができ、この推薦実体１０１が、バックエンドサーバ１０２を用いて、地域サービス券のターゲットを絞るサービス、分配するサービス、仲介するサービス、および分析するサービスを提供する。推薦実体１０１とは、地域サービス券のターゲットを絞る分配サービスを販売店に提供することに同意した企業である。バックエンドサーバ１０２は、携帯端末装置および販売店のコンピュータにサービスを供給し、他のサーバとネットワーク１０３を通して通信可能に接続する。バックエンドサーバ１０２は、販売店から受信したサービス券を管理し、そのサービス券を潜在的顧客に送信する。バックエンドサーバ１０２は、ターゲットを絞り分配する機能のうちのほとんどを供給し、交通機関のサーバ１０４、および電子料金収受サーバ１０６（同様に、駐車場および商用車両運行管理者などのその他のデータ供給源）からのデータを取得して、ターゲットを絞り分配する機能を容易にする。尚、バックエンドサーバ１０２は、いくつものマシンを有するサーバの集まりでよい。 【００４２】 販売店１０７は、販売店のコンピュータ１１８を操作し、バックエンドサーバ１０２と通信して、サービス券を潜在的顧客に送信する。尚、販売店は、サービス券の仲介者を用いて、サービス券をバックエンドサーバ１０２、および／または、潜在的顧客に送信することができる。潜在的顧客は、通常、携帯端末装置１１０、１１２をそれぞれ所有する交通機関の利用者１０９、１１１などの交通機関の利用者である。これらの携帯端末装置１１０、１１２が、バックエンドサーバ１０２からサービス券を受信する。電子料金収受サーバ１０６は、位置データを提供し、この位置データをバックエンドサーバ１０２がＧＰＳと組み合わせて用いて、自動車のドライバーおよび同乗者などの潜在的顧客の位置を見つける。 【００４３】 バックエンドサーバ１０２は、サービス券管理サーバのソフトウェア１１６を格納する記憶装置１１４を含むことができる。いくつかの実装形態では、サービス券管理サーバのソフトウェア１１６は、推薦エンジンを含むことができ、この推薦エンジンが地域的にターゲットを絞る機能のうちのほとんどを実行する。この推薦エンジンは、近くにいて、サービス券を商品に引き換え、サービス券の特定の有効期間内に取引を完了することが物理的に可能な潜在的顧客とサービス券とをリアルタイムで組合せることができる。 【００４４】 交通機関のサーバ１０４は、公共交通機関に関連する任意のサーバでよい。この交通機関のサーバ１０４は、地域サービス券を受信することを選択した人たちなどの潜在的顧客である交通機関の利用者に関するデータを供給することができる。バックエンドサーバ１０２は、利用者の公共交通システムの利用状況を示すデータを交通機関のサーバ１０４から受信することができる。このデータには、運賃回収システムからの、運賃を支払うためのクレジットカードの利用状況などのデータが含まれる。いくつかの実装形態では、バックエンドサーバ１０２は、事前に支払ったユーザの口座を管理する、発行銀行に関するサーバから、小売店に関連するターゲットデータ（例えば、クレジットカード／デビットカードの利用状況）を取得することができる。 【００４５】 販売店のコンピュータ１１８は、記憶装置１２０を含むことができ、この記憶装置１２０には、サービス券管理アプリケーション１２２が格納される。サービス券管理アプリケーション１２２により、販売店の商品、および／または、サービスを地域内の潜在的顧客に売り込むために、販売店は、それらをバックエンドサーバ１０２に登録することができる。尚、販売店１０７は、レストラン、サロン、コンビニエンスストア、カフェ、またはその他の全ての品物およびサービスを消費者に販売する店を含む、あらゆる種類の店を運営することができる。ランチタイム時のレストランの席または、特定の時間が経過すると、破棄しなければならない加工食品などのリアルタイムの余剰な収容能力、および生ものの在庫に基づいて、販売店は即行でマーケティングの決定を下すことができる。種々の実装形態では、販売店のコンピュータ１１８は、繰り返し販売される、または即興のサービス券をウェブサイト、または携帯端末のアプリケーションを介してバックエンドサーバ１０２に送信することができる。 【００４６】 潜在的顧客は、例えば、公共交通機関の利用者１０９、１１１でよい。いくつかの実装形態では、交通機関の利用者は地域サービス券を申込み、クレジットカードを交通機関およびバックエンドサーバ１０２の両方に登録することができる。クレジットカードは、彼らの運賃を引き落とす（例えば、バスに乗ったとき、または地下鉄の回転式改札口を通過したときに）非接触式チップをその中に含むことができる。これにより、交通機関の利用者がどのように交通システムを利用したか（例えば、交通機関の利用者がいつバスに乗ったか、いつバスから降りたか、いつ地下鉄に乗ったか、またはいつ地下鉄から降りたかを含む）を示すデータが供給される。交通機関のサーバ１０４は、このデータをバックエンドサーバ１０２に送信し、これにより、バックエンドサーバ１０２がクーポンのターゲットを絞り、交通システムを利用する間の利用客の受け取り時間に交通機関の利用者に、そのクーポンを分配する。 【００４７】 交通機関の利用者は、携帯端末装置１１０、１１２などの携帯端末装置を所有し得る。携帯端末装置１１０、１１２はそれぞれ、携帯電話、タブレット、またはその他の全ての種類の携帯端末装置でよい。携帯端末装置１１０、１１２はそれぞれ、各記憶装置１２４、１２５を含むことができ、これらの記憶装置１２４、１２５が、各地域サービス券アプリケーション１２６、１２８、および各アプリケーションプログラムミングインターフェース１２７、１２９を格納する。アプリケーションプログラミングインターフェース１２７、１２９は、サービス券を受信し、その他の機能を実行する。携帯端末装置１１０、１１２は、ＧＰＳ機能も含み、これにより、ジオフェンシングが容易になる。交通機関の利用者１０９、１１１は、携帯端末装置１１０、１１２を用いて、自分たちをバックエンドサーバ１０２に登録することにより、地域サービス券を受信することが可能となる。公共交通機関の利用者は決まったルート内に居て、決まったルートに沿って移動する傾向があり、バックエンドサーバ１０２は、所与の時間に、彼らの位置を比較的正確に推定することができるため、地域サービス券を受信する良好な候補である。また、通勤者も毎日決まったルートに沿って移動する傾向がある。 【００４８】 地域サービス券アプリケーション１２６、１２８は、位置データを供給し、サービス券を受信し、引き換えられたサービス券を処理し、リアルタイムの交通情報を提供する。尚、実装形態によっては、クレジットカード／デビットカードを用いて、あるいはその他の全てのサービス券を引き換える方法を用いて、顧客はサービス券を商品に引き換えることもできる。リアルタイムの交通情報には、交通スケジュール、交通の運賃、および旅行者が自分たちの旅行の計画を立てるために必要なその他の情報が含まれる。実装形態によっては、交通機関のサーバ１０４など、そのようなデータを供給する全ての送信源から、リアルタイムの交通情報を受信することができる、あるいはバックエンドサーバ１０２、またはその他の全てのサーバを通して、そのような情報を受信することができる。地域サービス券アプリケーション１２６、１２８は、携帯端末装置のＧＰＳ情報にアクセスし、バックエンドサーバ１０２（または、交通機関サーバ１０４、あるいは無線キャリアサービス）にそのデータを送信して、ジオフェンシングを容易にすることができる。地域サービス券アプリケーション１２６、１２８は、販売店１１８などの販売店、およびその他の店からサービス券を受信し、サービス券に関する履歴情報を格納することができる。例えば、サービス券は、「バスの停留所の隣のカフェで全てのアイテムが２０％引きで購入できる券」でもよい。販売店は、バックエンドサーバ１０２を介して、このサービス券を、地域サービス券アプリケーション１２６、１２８に送信する。潜在的顧客は、携帯端末装置を見てバスまたは電車がいつ到着するのかを調べるときに、これらのサービス券を受信し閲覧することができる。潜在的顧客が、販売店の店舗を訪れ、クーポン／商品券、を使用しようと決めた場合、これらの顧客は、地域サービス券アプリケーションを用いて、クーポン／商品券を処理し商品と引き換える。 【００４９】 地域サービス券アプリケーション１２６、１２８は、リアルタイムの交通状況、およびバス、フェリー、電車、地下鉄、タクシー、およびその他の公共交通のスケジュール情報などの、スケジュール情報を提供することができる。例えば、携帯端末装置の所有者１０９、１１１は、バスが２分遅れることを判定し、地域サービス券アプリケーション１２６、１２８をそれぞれ用いて、そのバスを地図上で見て追跡することが可能である。地域サービス券アプリケーション１２６、１２８は、交通機関のサーバ１０４から、リアルタイムの公共交通データを取得することができる。リアルタイムの公共交通のスケジュール、および状況データサービスにアクセスすることは、交通機関の利用者が地域サービス券アプリケーションをインストールする動機となる。さらに、交通機関の利用者はおそらく、彼らの乗るバス、または電車の状況を何度もチェックしようとし、これにより、これらの乗客がサービス券を見る機会をより多く作り出す。」 「【００７４】 図５には、一実施形態に従った、予測ターゲッティングモードでサービス券を送信する例示的な処理のフローチャートが示されている。バックエンドサーバ１０２は、図５のステップを実行して、潜在的顧客が近い将来の（例えば、その日を通して）顧客の予測位置に適用したサービス券を受信するかどうか判定することができる。交通機関のサーバのデータベースでデータマイニングすることにより、または潜在的顧客の予定（例えば、電子カレンダ、やることリスト、タスクリマインダリスト）にアクセスすることにより、あるいは、東南ペンシルベニア交通局（ＳＥＰＴＡ）の電子運賃支払いカードなどの潜在的顧客が使用している非接触式のカードからデータにアクセスすることにより、バックエンドサーバ１０２は、潜在的顧客の日々の通勤、および／または、その他の位置を変更する行動に関するデータを取得することができる。潜在的顧客が、そのようなサービス券を受信することを選択し、自分の予定にアクセスすることを許可することもできる。バックエンドサーバ１０２は、予定内の情報を用いて、関連するサービス券を送信することができる。この情報のいくつかの例には、記念日のお祝い、ドライクリーニング、ディナーの引き取り、およびバースデイカードの購入に関する項目を含むリマインダリストが含まれる。バックエンドサーバ１０２は、これらの予定の項目に関連するサービス券を送信することができる。 【００７５】 予測ターゲッティングモードでは、バックエンドサーバ１０２は、潜在的顧客の通常の通勤ルートを学習して、受け取り時間を特定することができる（例えば、機械学習、またはその他の全ての学習技術）。バックエンドサーバ１０２が、潜在的顧客の通常の通勤ルートにおいて遅れを検知した場合（例えば、電車の遅れ）、バックエンドサーバ１０２は、サービス券を受信するための受け取り時間、およびサービス券に対して行動するための受け取り時間として、この遅れを認識することができる。バックエンドサーバ１０２は、交通データから、多くの受け取り時間を導き出すことができる。次いで、バックエンドサーバ１０２は、潜在的顧客に通勤電車が遅れていることを知らせ（例えば、３０分の遅れ）、電車の駅の周辺の販売店からのサービス券を含むメッセージを潜在的顧客に送信することができる。但し、予期せぬ遅れと、予想される遅れとがあり得る。予期せぬ遅れとは、例えば、事故または天候不良による遅れである。予想される遅れとは、通常よりも大多数の交通機関の利用者を引き付けるスポーツイベントによる遅れである。これらの遅れは、（予測される遅れでも、予期せぬ遅れでも）サービス券を受信するための受け取り時間、および／または、サービス券に対して行動する受け取り時間になり得る。 【００７６】 一例では、通勤者が、通常、午後５時２０分に事務所を出て、午後５時３０分に地下鉄の駅に入る平日の時間に関して、バックエンドサーバ１０２は学習することができる。その通勤者は、電車の駅まで地下鉄を利用し、午後６時７分の電車に乗り、その顧客が車を駐車している駅に、この電車が午後６時４０分に到着する。バックエンドサーバ１０２が、その顧客のルートに沿った遅れを示すデータを受信した場合、地下鉄に乗っているその顧客にメッセージを送信することができる。例えば、バックエンドサーバ１０２は、午後６時７分の電車が３０分遅れているということを示すメッセージを電車の駅構内の販売店からのサービス券と共に送信することができる。 【００７７】 あるいは、バックエンドサーバ１０２が、通勤電車が遅れることを示すデータを十分に前もって受信した場合、バックエンドサーバ１０２は、顧客がまだ事務所に居る間に、その顧客の事務所の付近のレストランの特別ディナーに関するサービス券をその顧客に送信することができる。別のオプションとして、顧客が朝自宅を出る前に、バックエンドサーバ１０２は、その顧客の事務所付近のレストランの特別ディナーに関するサービス券をその顧客に送信することができ、顧客はこの時点で夜の予定を変更し、数人の友達をディナーに呼ぶかどうか決めることができる。いくつかの実装形態では、ユーザが地域サービス券を受信するために、携帯端末のアプリケーションを使って自発的に自分たちの通勤パターンに関するデータを提供することができる。 【００７８】 バックエンドサーバ１０２はまず、予定されている、あるいは予測される潜在的顧客の今後の行事、および／または、その行事の場所に関するデータを取得する。このデータには、やることリスト、タスクリマインダリスト、または予測される行事、および／または、その行事の場所が含まれ得る（動作５０２）。バックエンドサーバ１０２は、行事のリストにアクセスするために、交通機関のデータベースでデータマイニングを行うことができる、あるいは、顧客からのアクセスを受信することができる。例えば、バックエンドサーバ１０２は、潜在的顧客のデイリーカレンダにアクセスすることができ、その中には、潜在的顧客がその日一日に予定していることが示されている。 【００７９】 次に、バックエンドサーバ１０２は、今後予定されている、あるいは予測される顧客の行事の中で、潜在的顧客に、サービス券を受信するための受け取り時間、およびサービス券に対して行動するための受け取り時間があるかどうか判定する（動作５０４）。いくつかのシナリオでは、日中に自由に使える空き時間がありそうならば、潜在的顧客には、サービス券を受信するための受け取り時間、および／または、サービス券に対して行動する受け取り時間がある。例えば、通常潜在的顧客が使う通勤ルートに遅れが生じたことをバックエンドサーバ１０２が判定した場合、顧客には、サービス券を受信するための受け取り時間、および／または、サービス券に対して行動するため受け取り時間がある。その場合、受け取り時間（例えば、サービス券を受信するための、および／または、サービス券に対して行動するための）の時間帯は、予測された遅れ時間であり得る。サービス券を受信するための、および／または、サービス券に対して行動するための、受け取り時間は、異なる事象により、あるいは異なる理由で発生する可能性がある。例えば、サービス券を受信するための、および／または、サービス券に対して行動するための、受け取り時間は、特別な事象、または、通常の短い待ち時間、あるいは、非常に短い待ち時間の影響により発生する可能性がある。都合のいい時間の別のバス／電車が利用可能で、かつサービス券に魅力があれば、受け取り時間が発生する可能性がある。いくつかの実装形態では、バックエンドサーバ１０２は、ランチタイムまたはディナータイムなどの特定の時間に顧客に受け取り時間があることを想定することもできる。バックエンドサーバ１０２は、受け取り時間の時間帯を推定することができる。潜在的顧客に受け取り時間がないことを、バックエンドサーバ１０２が判定すると、バックエンドサーバ１０２は、ステップ５０６を実行することにより、サービス券を送信する動作をスキップする（動作５０６）。 【００８０】 バックエンドサーバ１０２は、随意的に、サービス券に対して行動するための各受け取り時間を分析して、それらの受け取り時間が全てのサービス券の有効期間内かどうか判定することができる（動作５０８）。バックエンドサーバ１０２は、サービス券の有効期間の前にサービス券を潜在的顧客に送信することができ、その後、サービス券の有効期間中に、潜在的顧客がこのサービス券を使うことができる。サービス券に対して行動するための受け取り時間が、全てのサービス券の有効期間内でないとき、バックエンドサーバ１０２は、サービス券を潜在的顧客に送信する動作をスキップすることができる（動作５０６）。サービス券に対して行動するための受け取り時間が、１つ以上の有効なサービス券の有効期間内の場合、バックエンドサーバ１０２は、サービス券に対して行動するための受け取り時間の時間帯以下の長さのサイクル時間が有効なサービス券には、あるかどうかを判定することができる（動作５１０）。サービス券に対して行動するための受け取り時間の時間帯以下の長さのサイクル時間のあるサービス券がない場合、バックエンドサーバ１０２は、サービス券を潜在的顧客に送信しない（動作５０６）。 【００８１】 サービス券に対して行動するための受け取り時間の時間帯以下の長さのサイクル時間のある、１つ以上のサービス券がある場合、バックエンドサーバ１０２は、潜在的顧客のために１つ以上のサービス券を選択する（動作５１２）。バックエンドサーバ１０２は、いくつかの基準に基づいて、サービス券を選択することができる。例えば、販売店の位置からの潜在的顧客の予測される将来の場所の地理的な距離に基づいて、バックエンドサーバ１０２はサービス券を選択することができる。バックエンドサーバ１０２は、予測される行動との関連性に基づいて、サービス券を選択することもできる。例えば、バックエンドサーバ１０２は、記念日がそのやることリストに載っている顧客に、割引された花に関するサービス券を送信することができる。バックエンドサーバ１０２は、潜在的顧客が所有する携帯端末装置上で実行されるアプリケーション（例えば、地域サービス券アプリケーション１２６、１２８）にサービス券を送信することができる、あるいは送信を予定することができる（動作５１４）。いくつかの実装形態では、バックエンドサーバ１０２は、潜在的顧客のカレンダにサービス券を添付することができる。」 「【図１】 ［図：0001397186000004.jpg］ 」 「【図５】 ［図：0001397186000005.jpg］ 」 「【図９】 ［図：0001397186000006.jpg］ 」 「【図１０】 ［図：0001397186000007.jpg］ 」 上記記載から、甲７には、以下の発明（以下、「引用発明７」という。）が記載されている。 「バックエンドサーバ１０２を用いて、地域サービス券のターゲットを絞るサービスおよび分配するサービス提供するものであって、（【００４１】） バックエンドサーバ１０２は、携帯端末装置にサービスを供給し、ネットワーク１０３を通して通信可能に接続し、サービス券を潜在的顧客に送信するものであって、（【００４１】） 潜在的顧客のデイリーカレンダにアクセスし、やることリスト、タスクリマインダリスト、または予測される行事、および／または、その行事の場所が含まれる、予定されている、あるいは予測される潜在的顧客の今後の行事、および／または、その行事の場所に関するデータを取得し、（【００７８】） 受け取り時間があるかどうかを判定するために、交通機関から潜在的顧客の予測される通勤ルートにおける遅れを示すリアルタイムデータを取得し、（【００３１】【００７９】） 通常潜在的顧客が使う通勤ルートに遅れが生じたこと判定した場合、顧客には、サービス券を受信するための受け取り時間、および／または、サービス券に対して行動するため受け取り時間があるとし、（【００７９】） サービス券に対して行動するための各受け取り時間を分析して、それらの受け取り時間が全てのサービス券の有効期間内かどうか判定し、（【００８０】） サービス券に対して行動するための受け取り時間が、１つ以上の有効なサービス券の有効期間内の場合、サービス券に対して行動するための受け取り時間の時間帯以下の長さのサイクル時間が有効なサービス券があるかどうかを判定し、（【００８０】） サービス券に対して行動するための受け取り時間の時間帯以下の長さのサイクル時間のある、１つ以上のサービス券がある場合、記念日がそのやることリストに載っている顧客に、割引された花に関するサービス券を選択する等の、予測される行動との関連性に基づいて、サービス券を選択し、（【００８１】） 潜在的顧客が所有する携帯端末装置上で実行されるアプリケーション（例えば、地域サービス券アプリケーション１２６、１２８）にサービス券を送信する、（【００８１】） バックエンドサーバ１０２。」 （４）特許異議申立書における主張の検討 ア 本件訂正発明１、２、４（特許異議申立人の上記（２）ア、イ、エの主張）について 上記第２で示したように、本件訂正請求による訂正は認められ、請求項１、２、４は、は削除された。このため、請求項１、２、４について、申立ての対象がなくなった。 イ 本件発明３（特許異議申立人の上記（２）ウの主張）について （ア）対比 ａ 本件発明３と引用発明２とを対比する。 （ａ）引用発明２の「ユーザの端末２００」は、本件発明３の「ユーザの端末装置」に相当する。 そして、引用発明２の「行動制御システム１００」は、「ユーザの端末装置２００や他の装置３００とインターネットを通じて通信可能である」から、本件発明３の「各ユーザの端末装置と通信可能なコンピュータ」に相当する。 （ｂ）引用発明２は、「平準化モデル」を生成するために、ステップＳ２０２で「近い将来（例えば数十分から数時間後）の交通状況を予測し」、具体的には、「本線：１００台（渋滞）、迂回路：１０台（非渋滞）」を予測し、引用発明２の「近い将来（例えば数十分から数時間後）の交通状況」は、予測された数値（台数）であり、これらの数値は、場所や値の大きさによって「渋滞」、「非渋滞」に区別されることから、混雑状況に関する数値であるといえる。 また、引用発明２のステップＳ２０２の「現在の交通状況を把握する」ことにおいて、この把握された「現在の交通状況」は、「各道路の許容車両台数（渋滞が発生しない上限の車両台数）は、本線が７０台、迂回路が３０台である」ことと比較されるのであるから、引用発明２の「現在の交通状況を把握」することは、混雑状況に関する数値を把握することであるといえる。 そうすると、引用発明２において、「ユーザから収集した個人状態値およびセンサデータと、他の装置３００から収集した交通状況関連情報に基づいて、現在の交通状況を把握するとともに、近い将来（例えば数十分から数時間後）の交通状況を予測（ステップＳ２０２）」することによって、予測した結果を得ていることは明らかであり、そのような結果を得る手段を有していることも明らかであるから、引用発明２の当該予測した結果を得るための手段は、本件発明３の「或る移動経路の現在又は将来の混雑状況値を取得する取得手段」に相当する。 （ｃ）引用発明２の「コンテンツ」は、「「迂回」「時間差移動」「電車」のいずれかを含むコンテンツ」であり、「端末装置２００の専用アプリ」が、「動制御システム１００からコンテンツを受信されると（ステップＳ１０４；Ｙｅｓ）、そのコンテンツをユーザに提示し（ステップＳ１０６）」、「ユーザが、コンテンツを受け入れレコメンドに従う場合には、「受入」ボタンを押し」、「移動終了後、行動制御システム１００から、ユーザが実際に採った移動経路や移動手段、あるいは移動時刻が、ユーザが受け入れたコンテンツの条件を満たしていたかどうかの結果情報が受信され」るものであり、さらに、引用発明２の「コンテンツ」は、車で移動しているユーザに「迂回」「時間差移動」「電車」の利用のずれかを提示するものであって、「迂回」の例として、「本日１５時頃、国道Ａ号のＢ交差点付近で渋滞の発生が予想されますので、迂回路（県道Ｃ号）の通行をお願いします。」との文章が含まれていることから、「コンテンツ」は、ユーザに対して行動変更を要求する、すなわち移動経路の利用を控える要請をするものであるといえる。そうすると、引用発明２の「コンテンツ」は、本件発明３の「前記或る移動経路の利用を控える要請」に相当する。 そして、引用発明２は、「ユーザから収集した個人状態値およびセンサデータと、他の装置３００から収集した交通状況関連情報に基づいて、現在の交通状況を把握するとともに、近い将来（例えば数十分から数時間後）の交通状況を予測（ステップＳ２０２）し」、「ステップＳ２０２の結果をもとに、地域内の道路ですでに渋滞が発生しているか、近い将来渋滞が発生しそうだと判断であれば、ステップＳ２０４に進み」、ステップＳ２０４で平準化モデル生成処理を実行し、平準化モデルが生成されると、コンテンツを提供するコンテンツ提供処理（ステップＳ２０５）に進んでおり、このコンテンツ提供処理（ステップＳ２０５）では、その提供コンテンツの提供先となるユーザを選択し、そのユーザの端末装置２００にコンテンツを送信し（ステップＳ４０５）ているから、引用発明２の「ステップＳ２０２の結果をもとに、地域内の道路ですでに渋滞が発生しているか、近い将来渋滞が発生しそうだと判断」することは、このときの予想した値を何らかの基準値と比較をすることで行うことは明らかである。そうすると、引用発明２の当該予想した値は、本件発明３の「前記現在又は将来の混雑状況値」に相当し、引用発明２の、すでに渋滞が発生、または、近い将来渋滞が発生しそうだと判断したことによって、「そのユーザの端末装置２００にコンテンツを送信」することは、本件発明３の「前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信」することに相当する。 そして、引用発明２において、行動制御システム１００が「そのユーザの端末装置２００にコンテンツを送信」する手段を有することは明らかであるから、引用発明２の当該手段は、本件発明３の「前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信」する「要請手段」に相当する。 （ｄ）引用発明２は、「インセンティブが付加されたコンテンツを含むコンテンツ」について、「行動制御システム１００」が「ユーザの端末装置２００にコンテンツを送信し（ステップＳ４０５）」、「ユーザがコンテンツを受け入れた場合」に、端末装置２００では、「移動が終了（目的地に到着または目的地を変更）するまでの間（ステップＳ１１２）、ＧＰＳや加速度などのセンサデータが定期的に取得され（ステップＳ１１０）、行動制御システム１００へ送信し（ステップＳ１１１）」、「行動制御システム１００」が「ステップＳ２０８で」、「コンテンツ効果判定部１４４が、コンテンツの提供を受けたユーザがコンテンツに従って実際に行動を変更したか否かを確認し、当該ユーザが受け入れたコンテンツの条件を満たしていたかを判定し、その判定結果をユーザの端末装置２００に送信」し、「端末装置２００の専用アプリ」は、「移動終了後、行動制御システム１００から、ユーザが実際に採った移動経路や移動手段、あるいは移動時刻が、ユーザが受け入れたコンテンツの条件を満たしていたかどうかの結果情報が受信され」、「ユーザがコンテンツの条件を満たす移動を実行していた場合には（ステップＳ１１４；Ｙｅｓ）、ユーザに対してインセンティブが授与される（ステップＳ１１５）」ものであるから、引用発明２の「行動制御システム１００」が、「コンテンツ効果判定部１４４が、コンテンツの提供を受けたユーザがコンテンツに従って実際に行動を変更したか否かを確認し、当該ユーザが受け入れたコンテンツの条件を満たしていたかを判定し、その判定結果をユーザの端末装置２００に送信」するものであることであって、条件を満たしていたことは、本件発明３の「前記要請を承諾した」ことに相当する。このとき、引用発明２の条件を満たしていたユーザは、本件発明３の「前記要請を承諾したユーザ」に相当する。 （ｅ１）引用発明２の「コンテンツ提供処理（ステップＳ２０５）」では、 「コンテンツ提供優先順位を０で初期化し（ステップＳ４００）、コンテンツ提供優先順位をインクリメントしながら（ステップＳ４０１）、コンテンツ効果管理ＤＢ１３５に登録されている、「提供優先順位」と、「インセンティブが付加されたコンテンツを含むコンテンツ」から、提供優先順位の高いものから順に注目（ステップＳ４０２）し、注目したコンテンツが現在の環境下で受け入れ可能なコンテンツか否かを判断し（ステップＳ４０３）、受け入れ可能性のあるコンテンツであれば、その注目したコンテンツを提供コンテンツとして選択し（ステップＳ４０４）」、 「提供コンテンツが選択されると、その提供コンテンツの提供先となるユーザを選択し、そのユーザの端末装置２００にコンテンツを送信し（ステップＳ４０５）」、 「コンテンツの受入予測人数（複数種類のコンテンツ提供を行った場合は、その合計人数）が、渋滞緩和させたい道路から減らすべき車の数に達したかを確認し（ステップＳ４０６）、必要な台数分、車が減らせると予想できたら（ステップＳ４０６；Ｙｅｓ）、ステップＳ４０７に進み、受入予測人数が必要な台数に達してなければ（ステップＳ４０６；Ｎｏ）、ステップＳ４０１に戻って別のコンテンツの提供を検討し」ており、 ステップＳ４０５で「ユーザの端末２００」に送信される「コンテンツ」は、「コンテンツ提供優先順位をインクリメントしながら（ステップＳ４０１）、コンテンツ効果管理ＤＢ１３５に登録されている、「提供優先順位」と、「インセンティブが付加されたコンテンツを含むコンテンツ」」に基づき変更されているといえる。ここで、引用発明２の「インセンティブ」は、例えば、店舗で利用できるクーポンを表示したり、ＥＴＣの割引コードを表示したり、ポイントやデジタルマネーであるから、本件発明３の「報酬」に相当する。そして、引用発明２において、「ユーザの端末２００」に送信される「コンテンツ」にはインセンティブが含まれており、「行動制御システム１００」が、「コンテンツ効果判定部１４４が、コンテンツの提供を受けたユーザがコンテンツに従って実際に行動を変更したか否かを確認し、当該ユーザが受け入れたコンテンツの条件を満たしていたかを判定し、その判定結果をユーザの端末装置２００に送信」する手段を有することは明らかであるから、引用発明２の当該手段は、本件発明３の「前記要請を承諾したユーザに対して、報酬を付与する要請手段」に相当する。 そして、上記（ｃ）と併せると、引用発明２の「そのユーザの端末装置２００にコンテンツを送信」する手段と、「コンテンツ効果判定部１４４が、コンテンツの提供を受けたユーザがコンテンツに従って実際に行動を変更したか否かを確認し、当該ユーザが受け入れたコンテンツの条件を満たしていたかを判定し、その判定結果をユーザの端末装置２００に送信」する手段とは、２つの手段で構成されている点で異なるものの、本件発明３の「前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信し、且つ、前記要請を承諾したユーザに対して、報酬を付与する要請手段」に相当する。 また、引用発明２の「コンテンツ提供優先順位をインクリメント」することは、これにより、コンテンツ効果管理ＤＢ１３５に登録された、ユーザに送信されるインセンティブが付加されたコンテンツが変更されることから、本件発明３の「報酬を変更する」ことに相当する。 （ｅ２）さらに、引用発明２において、「行動制御システム１００」は、「コンテンツ提供優先順位をインクリメント」することにより、「報酬を変更する」手段を有していることは明らかである。 ここで、引用発明２の「「コンテンツ提供優先順位をインクリメント」することにより、「報酬を変更する」」ことは、コンテンツ管理ＤＢ１３５に予めコンテンツに対応付けて登録されている上記インクリメントするための優先順位（の情報）に基づいて報酬を変更していることであるといえ、本件発明３の「予め定められた情報に基づき、前記報酬を変更する変更手段」といいうるものである。 もっとも、「予め定められた情報」について、本件発明３では「前記予め定められた情報は、前記要請を送信してから承諾するまでの経過時間を含む」のに対し、引用発明２では、コンテンツ管理ＤＢ１３５に予めコンテンツに対応付けて登録されている上記インクリメントするための優先順位（の情報）である点で相違する。 （ｆ）そして、引用発明２の「行動制御システム１００の、処理及び機能をソフトウェア的に実現させるプログラム」は、本件発明３の「プログラム」に対応する。 （ｇ）上記のとおりであるから、本件発明３と引用発明２との、一致点、相違点は以下のとおりである。 ［一致点］ 「各ユーザの端末装置と通信可能なコンピュータを、 或る移動経路の現在又は将来の混雑状況値を取得する取得手段、 前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信する手段、 前記要請を承諾したユーザに対して、報酬を付与する手段、 予め定められた情報に基づき、前記報酬を変更する変更手段、 として機能させる、 プログラム。」 ［相違点３－１］ 本件発明３は、「前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信し、且つ、前記要請を承諾したユーザに対して、報酬を付与する要請手段」として機能させているのに対して、引用発明２は、「そのユーザの端末装置２００にコンテンツを送信」する手段と、「コンテンツ効果判定部１４４が、コンテンツの提供を受けたユーザがコンテンツに従って実際に行動を変更したか否かを確認し、当該ユーザが受け入れたコンテンツの条件を満たしていたかを判定し、その判定結果をユーザの端末装置２００に送信」する手段からなり、この２つの手段が同一の「要請手段」であるか定かではない点。 ［相違点３－２］ 「予め定められた情報」について、本件発明３では「前記予め定められた情報は、前記要請を送信してから承諾するまでの経過時間を含む」のに対し、引用発明２では、コンテンツ管理ＤＢ１３５に予めコンテンツに対応付けて登録されている上記インクリメントするための優先順位（の情報）である点。 （イ）相違点についての当審判断 ａ 事案に鑑み、相違点３－２から判断する。 「各ユーザの端末装置と通信可能なコンピュータを」、「前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信し、且つ、前記要請を承諾したユーザに対して、報酬を付与する要請手段」として機能させるプログラムにおいて、「前記要請を送信してから承諾するまでの経過時間を含む」「予め定められた情報に基づき、前記報酬を変更する」ことは、甲１には記載されておらず、また本件特許の出願前に周知の技術であったともいえない。また、引用発明５は、上記（３）オのとおりであって、クーポン取得権限を付与された時点からクーポンを取得するまでの時間が短いほど、より大きな特典を付与するものである。そして、引用発明５は、ユーザに混雑回避経路を提供するものではなく、「前記要請を送信してから承諾するまでの経過時間を含む」「予め定められた情報に基づき、前記報酬を変更する」ものでもない。このため、引用発明２に技術分野の異なる引用発明５を適用しようとする動機はなく、適用しても、相違点３－２の構成には至らない。また、甲３、甲４、甲６、甲７にも相違点３－２の構成は記載されていない。 したがって、相違点３－１について検討するまでもなく、本件発明３は、引用発明２及び甲１、甲３～甲７に記載された技術的事項に基づいて当業者が容易に発明をすることができたものではない。 ｂ また、引用発明５を主引用例としても、上記ａのとおり、甲１～４、甲６、甲７には「要請を送信してから承諾するまでの経過時間を含む」「予め定められた情報に基づき、前記報酬を変更する」ことは記載されていないため、引用発明５に、甲１～４、甲６、甲７に記載された技術的事項を適用しても、上記相違点３－２の構成には至らないことから、当該相違点３－２の構成は、当業者が容易に想到することができたものではない。 さらに、甲１、甲３、甲４、甲６、甲７のいずれかを主引用例としても、甲２、甲５には、「要請を送信してから承諾するまでの経過時間を含む」「予め定められた情報に基づき、前記報酬を変更する」ことは記載されていないため、上記相違点３－２の構成には至らないことから当該相違点３－２の構成は、当業者が容易に想到することができたものではない。 ｃ そして、上記相違点３－２の構成とすることで、「本発明によれば、ユーザに混雑する経路の利用を控える動機付けを与え、当該経路の混雑を緩和させることができる。」（【００１６】）との効果を奏するものである。 （ウ）特許異議申立人の主張について ａ 特許異議申立人は、特許異議申立書で （主張３－１） 甲５には、要請を承諾したユーザに対して、報酬を付与する要請手段、予め定められた情報に基づき、報酬を変更する変更手段、予め定められた情報は、要請を送信してから承諾するまでの経過時間であることが記載されており、そして、甲５は、クーポンの付与に係るプログラムに関する技術であるため、当業者によれば、この技術を甲１と組み合わせて、本件発明３を容易に想到することができる（特許異議申立書第３４頁第２４行～第３５頁第１２行）旨主張する。 （主張３－２） 甲２には、「（３Ｅ）前記予め定められた情報は、前記要請を送信してから承諾するまでの経過時間を含む」ことが記載されている（特許異議申立書第１７頁下から第１行～第１８頁第５行）旨主張し、甲２は、渋滞緩和や渋滞防止を図るシステムに関する技術であるため、当業者によれば、この技術を甲１と組み合わせて、本件発明３を容易に想到することができる（特許異議申立書第３５頁第１４行～第１７行）旨主張する。 ｂ 主張の検討 （主張３－１）について 上記（イ）で検討したように、引用発明５は、ユーザに混雑回避経路を提供するものではなく、「予め定められた情報に基づき、前記報酬を変更する」ものでもない。そして、甲１にも「予め定められた情報に基づき、前記報酬を変更する」ことは記載されていない。このため、引用発明５に甲１に記載された技術的事項を適用しても、相違点３－２の構成には至らない。この点を看過している特許異議申立人の主張は適切ではない。 （主張３－２）について 引用発明２は、「ユーザの端末２００」に送信される「コンテンツ」は、「コンテンツ提供優先順位をインクリメントしながら（ステップＳ４０１）、コンテンツ効果管理ＤＢ１３５に登録されている、「提供優先順位」と、「インセンティブが付加されたコンテンツを含むコンテンツ」」に基づき変更しており、「前記要請を送信してから承諾するまでの経過時間」により変更されるものではない。 そうすると、特許異議申立人の上記主張は、甲２の誤った理解に基づく主張であり採用できない。 （エ）小括 上記のとおりであるから、本件発明３は、当業者が、引用発明２若しくは引用発明５並びに甲１に記載された事項に基づいて、容易に発明をすることができたものであるとはいえない。 ウ 本件訂正発明５（特許異議申立人の上記（２）オの主張）について （ア）対比 本件訂正発明５と引用発明２とを対比する。 本件発明３と本件訂正発明５とは、前者は「前記予め定められた情報は、前記要請を送信してから承諾するまでの経過時間を含む、」のに対し、後者は「前記予め定められた情報は、現在の天候情報を含み、前記変更手段は、前記天候情報が雨を示す場合、屋内施設で利用可能な報酬に変更し、前記天候情報が晴れを示す場合、野外施設で利用可能な報酬に変更する、」構成である点で相違し、他の構成で一致する。 そして、本件訂正発明５の当該一致する構成についての対比は、上記イ（ア）ａ（ａ）～（ｅ１）及び（ｇ）のとおりであるから、上述した相違する構成について対比を行うと、本件訂正発明５と引用発明２との、一致点、相違点は以下のとおりである。 ［一致点］ 「各ユーザの端末装置と通信可能なコンピュータを、 或る移動経路の現在又は将来の混雑状況値を取得する取得手段、 前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信する手段、 前記要請を承諾したユーザに対して、報酬を付与する手段、 予め定められた情報に基づき、前記報酬を変更する変更手段、 として機能させる、 プログラム。」 ［相違点５－１］ 本件訂正発明５は、「前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信し、且つ、前記要請を承諾したユーザに対して、報酬を付与する要請手段」として機能させているのに対して、引用発明２は、「そのユーザの端末装置２００にコンテンツを送信」する手段と、「コンテンツ効果判定部１４４が、コンテンツの提供を受けたユーザがコンテンツに従って実際に行動を変更したか否かを確認し、当該ユーザが受け入れたコンテンツの条件を満たしていたかを判定し、その判定結果をユーザの端末装置２００に送信」する手段からなり、この２つの手段が同一の「要請手段」であるか定かではない点。 ［相違点５－２］ 「予め定められた情報」について、本件訂正発明５では「前記予め定められた情報は、現在の天候情報を含み、／前記変更手段は、前記天候情報が雨を示す場合、屋内施設で利用可能な報酬に変更し、前記天候情報が晴れを示す場合、野外施設で利用可能な報酬に変更する」のに対し、引用発明２では、「コンテンツ管理ＤＢ１３５にあらかじめコンテンツに対応付けて登録されている上記インクリメントするための優先順位（の情報）」である点。 （イ）相違点についての当審判断 ａ 事案に鑑み、上記相違点５－２から判断する。 「各ユーザの端末装置と通信可能なコンピュータを」、「前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信し、且つ、前記要請を承諾したユーザに対して、報酬を付与する要請手段」として機能させるプログラムにおいて、「現在の天候情報を含む」「予め定められた情報に基づき、前記報酬を変更する」ことにおいて、「前記天候情報が雨を示す場合、屋内施設で利用可能な報酬に変更し、前記天候情報が晴れを示す場合、野外施設で利用可能な報酬に変更する」ことは、甲１には記載されておらず、また本件特許の出願前に周知の技術であったともいえない。また、引用発明６は、割引率が適用されたクーポンを生成・発行する「クーポン発行システム」であって、割引率は、仮に本クーポン４１の利用日の天候が晴れ又は曇りであれば割引率１０％であるところ、雨であれば割引率２５％となるものである。そして、引用発明６は、ユーザに混雑回避経路を提供するものではなく、「前記予め定められた情報は、現在の天候情報を含み、／前記変更手段は、前記天候情報が雨を示す場合、屋内施設で利用可能な報酬に変更し、前記天候情報が晴れを示す場合、野外施設で利用可能な報酬に変更する」ものでもない。このため、引用発明２に技術分野の異なる引用発明６を適用しようとする動機はなく、適用しても、相違点５－２の構成には至らない。また、甲１、甲３、甲４、甲５、甲７にも相違点５－２の構成は記載されていない。 したがって、相違点５－１について検討するまでもなく、本件訂正発明５は、引用発明２及び甲１、甲３～甲７に記載された技術的事項に基づいて当業者が容易に発明をすることができたものではない。 ｂ また、引用発明６を主引用例としても、上記ａのとおり、甲１～５、甲７には「前記予め定められた情報は、現在の天候情報を含み、／前記変更手段は、前記天候情報が雨を示す場合、屋内施設で利用可能な報酬に変更し、前記天候情報が晴れを示す場合、野外施設で利用可能な報酬に変更する」ことは記載されていないため、引用発明６に、甲１～５、甲７に記載された技術的事項を適用しても、上記相違点５－２の構成には至らない。 ｃ そして、上記相違点５－２の構成とすることで、「本発明によれば、ユーザに混雑する経路の利用を控える動機付けを与え、当該経路の混雑を緩和させることができる。」（【００１６】）との効果を奏するものである。 （ウ）特許異議申立人の主張について ａ 特許異議申立人は、特許異議申立書で、 （主張５－１） 甲６には、利用者が本クーポン４１を利用する日の天候によって、前記割引率を変化させることが記載されており、割引率を変化させる集客施設として、天候が雨の場合ユーザが集まり憎い野外施設があげられることは、間違いないことであり、本件訂正発明５のように変更手段を、天候情報が雨、晴れ、または、曇りによって報酬を変更することは、単なる設計事項である旨（特許異議申立書第３６頁下から第４行～第３７頁第１４行）主張する。 （主張５－２） 当業者によれば、引用発明６に甲１及び甲２に記載された事項を組み合わせて、本件訂正発明５を容易に想到することができる旨（特許異議申立書第３７頁第１６行～第１７行）主張する。 ｂ 主張の検討 （主張５－１）について 上記（イ）で検討したように、引用発明６は、ユーザに混雑回避経路を提供するものではなく、「前記予め定められた情報は、現在の天候情報を含み、／前記変更手段は、前記天候情報が雨を示す場合、屋内施設で利用可能な報酬に変更し、前記天候情報が晴れを示す場合、野外施設で利用可能な報酬に変更する」ものでもない。そして、甲１にも「予め定められた情報に基づき、前記報酬を変更する」ことは記載されていない。このため、引用発明６に甲１に記載された技術的事項を適用しても、相違点５－２の構成には至らない。この点を看過している特許異議申立人の主張は適切ではない。 （主張５－２）について 引用発明２は、「ユーザの端末２００」に送信される「コンテンツ」は、「コンテンツ提供優先順位をインクリメントしながら（ステップＳ４０１）、コンテンツ効果管理ＤＢ１３５に登録されている、「提供優先順位」と、「インセンティブが付加されたコンテンツを含むコンテンツ」」に基づき変更しており、「現在の天候情報」により変更されるものではない。 そうすると、特許異議申立人の上記主張は、甲２の誤った理解に基づく主張であり採用できない。 （エ）上記のとおりであるから、本件訂正発明５は、当業者が、引用発明２若しくは引用発明６並びに甲１に記載された事項に基づいて、容易に発明をすることができたものであるとはいえない。 エ 本件発明６（特許異議申立人の上記（２）カの主張）について （ア）対比 本件発明６と引用発明２とを対比する。 本件発明３と本件発明６とは、前者は「前記予め定められた情報は、前記要請を送信してから承諾するまでの経過時間を含む、」のに対し、後者は「前前記予め定められた情報は、前記要請を承諾したユーザのスケジュールを含む、」ものであって、コンピュータを「各ユーザのスケジュールを記憶する記憶手段」として機能させる構成である点で相違し、他の構成で一致する。 そして、本件発明６の当該一致する構成についての対比は、上記イ（ア）ａ（ａ）～（ｅ１）及び（ｇ）のとおりであるから、上述した相違する構成について対比を行うと、本件発明６と引用発明２との、一致点、相違点は以下のとおりである。 ［一致点］ 「各ユーザの端末装置と通信可能なコンピュータを、 或る移動経路の現在又は将来の混雑状況値を取得する取得手段、 前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信する手段、 前記要請を承諾したユーザに対して、報酬を付与する手段、 予め定められた情報に基づき、前記報酬を変更する変更手段、 として機能させる、 プログラム。」 ［相違点６－１］ 本件発明６は、コンピュータを「各ユーザのスケジュールを記憶する記憶手段」として機能させる構成であるのに対して、引用発明２は、対応する特定がされていない点。 ［相違点６－２］ 本件発明６は、「前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信し、且つ、前記要請を承諾したユーザに対して、報酬を付与する要請手段」として機能させているのに対して、引用発明２は、「そのユーザの端末装置２００にコンテンツを送信」する手段と、「コンテンツ効果判定部１４４が、コンテンツの提供を受けたユーザがコンテンツに従って実際に行動を変更したか否かを確認し、当該ユーザが受け入れたコンテンツの条件を満たしていたかを判定し、その判定結果をユーザの端末装置２００に送信」する手段からなり、この２つの手段が同一の「要請手段」であるか定かではない点。 ［相違点６－３］ 「予め定められた情報」について、本件発明６では「前記予め定められた情報は、前記要請を承諾したユーザのスケジュールを含む」のに対し、引用発明２では、「コンテンツ管理ＤＢ１３５にあらかじめコンテンツに対応付けて登録されている上記インクリメントするための優先順位（の情報）」である点。 （イ）相違点についての当審判断 ａ 事案に鑑み、上記相違点６－３から判断する。 「各ユーザの端末装置と通信可能なコンピュータを」、「前記現在又は将来の混雑状況値に基づき、前記或る移動経路の利用を控える要請を一又は複数のユーザの端末装置に送信し、且つ、前記要請を承諾したユーザに対して、報酬を付与する要請手段」として機能させるプログラムにおいて、「前記要請を承諾したユーザのスケジュールを含む」「予め定められた情報に基づき、前記報酬を変更する」ことは、甲１には記載されておらず、また本件特許の出願前に周知の技術であったともいえない。また、引用発明７は、「地域サービス券のターゲットを絞るサービスおよび分配するサービス提供するもの」であって、潜在的顧客のデイリーカレンダのデータ及び潜在的顧客の予測される通勤ルートにおける遅れを示すリアルタイムデータに基づいて、潜在的顧客の携帯端末装置にサービス券を送信するものである。そして、引用発明７は、ユーザに混雑回避経路を提供するものではなく、「予め定められた情報に基づき、前記報酬を変更する」ものでもない。このため、引用発明２に技術分野の異なる引用発明７を適用しようとする動機はなく、適用しても、相違点６－３の構成には至らない。また、甲１、甲３～甲６にも相違点６－３の構成は記載されていない。 したがって、相違点６－１及び相違点６－２について検討するまでもなく、本件発明６は、引用発明２及び甲１、甲３～甲７に記載された技術的事項に基づいて当業者が容易に発明をすることができたものではない。 ｂ また、引用発明７を主引用例としても、上記ａのとおり、甲１～６には「前記予め定められた情報は、前記要請を承諾したユーザのスケジュールを含む」「予め定められた情報に基づき、前記報酬を変更する」ことは記載されていないため、引用発明７に、甲１～６に記載された技術的事項を適用しても、上記相違点６－３の構成には至らない。 ｃ そして、上記相違点６－３の構成とすることで、「本発明によれば、ユーザに混雑する経路の利用を控える動機付けを与え、当該経路の混雑を緩和させることができる。」（【００１６】）との効果を奏するものである。 （ウ）特許異議申立人の主張について ａ 特許異議申立人は特許異議申立書で、 （主張６－１） 甲７には、「予め定められた情報に基づき、前記報酬を変更する」ことが記載されており、甲７は、サービス券を分配するシステムに関する技術であるため、当業者によれば、この技術を甲１に記載された技術と組み合わせて、本件発明６を容易に想到できる旨（特許異議申立書第３８頁下から第５行～第３９頁第２８行）主張する。 （主張６－２） 甲２には、「（６Ｂ）各ユーザのスケジュールを記憶する記憶手段」と、「（６Ｆ）前記予め定められた情報は、前記要請を承諾したユーザのスケジュールを含む」の構成が記載されている旨（特許異議申立書第１８頁第１３行～第２０行）主張し、引用発明２に甲１に記載された技術と組み合わせて、本件発明６を容易に想到できる旨（特許異議申立書第３９頁第２９行～第３２行）主張する。 ｂ 主張の検討 （主張６－１）について 上記（イ）で検討したように、引用発明７は、ユーザに混雑回避経路を提供するものではなく、「予め定められた情報に基づき、前記報酬を変更する」ものでもない。そして、甲１にも「予め定められた情報に基づき、前記報酬を変更する」ことは記載されていない。このため、引用発明７に甲１に記載された技術的事項を適用しても、相違点６－３の構成には至らない。この点を看過している特許異議申立人の主張は適切ではない。 （主張６－２）について 引用発明２は、「ユーザの端末２００」に送信される「コンテンツ」は、「コンテンツ提供優先順位をインクリメントしながら（ステップＳ４０１）、コンテンツ効果管理ＤＢ１３５に登録されている、「提供優先順位」と、「インセンティブが付加されたコンテンツを含むコンテンツ」」に基づいて選択されており、「要請を承諾したユーザのスケジュール」により変更されるものではない。 そうすると、特許異議申立人の上記主張は、甲２の誤った理解に基づく主張であり採用できない。 （エ）小括 上記のとおりであるから、本件発明６は、当業者が、引用発明２若しくは引用発明７並びに甲１に記載された事項に基づいて、容易に発明をすることができたものであるとはいえない。 オ 本件発明７（特許異議申立人の上記（２）キの主張）について （ア）対比 本件発明７は、本件発明６に 「前記変更手段は、前記要請を承諾したユーザのスケジュールを変更する」 との減縮を加えたものであるから、本件発明７と引用発明７は、上記相違点６－１～相違点６－３に加え、下記の点で相違する。 ［相違点７］ 本件発明７の「前記変更手段」は、「前記要請を承諾したユーザのスケジュールを変更する」のに対して、引用発明７には、「前記変更手段」が、「前記要請を承諾したユーザのスケジュールを変更する」ことは特定されていない点。 （イ）相違点についての当審判断 本件発明７は、相違点６－３に係る本件発明６の「予め定められた情報」を備えている。 そして、上記エ（イ）のとおり、相違点６－３の構成は、引用発明２若しくは引用発明７及び甲１に記載された事項に基づいて、当業者が容易に想到することができたものであるとはいえない。 （ウ）特許異議申立人の主張について 特許異議申立人は、特許異議申立書で、 ａ 甲７には「前記変更手段は、前記要請を承諾したユーザのスケジュールを変更する」ことが記載されており、甲７は、サービス券を分配するシステムに関する技術であるため、当業者によれば、この技術を甲１に記載された技術と組み合わせて、本件発明７を容易に想到できる旨（特許異議申立書第３９頁下から第４行～第１８行）主張する。 しかしながら、本件発明７は、本件発明６を引用しており、本件発明６は、上記エのとおり、当業者が、引用発明２若しくは引用発明７並びに甲１に記載された事項に基づいて、容易に発明をすることができたものであるとはいえないことから、特許異議申立人の上記主張は、その前提において誤りである。 （エ）上記のとおりであるから、本件発明７は、当業者が、引用発明２若しくは引用発明７並びに甲１に記載された事項に基づいて、容易に発明をすることができたものであるとはいえない。 ２（サポート要件）特許法第３６条第６項第１号について （１）特許異議申立書における主張の概要 訂正前の請求項１、２係る特許に対する、特許異議申立人の主張は以下のとおりである。 本件特許は、特許請求の範囲の請求項１及び２に係る記載が不備のため、特許法第３６条第６項第１号に規定する要件を満たしていない特許出願に対してされたものである。 （２）特許異議申立書における主張の検討 上記第２で示したように、本件訂正請求による訂正は認められ、本件特許の請求項１，２は削除されたため、訂正前の請求項１、２に係る記載についての、サポート要件違反の取消理由は、その対象が存在しないものとなった。 ３（明確性要件）特許法第３６条第６項第２号について （１）特許異議申立書における主張の概要 訂正前の請求項１、２係る特許に対する、特許異議申立人の主張は以下のとおりである。 本件特許は、特許請求の範囲の請求項１及び２に係る記載が不備のため、特許法第３６条第６項第２号に規定する要件を満たしていない特許出願に対してされたものである。 （２）特許異議申立書における主張の検討 上記第２で示したように、本件訂正請求による訂正は認められ、本件特許の請求項１，２は削除されたため、訂正前の請求項１、２に係る記載についての、明確性要件違反の取消理由は、その対象が存在しないものとなった。 ４（実施可能要件）特許法第３６条第４項第１号について （１）特許異議申立書における主張の概要 ア 主張４－１ 本件特許は、発明の詳細な説明の記載が、請求項１、２に記載された発明を実施することができる程度に明確かつ十分に記載したものではないため、特許法第３６条第４項第１号に規定する要件を満たしていない特許出願に対してされたものである。 イ 主張４－２ 本件特許は、発明の詳細な説明の記載が、請求項１～７に記載された発明を実施することができる程度に明確かつ十分に記載したものではないため、特許法第３６条第４項第１号に規定する要件を満たしていない特許出願に対してされたものである。 （２）特許異議申立書における主張の検討 ア 主張４－１について 上記第２で示したように、本件訂正請求による訂正は認められ、本件特許の請求項１，２は削除されたため、訂正前の請求項１、２に係る記載された発明についての、実施可能要件の取消理由は、その対象が存在しないものとなった。 イ 主張４－２について 上記第５の２で判断したように、請求項３、５～７の「或る移動経路」及び「或る移動経路の利用を控える要請」について、本件特許明細書の発明の詳細な説明に、本件発明３、本件訂正発明５、本件発明６、７を実施することができる程度に明確かつ十分に記載したものであるから、特許異議申立人の上記主張を採用することはできない。 第７ むすび 以上のとおり、本件発明３は、引用発明５若しくは引用発明２並びに甲１に記載され事項に基づいて、当業者が容易に発明をすることができたものであるとはいえない。 加えて、本件訂正発明５は、引用発明６若しくは引用発明２並びに甲１に記載された事項に基づいて、当業者が容易に発明をすることができたものであるとはいえない。 また、本件発明６は、引用発明７若しくは引用発明２並びに甲１に記載された事項に基づいて、当業者が容易に発明をすることができたものであるとはいえない。 そして、本件発明７は、引用発明７若しくは引用発明２並びに甲１に記載された事項に基づいて、当業者が容易に発明をすることができたものであるとはいえない。 加えて、発明の詳細な説明の記載は、請求項３、５～７に記載された発明を実施することができる程度に明確かつ十分に記載したものである。 そうすると、請求項３、５～７に係る特許は、特許異議申立書に記載した特許異議申立理由及び取消理由によっては取り消すことはできない。 さらに、他に請求項３、５～７に係る特許を取り消すべき理由を発見しない。 また、請求項１、２、４は、上記のとおり、訂正により削除された。これにより、特許異議申立人による特許異議の申立てについて、請求項１、２、４に係る申立ては、申立ての対象が存在しないものとなったため、特許法第１２０条の８第１項で準用する同法第１３５条の規定により却下する。 よって、結論のとおり決定する。