【事件の表示】
　特許第６４０１７４１号発明「席案内装置、席案内プログラム及び席案内方法」の特許異議申立事件について、次のとおり決定する。
【結　論】
　特許第６４０１７４１号の特許請求の範囲を訂正請求書（令和２年５月２８日付け）に添付された特許請求の範囲のとおり、訂正後の請求項〔１−９〕、１０、１１について訂正することを認める。
　特許第６４０１７４１号の請求項１ないし５、７ないし１１に係る特許を維持する。
　特許第６４０１７４１号の請求項６に係る特許についての特許異議の申立てを却下する。
【理　由】
第１　手続の経緯 
ア　経緯 
　特許第６４０１７４１号の請求項１ないし１１に係る特許についての出願は、平成２８年６月１４日に特許出願され、平成３０年９月１４日にその特許権の設定登録がされ、平成３０年１０月１０日に特許掲載公報が発行された。その後、本件特許に対して３の特許異議の申立てがあり、次のとおりに手続が行われた。 
　 
平成３０年１２月２５日　　：特許異議申立人加藤隆登による請求項１ないし４、７ないし１１に係る特許に対する異議の申し立て（以下、「申立０１」という。） 
平成３１年　１月２３日　　：特許異議申立人大薮朋子による請求項１ないし４、７ないし１１に係る特許に対する異議の申し立て（同「申立０２」）
平成３１年　４月　９日　　：特許異議申立人野中啓孝による請求項１ないし１１に係る特許に対する異議の申し立て（同「申立０３」） 
令和　元年　８月　１日付け：取消理由通知書 
令和　元年１０月２４日　　：特許権者による意見書の提出及び訂正請求 
令和　元年１２月１６日　　：特許異議申立人野中啓孝による意見書の提出
令和　元年１２月２３日　　：特許異議申立人大薮朋子による意見書の提出
（特許異議申立人加藤隆登からは、令和元年１０月２４日の訂正請求に対して意見書は提出されていない。） 
令和　２年　２月２６日付け：取消理由通知書（決定の予告）
令和　２年　５月２８日　　：特許権者による意見書の提出及び訂正請求
（令和元年１０月２４日の訂正請求は取下げられたものとみなされた。）
令和　２年　６月２２日　　：特許異議申立人野中啓孝による意見書の提出
（特許異議申立人加藤隆登、同大薮朋子からは、令和２年５月２８日の訂正請求に対して意見書は提出されていない。）
　 
イ　申立の概要 
（イ−１）異議申立人加藤隆登による異議申立の理由は、おおむね以下のとおりである。
　主たる証拠として以下の甲第１号証を及び従たる証拠として以下の甲第２号証〜甲第４号証を提出し、請求項１ないし４、７ないし１１に係る特許は、特許法第２９条第２項の規定に違反してされたものであるから、上記請求項に係る特許を取り消すべきものである（以下、申立理由１という。）。（以下、異議申立人加藤隆登の提出した甲第１号証ないし甲第４号証は他の異議申立人の提出した証拠と区別するため、それぞれ、１甲１、１甲２等と記載する。） 
１甲１：特開２００７−１６４６５４号公報（甲第１号証） 
１甲２：特開２００４−１９９４１１号公報（甲第２号証） 
１甲３：特開２００８−２５０７１１号公報（甲第３号証） 
１甲４：特開２００４−１９９４１２号公報（甲第４号証） 
　 
（イ−２）異議申立人大薮朋子による異議申立の理由は、おおむね以下のとおりである。 
　主たる証拠として以下の甲第１号証を提出し、請求項１ないし４、７ないし１１に係る特許は、特許法第２９条第１項の規定に違反してされたものであるから、上記請求項に係る特許を取り消すべきものである（以下、申立理由２−１という）、および、主たる証拠として以下の甲第１号証及び従たる証拠として以下の甲第２号証〜甲第９号証を提出し、請求項１ないし４、７ないし１１に係る特許は、特許法第２９条第２項の規定に違反してされたものであるから、上記請求項に係る特許を取り消すべきものである（以下、申立理由２−２という）。（以下、異議申立人大薮朋子の提出した甲第１号証ないし甲９号証は他の異議申立人の提出した証拠と区別するため、それぞれ、２甲１、２甲２等と記載する。） 
２甲１：特表２００５−５２７０１７号公報（甲第１号証） 
２甲２：特開２００８−７７５２８号公報（甲第２号証） 
２甲３：特開２００２−３１１１７０号公報（甲第３号証） 
２甲４：特開２００２−２７９２６２号公報（甲第４号証） 
２甲５：特開２００９−１９９２９９号公報（甲第５号証） 
２甲６：特開２００９−１２２７６９号公報（甲第６号証） 
２甲７：特開２００３−２７１７６７号公報（甲第７号証） 
２甲８：特開２００２−１４０７６７号公報（甲第８号証） 
２甲９：特開２０００−１２３２５８号公報（甲第９号証） 
　 
（イ−３）異議申立人野中啓孝による異議申立の理由は、おおむね以下のとおりである。
　証拠として以下の甲第１号証を提出し、請求項１ないし５、７ないし１１に係る特許は、特許法第２９条の２の規定に違反してされたものであるから、上記請求項に係る特許を取り消すべきものである（以下、申立理由３−１という）、および、主たる証拠として以下の甲第２号証及び従たる証拠として以下の甲第３号証〜甲第６号証を提出し、請求項１ないし１１に係る特許は、特許法第２９条第２項の規定に違反してされたものであるから、上記請求項に係る特許を取り消すべきものである（以下、申立理由３−２という）。（以下、異議申立人野中啓孝の提出した甲第１号証ないし甲６号証は他の異議申立人の提出した証拠と区別するため、それぞれ、３甲１、３甲２等と記載する。） 
３甲１：特願２０１５−１５６８４８号（特開２０１７−３７３８４号公報）（甲第１号証） 
３甲２：特開２００８−７７５２８号公報（甲第２号証） 
３甲３：特開２００３−２９６４２３号公報（甲第３号証） 
３甲４：特開平９−２４５２６２号公報（甲第４号証） 
３甲５：特開２０００−２０７４６９号公報（甲第５号証） 
３甲６：特開２００３−１６７９７２号公報（甲第６号証） 
　 
第２　訂正の適否についての判断 
（１）訂正の内容 
　令和２年５月２８日の訂正請求による訂正の内容は以下のアないしキのとおりである。
ア　訂正事項１ 
　特許請求の範囲の請求項１の「前記第１検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与された認証情報と前記条件とを含む予約データを登録する予約登録部と」の記載を「前記第１検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録部と」の記載と訂正する。 
　 
イ　訂正事項２ 
　特許請求の範囲の請求項１の「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され条件に適合する空席の座席を検索する第２検索部と」の記載を「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第２検索部と」の記載と訂正する。 
　 
ウ　訂正事項３ 
　特許請求の範囲の請求項１の
「前記第１検索部で条件に適合する座席が検索されると、前記第１検索部で検索された座席の情報を案内データとして出力し、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第２検索部で検索された座席の情報を案内データとして出力する案内出力部と、
  を備える席案内装置。」
の記載を
「前記第１検索部で条件に適合する座席が検索されると、前記第１検索部で検索された座席の情報を案内データとして出力し、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第２検索部で検索された座席の情報を案内データとして出力する案内出力部と、
　前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新部と、
  を備える席案内装置。」の記載と訂正する。
　
エ　訂正事項４
　特許請求の範囲の請求項３の「前記案内出力部が前記第２検索部で検索された座席の情報を案内データとして出力すると」の記載を「前記予約データ更新部は、前記案内出力部が前記第２検索部で検索された座席の情報を案内データとして出力すると」の記載と訂正する。
　
オ　訂正事項５
　特許請求の範囲の請求項３の「案内データを提供した前記ユーザの認証情報と条件を削除して前記予約データを更新する予約データ更新部をさらに備える」の記載を「案内データを提供した前記ユーザの認証情報と条件を削除して前記予約データを更新する」の記載と訂正する。
　
カ　訂正事項６
　特許請求の範囲の請求項６を削除する。 
　 
キ　訂正事項７  
　特許請求の範囲の請求項７の「請求項１乃至６のいずれか１項に記載の席案内装置。」の記載を「請求項１乃至５のいずれか１項に記載の席案内装置。」の記載と訂正する。 
　 
ク　訂正事項８
　特許請求の範囲の請求項８の「請求項１乃至７のいずれか１項に記載の席案内装置。」の記載を「請求項１乃至５、７のいずれか１項に記載の席案内装置。」の記載と訂正する。 
　 
ケ　訂正事項９ 
　特許請求の範囲の請求項９の「請求項１乃至８のいずれか１項に記載の席案内装置。」の記載を「請求項１乃至５、７、８のいずれか１項に記載の席案内装置。」の記載と訂正する。 
　 
コ　訂正事項１０  
　特許請求の範囲の請求項１０の「前記第１検索機能で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与された認証情報と前記条件とを含む予約データを登録する予約登録機能と」の記載を「前記第１検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録機能と」の記載と訂正する。 
　 
サ　訂正事項１１ 
　特許請求の範囲の請求項１０の「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され条件に適合する空席の座席を検索する第２検索機能と」の記載を「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第２検索機能と」の記載と訂正する。 
　 
シ　訂正事項１２ 
　特許請求の範囲の請求項１０の
「前記第１検索機能で条件に適合する座席が検索されると、前記第１検索機能で検索された座席の情報を案内データとして出力し、前記認証処理機能で正しい前記ユーザによって入力されたものと認証されると、前記第２検索機能で検索された座席の情報を案内データとして出力する案内出力機能と、
  して機能させる席案内プログラム。」
の記載を
「前記第１検索機能で条件に適合する座席が検索されると、前記第１検索機能で検索された座席の情報を案内データとして出力し、前記認証処理機能で正しい前記ユーザによって入力されたものと認証されると、前記第２検索機能で検索された座席の情報を案内データとして出力する案内出力機能と、
　前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新機能と、
  して機能させる席案内プログラム。」の記載と訂正する。
　
ス　訂正事項１３
　特許請求の範囲の請求項１１の「前記第１検索ステップで条件に適合する座席が検索されないとき、前記ユーザの認証用に付与された認証情報と前記条件とを含む予約データを登録する予約登録ステップと」の記載を「前記第１検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録ステップと」の記載と訂正する。 
　 
セ　訂正事項１４ 
　特許請求の範囲の請求項１１の「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され条件に適合する空席の座席を検索する第２検索ステップと」の記載を「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第２検索ステップと」の記載と訂正する。 
　 
ソ　訂正事項１５ 
　特許請求の範囲の請求項１１の
「前記第１検索ステップで条件に適合する座席が検索されると、前記第１検索ステップで検索された座席の情報を案内データとして出力し、前記認証処理ステップで正しい前記ユーザによって入力されたものと認証されると、前記第２検索ステップで検索された座席の情報を案内データとして出力する案内出力ステップと、
  を有する席案内方法。」
の記載を
「前記第１検索ステップで条件に適合する座席が検索されると、前記第１検索ステップで検索された座席の情報を案内データとして出力し、前記認証処理ステップで正しい前記ユーザによって入力されたものと認証されると、前記第２検索ステップで検索された座席の情報を案内データとして出力する案内出力ステップと、
　前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新ステップと、
  を有する席案内方法。」
の記載と訂正する。
　
　なお、訂正前の請求項１〜９は、請求項２ないし９が、訂正の請求の対象である請求項１の記載を引用する関係にあるから、本件訂正は、一群の請求項〔１〜９〕、及び請求項１０、請求項１１について請求されている。 
　 
（２）訂正の目的の適否、新規事項の有無、特許請求の範囲の拡張・変更の存否 
ア　訂正事項１、訂正事項１０、訂正事項１３ 
　訂正事項１に係る請求項１についての訂正は、予約登録部が登録する予約データについて、訂正前は「前記ユーザの認証用に付与された認証情報と前記条件とを含む予約データ」と特定されていたのに対し、訂正後は、上記「認証情報」と「前記条件」に加えて「予約番号」を含む構成とし、加えて予約番号と認証情報が関連付けられていることをさらに特定しているから特許請求の範囲の減縮を目的とするものである。 
　そして、当該構成は発明の詳細な説明の【００３０】に「予約データ１２２は、予約の順序を特定する予約番号と、予約条件と、ユーザを特定する認証情報とを含むデータである。「予約番号」は、予約を登録する際に付与される。」との記載が、【００３９】に「その後、第２検索手段１０５は、予約データ１２２において、検索対象の予約番号と関連付けられる認証情報を抽出し、検索対象の予約番号と、検索結果で得られた座席番号と、抽出した認証情報とを取得部１１０に出力する。」との記載があるから、新規事項の追加に該当しない。 
　また、上記訂正により実質上特許請求の範囲を拡張し、又は変更するものでもない。 
　 
　訂正事項１が「座席案内装置」の予約登録部が登録するデータに関する訂正であるのに対し、訂正事項１０は「座席案内プログラム」の予約登録機能において登録されるデータについて、訂正事項１と同様の訂正を行うものであり、また、訂正事項１３は「座席案内方法」の予約登録ステップにおいて登録されるデータについて、訂正事項１と同様の訂正を行うものであるから、訂正事項１０及び訂正事項１３は、訂正事項１と同様特許請求の範囲の減縮を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。 
　 
イ　訂正事項２、訂正事項１１、訂正事項１４ 
　訂正事項２に係る請求項１についての訂正は、訂正前の「前記予約データで登録され条件に適合する空席の座席を検索する第２検索部」の記載では、「前記予約データで登録され」と「条件に適合する空席の座席を検索する第２検索部」の係り受けが不明であり、「条件」がどのように特定されているか明確ではない記載であったのに対し、「前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第２検索部」との記載とすることで、「条件」は、「前記座席の条件」すなわち、「飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付部」と特定される条件受付部で受け付け、「前記予約データで登録され」た、すなわち、「前記第１検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録部」（訂正後）と特定される予約登録部で登録された条件であることが明確となったから、明瞭でない記載の釈明を目的とするものである。 
　そして、当該構成は発明の詳細な説明に、 
「条件受付部１０２は、飲食店で空席の座席を求める来店者（以下、「ユーザ」とする）によって入力される希望の座席の条件を受け付ける。また、条件受付部１０２は、座席の条件を、検索部１０３に出力する。」（【００３５】） 
「検索部１０３は、ユーザの希望する条件に適合する空席の座席を検索する第１検索手段１０４及び第２検索手段１０５を備える。」（【００３６】）
「第１検索手段１０４は、条件受付部１０２から条件が入力されると、記憶装置１２が記憶する座席データ１２１を参照し、条件受付部１０２で受付された条件に適合する空席の座席を検索する。また、第１検索手段１０４は、検索された座席の番号を案内出力部１１２に出力する。条件に適合する座席がないとき、第１検索手段１０４は、座席の条件を認証情報生成部１０６に出力する。」（【００３７】） 
「認証情報生成部１０６は、第１検索手段１０４から条件が入力されると、ユーザを特定する認証情報を設定する。また、認証情報生成部１０６は、設定した認証情報を、入力された条件とともに予約登録部１０７に出力する。」（【００４１】） 
「予約登録部１０７は、認証情報生成部１０６から条件及び認証情報が入力されると、入力された条件及び認証情報を予約の順序を特定する予約番号とともに、予約データ１２２として記憶装置１２に登録する。」（【００４２】） 
の記載があるから、新規事項の追加に該当しない。 
　また、上記訂正により実質上特許請求の範囲を拡張し、又は変更するものでもない。 
　 
　訂正事項２が「座席案内装置」の第２検索部が座席を検索する条件に関する訂正であるのに対し、訂正事項１１は「座席案内プログラム」の第２検索機能機能において検索されるデータについて、訂正事項２と同様の訂正を行うものであり、また、訂正事項１４は「座席案内方法」の第２検索ステップにおいて検索されるデータについて、訂正事項２と同様の訂正を行うものであるから、訂正事項１１及び訂正事項１４は、訂正事項２と同様、明瞭でない記載の釈明を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。 
　 
ウ　訂正事項３、訂正事項１２、訂正事項１５
　訂正事項３に係る請求項１についての訂正は、訂正前の請求項１の座席案内装置に対して、さらに「前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新部」の構成を付加するものであるから特許請求の範囲の減縮を目的とするものである。
　そして、当該構成は、訂正前の請求項３に「前記案内出力部が前記第２検索部で検索された座席の情報を案内データとして出力すると、案内データを提供した前記ユーザの認証情報と条件を削除して前記予約データを更新する予約データ更新部をさらに備える」の記載があり、また、発明の詳細な説明に「予約データ更新部１１４は、案内出力部１１２が第２検索手段１０５で検索された座席の情報を案内データとして出力すると、案内データを提供したユーザの認証情報と条件を削除して記憶装置１２が記憶する予約データ１２２を更新する。」（【００５１】）、「また、席案内装置１は、記憶装置１２が記憶する予約データ１２２を更新する（Ｓ１３）。」（【００６８】）等の記載があるから、新規事項の追加に該当しない。 
　また、上記訂正により実質上特許請求の範囲を拡張し、又は変更するものでもない。 
　 
　訂正事項３が「座席案内装置」に予約データ更新部を付加する訂正であるのに対し、訂正事項１２は「座席案内プログラム」の予約データ更新機能を付加する、訂正事項１と同様の訂正を行うものであり、また、訂正事項１５は「座席案内方法」の予約データ更新ステップを付加する、訂正事項１と同様の訂正を行うものであるから、訂正事項１２及び訂正事項１５は、訂正事項１と同様特許請求の範囲の減縮を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。
　
エ　訂正事項４、訂正事項５
　訂正事項４、訂正事項５に係る請求項３についての訂正は、訂正事項３において、訂正前請求項３の構成が有していた一部の構成を請求項１に付加したため、請求項１の記載を引用する請求項３の記載が、訂正後の請求項１の記載と矛盾しないように訂正するものである。
　したがって、訂正事項４、訂正事項５に係る訂正は、明瞭でない記載の釈明を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。 
　
オ　訂正事項６ないし訂正事項９
　訂正事項６に係る訂正は、特許請求の範囲の請求項６を削除する訂正であるから、特許請求の範囲の減縮を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。 
　 
　また、訂正事項７ないし訂正事項９は、訂正前、請求項６の記載を引用する請求項７ないし請求項９の記載について、訂正事項６により請求項６が削除されたことにより、それぞれ、請求項６の記載の引用を削除する訂正であり、明瞭でない記載の釈明を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。 
　 
（３）小括 
　上記のとおり、訂正事項１ないし１５に係る訂正は、特許法第１２０条の５第２項ただし書第１号又は第３号に掲げる事項を目的とするものであり、かつ、同条第９項で準用する同法第１２６条第５項及び第６項の規定に適合する。 
　したがって、特許請求の範囲を、訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項［１〜９］、１０、１１について訂正することを認める。 
　 
第３　取消理由（令和２年２月２６日付け）の概要
　訂正（令和２年５月２８日）前の請求項１、２、４、５、７〜１１に係る特許に対して、当審が令和２年２月２６日に特許権者に通知した取消理由の要旨は、次のとおりである。
　
　請求項１、２、４、５、７〜１１に係る発明は、特願２０１５−１５６８４８号（先願、特開２０１７−３７３８４号公報／３甲１）の願書に最初に添付された明細書、特許請求の範囲又は図面に記載された発明と同一である。
　よって、請求項１、２、４、５、７〜１１に係る特許は、特許法第２９の２の規定に違反してされたものであり、取り消されるべきものである。
　
第４　当審の判断
１　訂正後の本件請求項１に係る特許
（１）本件発明１について 
　上記訂正後の請求項１に係る発明（以下「本件発明１」という。）は、以下のとおりである。（（ａ）〜（ｊ）は当審で付与した。） 
【請求項１】 
（ａ）飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付部と、 
（ｂ）前記飲食店における各座席の状態を含む座席データを参照し、前記条件受付部で受け付けられた条件に適合する空席の座席を検索する第１検索部と、 
（ｃ）前記第１検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録部と、 
（ｄ）前記予約登録部が予約データを登録すると、前記予約データで登録された認証情報を含む予約案内データを出力する予約情報出力部と、 
（ｅ）前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第２検索部と、 
（ｆ）前記第２検索部で条件に適合する座席が検索されると、前記ユーザによって入力される認証情報を取得する取得部と、 
（ｇ）前記取得部が取得した認証情報が、前記予約データが含む認証情報と一致するとき、前記取得部が取得した認証情報は正しい前記ユーザによって入力されたものと判定する認証処理部と、 
（ｈ）前記第１検索部で条件に適合する座席が検索されると、前記第１検索部で検索された座席の情報を案内データとして出力し、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第２検索部で検索された座席の情報を案内データとして出力する案内出力部と、 
（ｉ）前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新部と、
（ｊ）を備える席案内装置。 
　
（２）先願明細書の記載・引用発明（先願） 
　上記先願明細書には以下のとおりの記載がある。 
　 
【００１３】 
　以下、この発明の実施の形態を添付図面に基づいて説明する。 
実施の形態１． 
　図１に、本発明の実施の形態１に係る空き設備管理システム１００を含む構成の例を示す。空き設備管理システム１００は、設備の占有状況、すなわち設備が使用中であるか空いているかを表す情報を管理する。本実施形態では、設備の例としてフードコート等に設置される卓４０を管理対象とする。
【００１４】 
　空き設備管理システム１００は、制御装置１０と、受付装置２０と、複数のポケットベル２３（待機者用受信機）と、調理指示端末３０と、複数の客席端末４１（設備端末）とを備える。また、空き設備管理システム１００は、状況表示ランプ４２（設備状態表示装置）および座席５０を備える。この状況表示ランプ４２および座席５０は、卓４０のそれぞれに関連して設けられる。 
  
【００３８】 
　図７は、空き設備管理システム１００が所定の卓要求操作を受け付けた場合に実行する動作の流れの例を示す。 
　制御装置１０は、卓要求操作（設備要求操作）を受け付ける（ステップＳ１１）。卓要求操作とは、上述のように、新たな顧客が卓の割り当てを要求する操作である。この操作は、制御装置１０が受付端末２１を介して受け付けてもよい。ここで制御装置１０は、卓要求操作を表す受付番号を決定する。
【００３９】 
　図８に、この卓要求操作の受け付けに関連して表示される画面の例を示す。卓要求操作は、対応する卓（または卓の集合）を特定するものであってもよい。たとえば図８の例では、顧客は、所定のボタンを選択して操作することにより、卓要求操作に対応して希望する卓の集合を指定することができる。たとえば顧客が第１エリアを選択した場合には、第１エリアに配置された卓（図４の例では卓番号Ａ００１〜Ａ００３等の卓）に対応する卓要求操作が受け付けられることになる。 
【００４０】 
　次に、制御装置１０は、受け付けた卓要求操作に対応する卓のいずれかが空いているか否かを判定する（ステップＳ１２）。この判定は、たとえば卓状況ＤＢ７３において利用状況が「空き」となっているか否かに基づいて行われる。 
【００４１】 
　対応する卓のいずれかが空いている場合には、制御装置１０は、処理中の卓要求操作を表す受付番号に対応する行を受付管理ＤＢ７２に追加する（ステップＳ１３）。ここで追加される行は、受付番号と、受付時刻（たとえばステップＳ１１が実行された時刻）と、希望エリア（たとえばステップＳ１１において選択された領域）と、受付時点で空きが存在していたことを示す情報とを含む。 
【００４２】 
　次に、制御装置１０は、顧客に利用させるべき卓を決定する（ステップＳ１４）。たとえば、卓要求操作に対応する卓のうちから、所定の基準（たとえば最も長時間空いているもの等）に基づいて１つの卓を選択する。 
【００４３】 
　次に、制御装置１０は、ステップＳ１４で決定された卓がもはや空いていないことを示すよう、卓状況ＤＢ７３において利用状況を更新する（ステップＳ１５）。たとえば利用状況を「着席待ち」に変更する。ここで、制御装置１０はさらに、卓状況ＤＢ７３において、その卓に、受付番号および受付時刻を関連付けて記憶する。 
【００４４】 
　次に、制御装置１０は、ステップＳ１４で決定された卓に設置された状況表示ランプ４２を所定の状態に変更させる（たとえば青色で点灯させる）（ステップＳ１６）。ただしステップＳ１６は省略可能である。その場合には状況表示ランプ４２の状態は変更されない。 
【００４５】 
　次に、制御装置１０は、その卓を特定する案内情報を出力することにより、顧客に対して案内を行う（ステップＳ１７）。案内情報はたとえば受付端末２１に送信され、受付端末２１において表示される。案内情報は、本実施形態では地図の表示を含む。地図は、たとえば所定の領域（客席エリアＡ２等）においてステップＳ１４で決定された卓に対応する位置にマーク表示を付した画像である。 
【００４６】 
　図９に、この案内表示に関連して表示される画面の例を示す。案内表示は、地図の他に、たとえば、卓が空いていたことまたは卓を確保したことを示すメッセージと、受付番号と、着席後に所定の着席操作を行うこと（たとえば客席端末４１から受付番号を入力すること）を促すメッセージとを含む。
【００４７】 
　ここで、顧客は案内表示に従って決定された卓に移動し、その卓の客席端末４１において着席操作を行うことになる。本実施形態では、顧客は受付番号を入力する。 
　図１０は、着席操作に関連して表示される画面の例を示す。顧客は数字を表すボタンを操作することにより受付番号を入力することができる。 
【００４８】 
　客席端末４１は、この着席操作を受け付け（ステップＳ１８）、着席操作が行われたことを示す着席通知を制御装置１０に送信する（ステップＳ１９）。着席通知は、その着席通知を送信する客席端末４１自身の卓番号を含む。また、本実施形態では、着席通知は、着席操作に関連して入力された受付番号を含む。 
【００４９】 
　とくに図示しないが、制御装置１０は、卓状況ＤＢ７３を参照し、受信した着席通知に含まれる卓番号に関連付けられた受付番号と、受信した着席通知に含まれる受付番号とが一致するか否かを判定してもよく、一致しない場合にはエラー表示を行った後に処理をステップＳ１８に戻してもよい。 
【００５０】 
　制御装置１０は、着席通知を受信することに応じて、卓状況ＤＢ７３においてその卓の利用状況を「利用中」に変更する（ステップＳ２０）。ここで、制御装置１０はさらに、卓状況ＤＢ７３において、その卓に、着席時刻（たとえばステップＳ１９が実行された時刻）を関連付けて記憶する。次に、制御装置１０は、その卓に設置された状況表示ランプ４２を所定の状態に変更させる（たとえば赤色に点灯させる）（ステップＳ２１）。 
【００５１】 
　ステップＳ１２において、卓要求操作に対応する卓がいずれも空いていない場合には、制御装置１０は、その顧客に対してポケットベル２３を供給する（ステップＳ２２）。ポケットベル２３は、たとえば受付装置２０の取出口２２を介して提供される。なお、制御装置１０の制御に応じて取出口２２からポケットベル２３を提供するための受付装置２０の構成は、当業者が任意に設計可能である。 
【００５２】 
　図１１は、ステップＳ２２の実行に関連して表示される画面の例を示す。この表示はたとえば受付端末２１に表示される。この表示は、たとえば、卓が空いていないことを示すメッセージと、ポケットベル２３を受け取ることを促すメッセージと、ポケットベル２３の番号（以下「ポケベル番号」）（待機者識別情報）を受付装置２０に入力することを促すメッセージ（この図ではバーコードリーダ２４に読み取らせることを促すメッセージ）と、卓が空いたことに応じてポケットベル２３に通知が行われることを示すメッセージと、受付番号とを含む。 
【００５３】 
　次に、制御装置１０は、その卓要求操作に関連付けられるポケベル番号（待機者識別情報）を取得する（ステップＳ２３）。たとえばポケベル番号は、顧客がポケットベル２３に印刷されたバーコードをバーコードリーダ２４に読み取らせることに応じ、バーコードリーダ２４が取得して制御装置１０に送信する。 
【００５４】 
　ポケベル番号の取得は、様々な方法で行うことができる。たとえば受付装置２０の付近に店員を配置し、店員がポケットベル２３をバーコードリーダ２４にかざしてもよい。または、受付装置２０がポケットベル２３の提供に伴って自動的に取得してもよい。または、ポケットベル２３がポケベル番号を動的に変更可能なものである場合には、制御装置１０がポケベル番号を決定し、これを取得した後にポケットベル２３に付与してもよい。 
【００５５】 
　次に、制御装置１０は、処理中の卓要求操作を表す受付番号に対応する行を受付管理ＤＢ７２に追加する（ステップＳ２４）。ここで追加される行は、受付番号と、受付時刻（たとえばステップＳ１１が実行された時刻）と、希望エリア（たとえばステップＳ１１において選択された領域）と、受付時点で空きが存在していなかったことを示す情報と、ステップＳ２３で取得したポケベル番号とを含む。 
　 
【００６８】 
　客席端末４１は、終了操作を受け付けると、終了操作が行われたことを示す終了通知を制御装置１０に送信する（ステップＳ４２）。終了通知は、その終了通知を送信する客席端末４１自身の卓番号を含む。制御装置１０は、終了通知を受信することに応じて、該当する卓に設置された状況表示ランプ４２（言い換えると、終了通知に含まれる卓番号に係る状況表示ランプ４２）を所定の状態に変更させる（たとえば青色に点灯させる）（ステップＳ４３）。 
　 
【００７１】 
　ステップＳ４４において、その卓を希望している待機中の顧客が存在する場合には、制御装置１０は、その卓に案内すべき顧客を決定する（ステップＳ４６）。たとえば、その卓に対応する卓要求操作のうちから、受付時刻が最も早いものを選択する。ここで、待機中の顧客の卓要求操作にはそれぞれポケベル番号が付与されているので、制御装置１０は、終了通知を受信することに応じて、ポケットベル２３のいずれかを、その終了通知に含まれる卓番号に関連付けるということができる。 
　 
【００７３】 
　このように、制御装置１０は、終了通知を受信することに応じて、受付管理ＤＢ７２（第１のデータベース）に基づき、その終了通知に含まれる卓番号と、いずれかのポケベル番号とを関連付けて、卓状況ＤＢ７３（第２のデータベース）に記憶する。より詳しく表現すると、制御装置１０は、受付管理ＤＢ７２において該当のポケベル番号に関連付けられた卓要求操作に対応する各卓（すなわちその卓要求操作において指定された希望エリアに配置された各卓）に係る各卓番号のいずれかを含む終了通知を受信することに応じて、その終了通知に含まれる卓番号と、そのポケベル番号とを関連付けて、卓状況ＤＢ７３に記憶する。 
【００７４】 
　ここで、制御装置１０は、受付管理ＤＢ７２においてそのポケベル番号を消去してもよい。 
【００７５】 
　次に、制御装置１０は、ステップＳ４６において決定された顧客に対し、呼出通知を送信する（ステップＳ４８）。たとえば、ステップＳ４６において選択された卓要求操作に関連付けられたポケベル番号を参照し、対応するポケットベル２３に対して呼出通知を送信する。呼出通知とは、たとえば顧客を受付端末２１に呼び出すための通知である。 
　 
【００７７】 
　次に、制御装置１０は、所定の呼出応答操作を受け付ける（ステップＳ４９）。呼出応答操作とは、顧客が呼出通知に応答して呼び出されたことを制御装置１０に通知する操作である。呼出応答操作はポケベル番号の入力を含み、たとえば受付装置２０を介して受け付けられる。呼出応答操作はたとえば、顧客がポケットベル２３に印刷されたバーコードをバーコードリーダ２４に読み取らせる操作に対応する。この操作に応じ、制御装置１０は、対応するポケベル番号を取得する。 
【００７８】 
　制御装置１０は、卓状況ＤＢ７３においていずれかの卓番号に関連付けられているポケベル番号を取得することに応じ、その卓の利用状況を「着席待ち」に変更する（ステップＳ５０）。ここで、制御装置１０はさらに、卓状況ＤＢ７３において、その卓に関連付けられたポケベル番号を消去してもよい。 
　 
【００８０】 
　次に、空き設備管理システム１００は、図７のステップＳ１７〜Ｓ２１と同様の処理を実行する（ステップＳ５１〜Ｓ５５）。なお、ステップＳ５１において表示される案内情報は、ステップＳ４２において送受信された終了通知に含まれる卓番号に係る卓を示す情報（たとえば図９のように、所定の領域においてその卓に対応する位置にマーク表示を付した画像等）を含む。
　 
【００９１】 
　実施の形態１ではポケットベル２３を用いているが、ポケットベル２３を用いない構成としてもよい。たとえば、空き設備管理システム１００は印刷装置を備えてもよく、ステップＳ２２において、ポケットベル２３に代えて、受付番号または待機者識別情報を印刷した紙片を提供してもよい。受付番号または待機者識別情報の双方を印刷してもよく、その場合には一方を文字または数字で、他方をバーコードにより印刷してもよい。その場合には、ステップＳ４８の処理に代えて、特定の受付番号または待機者識別情報を与えられた顧客を呼び出す呼出処理が行われる。 
　
図５
図６
　 
　以上の記載からみて、先願明細書には以下の発明（以下「引用発明（先願）」という。）が記載されていると認められる。 
　 
（Ａ）「フードコート等に設置される卓４０を管理対象と」し（【００１３】）、 
（Ｂ）「制御装置１０と、受付装置２０と、複数のポケットベル２３（待機者用受信機）と、調理指示端末３０と、複数の客席端末４１（設備端末）と」、「卓４０のそれぞれに関連して設けられる」、「状況表示ランプ４２（設備状態表示装置）および座席５０を備え」（【００１４】）、 
（Ｃ）図７は、空き設備管理システム１００が所定の卓要求操作を受け付けた場合に実行する動作の流れの例を示し（【００３８】）、 
（Ｄ）制御装置１０は、卓要求操作（設備要求操作）を受け付ける（ステップＳ１１）。卓要求操作とは、上述のように、新たな顧客が卓の割り当てを要求する操作であり、この操作は、制御装置１０が受付端末２１を介して受け付けてもよく、ここで制御装置１０は、卓要求操作を表す受付番号を決定し（【００３８】） 
（Ｅ）卓要求操作は、対応する卓（または卓の集合）を特定するものであってもよく、たとえば図８の例では、顧客は、所定のボタンを選択して操作することにより、卓要求操作に対応して希望する卓の集合を指定することができ、たとえば顧客が第１エリアを選択した場合には、第１エリアに配置された卓（図４の例では卓番号Ａ００１〜Ａ００３等の卓）に対応する卓要求操作が受け付けられることになるものであり（【００３９】）、 
（Ｆ）制御装置１０は、受け付けた卓要求操作に対応する卓のいずれかが空いているか否かを判定し（ステップＳ１２）【００４０】、 
（Ｇ）対応する卓のいずれかが空いている場合には、制御装置１０は、処理中の卓要求操作を表す受付番号に対応する行を受付管理ＤＢ７２に追加し、（【００４１】） 
（Ｈ）制御装置１０は、顧客に利用させるべき卓を決定（ステップＳ１４）し（【００４２】）、制御装置１０は、ステップＳ１４で決定された卓がもはや空いていないことを示すよう、卓状況ＤＢ７３において利用状況を更新し（【００４３】）、 
（Ｉ）制御装置１０は、その卓を特定する案内情報を出力することにより、顧客に対して案内を行い（ステップＳ１７）（【００４５】）、 
（Ｊ）顧客は案内表示に従って決定された卓に移動し、その卓の客席端末４１において着席操作を行うことになる。本実施形態では、顧客は受付番号を入力し（【００４７】）、 
（Ｋ）着席後の処理（Ｓ１８〜Ｓ２１）をおこなう（【００４８】−【００５０】）、 
（Ｌ）ステップＳ１２において、卓要求操作に対応する卓がいずれも空いていない場合には、制御装置１０は、その顧客に対してポケットベル２３を供給し（ステップＳ２２）【００５１】、 
（Ｍ）制御装置１０は、その卓要求操作に関連付けられるポケベル番号（待機者識別情報）を取得する（ステップＳ２３）。たとえばポケベル番号は、顧客がポケットベル２３に印刷されたバーコードをバーコードリーダ２４に読み取らせることに応じ、バーコードリーダ２４が取得して制御装置１０に送信し（【００５３】）、 
（Ｎ）ポケベル番号の取得は、様々な方法で行うことができる。たとえば受付装置２０の付近に店員を配置し、店員がポケットベル２３をバーコードリーダ２４にかざしてもよい。または、受付装置２０がポケットベル２３の提供に伴って自動的に取得してもよい。または、ポケットベル２３がポケベル番号を動的に変更可能なものである場合には、制御装置１０がポケベル番号を決定し、これを取得した後にポケットベル２３に付与してもよく（【００５４】）、 
（Ｏ）制御装置１０は、処理中の卓要求操作を表す受付番号に対応する行を受付管理ＤＢ７２に追加する（ステップＳ２４）。ここで追加される行は、受付番号と、受付時刻（たとえばステップＳ１１が実行された時刻）と、希望エリア（たとえばステップＳ１１において選択された領域）と、受付時点で空きが存在していなかったことを示す情報と、ステップＳ２３で取得したポケベル番号とを含み（【００５５】）、 
（Ｐ）客席端末４１は、終了操作を受け付けると、終了操作が行われたことを示す終了通知を制御装置１０に送信する（ステップＳ４２）。終了通知は、その終了通知を送信する客席端末４１自身の卓番号を含む。制御装置１０は、終了通知を受信することに応じて、該当する卓に設置された状況表示ランプ４２（言い換えると、終了通知に含まれる卓番号に係る状況表示ランプ４２）を所定の状態に変更させる（たとえば青色に点灯させる）（ステップＳ４３）（【００６８】）。 
（Ｑ）ステップＳ４４において、その卓を希望している待機中の顧客が存在する場合には、制御装置１０は、その卓に案内すべき顧客を決定する（ステップＳ４６）。たとえば、その卓に対応する卓要求操作のうちから、受付時刻が最も早いものを選択する。ここで、待機中の顧客の卓要求操作にはそれぞれポケベル番号が付与されているので、制御装置１０は、終了通知を受信することに応じて、ポケットベル２３のいずれかを、その終了通知に含まれる卓番号に関連付けるということができ（【００７１】）、 
（Ｒ）制御装置１０は、終了通知を受信することに応じて、受付管理ＤＢ７２（第１のデータベース）に基づき、その終了通知に含まれる卓番号と、いずれかのポケベル番号とを関連付けて、卓状況ＤＢ７３（第２のデータベース）に記憶する。より詳しく表現すると、制御装置１０は、受付管理ＤＢ７２において該当のポケベル番号に関連付けられた卓要求操作に対応する各卓（すなわちその卓要求操作において指定された希望エリアに配置された各卓）に係る各卓番号のいずれかを含む終了通知を受信することに応じて、その終了通知に含まれる卓番号と、そのポケベル番号とを関連付けて、卓状況ＤＢ７３に記憶し（【００７３】）、 
（Ｓ）制御装置１０は、ステップＳ４６において決定された顧客に対し、呼出通知を送信する（ステップＳ４８）。たとえば、ステップＳ４６において選択された卓要求操作に関連付けられたポケベル番号を参照し、対応するポケットベル２３に対して呼出通知を送信し（【００７５】）、 
（Ｔ）制御装置１０は、所定の呼出応答操作を受け付ける（ステップＳ４９）。呼出応答操作とは、顧客が呼出通知に応答して呼び出されたことを制御装置１０に通知する操作であり、呼出応答操作はポケベル番号の入力を含み、たとえば受付装置２０を介して受け付けられ、呼出応答操作はたとえば、顧客がポケットベル２３に印刷されたバーコードをバーコードリーダ２４に読み取らせる操作に対応し、この操作に応じ、制御装置１０は、対応するポケベル番号を取得し（【００７７】）、 
（Ｕ）制御装置１０は、卓状況ＤＢ７３においていずれかの卓番号に関連付けられているポケベル番号を取得することに応じ、その卓の利用状況を「着席待ち」に変更し、ここで、制御装置１０はさらに、卓状況ＤＢ７３において、その卓に関連付けられたポケベル番号を消去してもよく（【００７８】）、 
（Ｖ）空き設備管理システム１００は、図７のステップＳ１７〜Ｓ２１と同様の処理を実行する（ステップＳ５１〜Ｓ５５）（【００８０】）、 
（Ｗ）実施の形態１ではポケットベル２３を用いているが、ポケットベル２３を用いない構成としてもよく、たとえば、空き設備管理システム１００は印刷装置を備えてもよく、ステップＳ２２において、ポケットベル２３に代えて、受付番号または待機者識別情報を印刷した紙片を提供してもよいものであり、受付番号または待機者識別情報の双方を印刷してもよく、その場合には一方を文字または数字で、他方をバーコードにより印刷することも可能であり、この場合には、ステップＳ４８の処理に代えて、特定の受付番号または待機者識別情報を与えられた顧客を呼び出す呼出処理が行われる（【００９１】） 
（Ｘ）空き設備管理システム。 
　 
（３）対比・判断 
ア　引用発明（先願）では、（Ａ）〜（Ｅ）において、フードコート等に設置される卓を要求する顧客が卓要求操作を受け付ける空き設備管理システムであって、上記卓要求は、対応する卓（または卓の集合）を特定するものを含むものであってもよいから、本件発明１の構成（ａ）を備える。 
イ　引用発明（先願）では、（Ｆ）において、受け付けた卓要求操作に対応する卓のいずれかが空いているか否かを判定しているから、本件発明１の構成（ｂ）を備える。 
ウ　引用発明（先願）では、図５によれば、（Ｆ）において受付時空きなしの場合、（Ｌ）〜（Ｎ）のポケベルを用いた実施例では、「受付番号」、「希望エリア」、「ポケベル番号」を登録するものであるが、これを（Ｗ）のポケベルを用いない例としたときには、受付番号または待機者識別情報の双方を印刷するものであってもよいから、ポケベル番号の代わりが「待機者識別情報」となることは明らかであることを鑑みれば、本件発明１の構成（ｃ）を備える。　 
エ　ウのとおり、引用発明（先願）では、受付番号または待機者識別情報の双方を印刷するから、構成（ｄ）を備える。 
オ　引用発明（先願）では、（Ｐ）〜（Ｒ）において、客席端末で顧客が、卓の利用を終了する処理を行うと、その卓を希望する次の利用者がいるか否か判別しているから、構成（ｅ）を備える。 
カ　引用発明（先願）では、（Ｒ）〜（Ｔ）において、上記終了処理において終了処理がなされた卓番号にポケットベルの番号を関連付け、対応するポケットベルを呼出し、ポケベル番号の入力を含む呼出し応答操作を行うとされており、（Ｗ）の例の場合、ポケベル番号の代わりに待機者識別情報が関連付けされること先の検討のとおりであるから、上記（Ｒ）〜（Ｔ）において、（ポケベル番号の代わりに）待機者識別番号の入力を受け付けることは明らかであり、構成（ｆ）を備える。 
キ　引用発明（先願）では、（Ｕ）において、「いずれかの卓番号に関連付けられているポケベル番号を取得することに応じ、その卓の利用状況を「着席待ち」に変更し」ており、Ｗ）の例とすれば、ポケベル番号に代わる待機者識別番号が正しいかどうか判別することは明白であるから、構成（ｇ）を備える。 
ク　引用発明（先願）では、（Ｇ）、（Ｈ）にて卓の空きがあるとき（Ｉ）の「その卓を特定する案内情報を出力することにより、顧客に対して案内を行い（ステップＳ１７）」の処理を行こと、および、（Ｕ）にて「いずれかの卓番号に関連付けられているポケベル番号を取得する」とその卓の利用状況を「着席待ち」に変更し、さらに（Ｖ）にて「空き設備管理システム１００は、図７のステップＳ１７〜Ｓ２１と同様の処理を実行する」から、構成（ｈ）を備える。 
ケ　引用発明（先願）では、卓を特定する案内情報を出力することにより、顧客に対して案内を行った（案内データを提供）後の処理について、着席処理などは特定されているが、「前記案内データを提供した前記ユーザの認証情報と
前記座席の条件
　以下、この点について詳細に検討する。
　本件発明１の構成（ｉ）は、構成（ｈ）において、検索された座席の情報を案内データとして出力し、前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能であることを特定している。
　上記本件発明１の構成と引用発明（先願）との構成とを対比すれば、引用発明（先願）では、構成（Ｓ）にて呼出し通知を受けた顧客が、構成（Ｔ）にてポケットベルの番号を制御装置に通知することで、構成（Ｕ）により、制御装置が卓番号に関連付けられているポケベル番号を取得したとき、構成（Ｖ）にて、顧客に対して案内を行う（ステップＳ１７）が、この際に、その卓に関連付けられたポケベル番号を消去（すなわち、認証情報の削除）が可能である構成を有しているから、この点で、上記本件発明１の構成（ｉ）の「前記案内データを提供した前記ユーザの認証情報を削除可能である」構成と一応対応する。しかし、引用発明（先願）の「卓状態ＤＢ７３」には、本件発明１の「条件」に相当する情報がなく、また、引用発明（先願）の受付管理ＤＢ７２の「希望エリア」が本件発明１の「条件」に相当するとしても、これを削除可能であることは記載されていない。よって「座席の条件を削除可能である」ことについては、引用発明（先願）との対比における相違点となる。
　
　この点、異議申立人野中啓孝は、令和２年６月２２日付け意見書３頁の上段にて、先願明細書の７８段落と図５を摘記して、意見を述べている。しかし、７８段落にて、「その卓に関連付けられたポケベル番号を消去してもよく」と説明されているのは、「卓状況ＤＢ７３」のことであり、対応する図面として、図５（受付管理ＤＢ７２）を用いているのは誤りであり、図５において、ポケベル番号を消去することが可能であることは直接記載がない事項である。
　また、同意見書５頁において「そして、受付番号１３００、１３０２のようにポケベル番号を付与したケースであっても、希望エリアに空きが生じて顧客を呼び出した後はポケベル番号が不要になることから、ポケベル番号を消去しても良いことが記載されている（【００７８】）、この際、ポケベル番号には希望エリアが関連付けられていることから（【００５５】【００５６】【図５】）、ポケベル番号番号を消去することには、条件を削除することも含まれていることが明らかである。」と主張している。しかし、「ポケベル番号には希望エリアが関連付けられている」ことと、「ポケベル番号を消去することには、条件を削除することも含まれていることが明らかである」との関係が何ら説明されていない。
　
　仮に、図６のポケベル番号の削除に伴って、図５のポケベル番号が削除されるとしても、本件発明１の「前記座席の条件を削除可能である」を、引用発明（先願）との一致点とすることはできない。
　図５において、各行中の「希望エリア」の欄（例えば、受付番号１３００の行の「第１エリア」という部分）を削除するには、i）受付番号１３００の行そのもののレコードを全て削除する、ii）受付番号１３００の行のレコードは残し、「第１エリア」の記録だけ削除するの二つが考えられるものの、先願明細書の図５の受付番号１２３３、１２３４等の行（受付時に空きがあり、既に顧客を座席に案内した受付番号のレコードである）によれば、図５の受付管理ＤＢにおいて、テーブルに空きがあり顧客をテーブルに案内した後も受け付けたレコードは削除されておらず、i）の処理は行っていない。
　そして、「受付時空き」が「あり」のレコードにおいて、希望エリアの記録が削除されていないから、顧客をテーブルに案内することに伴って「ポケベル番号」を削除するとしても、希望エリアの記録を削除することは、処理として不自然であり、ii）の処理が行われていると認定することもできない。
　以上のとおり、図５に記載された受付管理ＤＢ（７２）における、各受付番号のレコードの記録状態からみて、「希望エリア」の列の記録は削除されておらず、引用発明（先願）は構成（ｉ）を備えていない。
　
コ　上記引用発明（先願）が備えていない構成について、先願出願時点において、周知慣用手段であって、先願明細書に記載されているに等しい事項であるということはできない。
　 
（４）してみると、本件発明１は、その出願の日前の特許出願であって、その出願後に出願公開がされた特願２０１５−１５６８４８号の特許出願の願書に最初に添付された明細書、特許請求の範囲又は図面に記載された発明と同一であるということはできず、特許法第２９条の２の規定に違反してなされたものであるということはできない。 
　 
２　請求項２〜請求項５、請求項７〜９に係る特許について 
　上記請求項に係る特許は、請求項１の記載を引用し、更に限定する構成を付加したものであるから、請求項１について検討したのと同様、先願明細書に記載された発明であるということはできない。
　 
３　請求項１０、請求項１１について 
　請求項１０、請求項１１は、請求項１の「案内装置」の発明を、それぞれ、「席案内プログラム」、「席案内方法」としたのみであり、請求項１と同様の構成であるから、請求項１と同様、先願明細書に記載された発明であるということはできない。
　 
第５　令和元年８月１日付けで通知した取消理由について 
１　訂正（令和元年１０月２４日）前の請求項１〜１１に係る特許に対して、当審は、申立０２の申立理由２−１及び２−２をふまえ、令和元年８月１日付けで下記の取消理由（ア）〜（ウ）を特許権者に通知した。 
　 
（ア）（進歩性）請求項１ないし５、７ないし１１に係る発明は、本件特許出願前に日本国内または外国において、頒布された下記の引用例に記載された発明に基いて、本件特許出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、請求項１ないし５、７ないし１１に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 
　 
（イ）（明確性）本件請求項１ないし１１特許は、特許請求の範囲の記載が不備のため、特許法第３６条第６項第２号に規定する要件を満たしていない特許出願に対してされたものである。 
　 
（ウ）（サポート要件）本件請求項６ないし９に係る特許は、明細書の記載が不備のため、特許法第３６条第６項第１号に規定する要件を満たしていない特許出願に対してされたものである。 
　 
２　以下に示すとおり、取消理由（ア）〜（ウ）は令和２年５月２８日の訂正請求により解消する。 
　 
（１）取消理由（イ） 
　訂正事項２、訂正事項１１、訂正事項１４により、特許請求の範囲が訂正されることにより、上記第３（２）イで検討したとおり第２検索部（第２検索機能、第２検索ステップ）により検索される条件は、明確となったから取消理由（イ）は解消した。 
　 
（２）取消理由（ウ） 
　訂正事項６ないし９により、明細書の記載と対応しない請求項は削除されたから、取消理由（ウ）は解消した。 
　 
（３）取消理由（ア） 
ア　訂正後の請求項１に係る発明 
（ア）本件発明１について 
　上記訂正請求により訂正された訂正後の請求項１に係る発明（以下「本件発明１」という。）は、上記第４　１（１）のとおりである。 
　 
（イ）引用例の記載・引用発明 
　取消理由（ア）において引用した特表２００５−５２７０１７号公報（２甲１、以下引用例という。）には以下の事項が記載されている。 
　 
【０００１】 
　本発明は、食事注文、食事品の準備処理、支払いを促進し、顧客の全体的なレストラン及びその他の飲食サービス施設における体験を改善するという分野に関する。特に、この発明は、一つまたはそれ以上のサーバに無線で接続された、薄いタッチ式画面端末と携帯機を含有し、顧客が自分自身で迅速に、効率よく食事の注文及び支払いができるシステムに関する。 
　 
【発明が解決しようとする課題】 
【００２１】 
　それ故、本発明は、以前の発明における多くの技術的欠点を克服するものである。本発明の目的には、飲食業界における最適なハードウエア機器の使用と施行により、顧客が従業員の介入なしで無線で注文できることを含有する。 
【００２２】 
　完全な注文処理解決で、注文受付や、注文遂行過程処理、支払い処理方法に対処することが、本発明の更なる目的である。 
【００２３】 
　低コストで信頼性のある、安全なシステムで、飲食業者の運用をより効率良くするシステムを提供することが、本発明の更なる目的である。 
【００２４】 
　顧客の待ち時間を最小限にし、顧客へのサービスと、顧客の飲食業店における全体的な体験を改善することが、本発明の更なる目的である。 
【００２５】 
　従業員不足と従業員費用増加を緩和するシステムを提供することが、本発明の更なる目的である。 
【００２６】 
　固定した端末または携帯機を使用し、注文受付や支払い処理のできるシステムを提供することが、本発明の更なる目的である。携帯機には、携帯電話や、ＰＤＡ、及びそれ以外の無線機器が含まれる。 
　 
【００３３】 
　レストランや食事施設等において、自動座席配置（隣接するテーブルに着く選択も含む）を可能にすることが、本発明の更なる目的である。 
　 
【課題を解決するための手段】 
【００４２】 
　本発明は、レストラン等の食事施設にて、顧客の為の食事料理注文処理システムを改善することを目的としている。本発明は、特別に設計された端末と、現存のインターネット・アクセス（接続）が可能な携帯機器を利用し、レストラン等の食事施設にて、顧客が従業員の介入なしに、飲料品や食事料理品を無線で注文したり、その支払いができるようにしている。それ故、本発明は、注文処理と支払い処理だけにとどまらず、注文から支払いまでの完全な遂行過程処理を含み、更に、多国言語使用、自動着席案内、事前注文、顧客への報奨ポイント、動的販売、余った在庫販売の促進等の、特別追加企画を含む。 
【００４３】 
　費用効率の良い、信頼性の高い、安全なシステムに加えて、この発明は、全体の注文処理を非常に早め、顧客の待ち時間を減らし、レストラン等の食事施設における運営の効率を向上させ、顧客へのサービスを増し、顧客のレストラン等での総合的体験を改善する。その上、この発明技術を取り入れることにより、レストラン等の食事施設の持ち主は、従業員不足と従業員費用の心配から緩和される。 
　 
【００９５】 
　図６．１．１．１は、現金と現金不要支払い媒体の両方を受け入れるレストランにおいて端末使用するところの過程論理の図である。示されているように、過程は団体が店［１０］に入るところから始まる。この言葉「団体」は、首尾一貫性のために、顧客が数人であろうが一人であろうが用いられる。店の経営者の好みにより、顧客が自分で席を選ぶことができ、全ての注文過程を手早く済ませ、店の労働コストを削減することができる自動着席案内システム［１５］を使うかどうかを選ぶことができる。もし店が自動着席案内システムを使っているならば［１５：はい］、論理は図８．１．３．１［２５］に描写されているように進み、後でテーブルへ向かっている団体に戻る［２２０］。しかし、もし店が自動着席案内システムを使っていなければ［１５：いいえ］、従業員は団体の幹事から名前、人数、禁煙席か喫煙席かを聞かなければならない［３０］。 
【００９６】 
　団体幹事の名前と来店コード（下参照）は注文システムにログインする安全な手段として一緒に使われている。付加して、団体幹事の名前は、「団体名」の役割を果たし、特に団体がいくつかのテーブルに分かれて座っていて、注文をするのに違う端末を使っている場合に、団体のメンバーを一まとめにすることに役立つ。団体幹事は名前が明記されている現金不要支払いカードを提示することにより、若しくはこのシステムのために特別にデザインされたカード（もしそのようなカードが使われるようになれば）を使うことにより、従業員に名前を知らせることもできるということは言及すべきである。 
【００９７】 
　そして従業員は顧客の名前、団体の人数、禁煙席か喫煙席かをシステムに入力する［４０］。情報を入力することにより、システムはその団体のための「来店コード」を発行する［５０］。「来店コード」はアットランダムに作られるコードで、数字と文字によって成り立ち、団体が店にいる間、団体を識別するために用いられる。この来店コードは発行からその顧客の団体がログアウトし、勘定が支払われるまで有効である。つまり、来店コードは顧客が注文を入れる前に実際に店の中にいるということを確実にするための安全装置の役割をも果たす。これは現金支払いを食事の後に顧客から受けつける店において注文が携帯機器を用いて行われる場合に非常に重要である。もしなんらかの、団体が店で注文をしている間にのみ有効なアットランダムに作られたコードがなければ、誰かレストランの外にいる者が自分の携帯機器を使って悪ふざけで注文を入れるということも可能であるからである。更に、来店コードは顧客にテーブルが与えられて初めて使えるようになる。 
【００９８】 
　その次に従業員は来店コードとバーコードが含まれたスリップを発行し、団体の幹事に手渡す［６０］。このスリップはステップ５０で来店コードが作られた後、システムによって自動的にプリントされることもできる。次に従業員は席が空いているかどうかを確認する［７０］。もし空席があれば［７０：はい］従業員は特定のテーブル用に来店コードを使用可能にし［２１０］、そして団体にテーブル番号を知らせる、若しくは団体にテーブルを示す［２１５］。その後団体はテーブルへと進む［２２０］。もし空席がなければ［７０：いいえ］、団体は待合室内の「ゲスト用端末」が空いているかを見ることができる［８０］。「ゲスト用端末」は、実際のテーブルで使えるのと同じような注文端末である。しかしながらこれはあくまでも閲覧するためと、その日可能なメニューアイテムの前注文をするためのみに使うことができる。顧客はまだ席に着いていないので、前注文されたアイテムはキッチンには送られず、臨時的に記憶されて、後に着席した後、回復することができる。 
　 
【０１０２】 
　もし、団体の誰も携帯機を持っていない場合［１５０：いいえ］従業員が、テーブルに案内するまで、待つことになる。しかし、団体が、携帯機を持っている場合［１５０：はい］、図形８．１．５に表されている説明に基づきメニューを見たり、前もって注文することができる。 
　テーブルが空くと、従業員が、団体の情報をシステムより読み取る［２００］。前にも述べたように、システムは、どの団体に、テーブルが利用できるか、表示することができる。それで、従業員が、団体の来店コードを利用できるテーブル用にアクティブ化する［２１５］。そして、団体はテーブルに案内される［２２０］。 
【０１０３】 
　団体がテーブルに案内されると、幹事となる人が言語を選択する［２２５］、その店舗の所在する所で通常使われている言語と異なっていても、システムと店舗との設定がされていれば、選択された言語が端末のスクリーンに表示される。それから幹事が、名前と来店コードを端末に入力して、ログインする［２３０］。一つの団体が複数のテーブルを使用する場合、複数の端末を使用することになるので、システムはログインした人が幹事かどうかを確認する必要がある［２４０］。団体が二つ以上のテーブルと端末を使用する場合（テーブル一つに一端末と仮定して）、他のメンバーが端末に団体の来店コードでログインすることは可能だが、個人名意外に団体の幹事の名前を指定しなければならない。団体の幹事がログインした場合には他の人が同じ来店コードでログインするこが出来ない事を覚えておく必要がある。幹事以外の人が図形８．３．１に示された様に注文に追加することはできるが注文自体をすることはできない。幹事は注文担当を指名する場合以外は、メンバーの注文を確認する必要がある［図８．３．１：１０４−１０６］、その場合には、メンバーが直接注文することができる。 
　 
【０２０５】 
　図８．１．３．１は飲食店の自動着席案内の論理を詳述したものである。この過程は、図８．１．３．２（手順１０：テーブルの利用可能性確認前）に記述されるように、事前にテーブルの利用可能性を確認することから始まる［１０］。入力された情報をもとにして、システムはテーブルが利用可能かどうか判断する［２０］。続いてシステムはテーブルが利用可能かどうか、自動着席案内システムが保留されていないかどうかの確認を行う［３０］。従業員は、様々な理由から必要と判断すれば、着席案内をマニュアルで行う。その場合はシステムにより自動的に顧客が着席案内されるのを一時的に望まないため、自動着席案内システムを保留にすることができる。 
【０２０６】 
　利用可能なテーブルがあり、自動着席案内システムが保留になっていない場合［３０：はい］、システムは、利用可能なテーブルに顧客の団体の総人数が着席できるかどうか確認する［４０］。団体の規模が利用可能なテーブルの最大着席人数を超えない場合［４０：いいえ］、つまりその団体が着席できるテーブルが利用可能な場合には、論理は以下の「すぐに利用可能なテーブル」と題した項目に記述されるように続く。 
【０２０７】 
　どの利用可能なテーブルにもその団体が着席できない場合［４０：はい］、システムは２つの隣接したテーブルが利用可能かどうか確認する［１００］。もしあれば［１００：はい］、次の論理は以下の「すぐに利用可能なテーブル」と題した項目で説明される。一方、もし２つの隣接するテーブルが利用可能でない場合［１００：いいえ］、その旨を示すメッセージが団体の幹事に表示される［１１０］。団体の幹事は、幹事とその団体は１）どんなテーブルの組み合わせでもその団体が着席できるか確認したい、２）隣接したテーブルが空くのを待ちたい、または３）待ちたくない（施設を去る）のいずれかを示唆しなければならない［１２０］。 
【０２０８】 
　団体が待ちたくない場合［１２０：待たない］、施設を退出してもよい［１３０］。団体が隣接したテーブルが空くのを待ちたい場合［１２０：隣接したテーブルを待つ］、図８．１．３．２（手順３００：テーブルの利用可能性確認後）に示すように、団体の幹事は幹事の情報をログイン端末／機器に入力する［１４０］。するとシステムはその団体を（隣接するテーブルの）待機リストに追加する［１５０］。その団体は隣接するテーブルが利用可能になるまで待たなくてはならない［２００］。テーブルが利用可能となったときに起こる論理は、以下の「利用可能になったテーブル」と題した項目に記述される。もし、その団体の幹事がどんなテーブルの組み合わせも受容すると決定した場合［１２０：全てのテーブル］、システムはその団体に必要な数のテーブルが利用可能かどうか確認する［１６０］。もしあれば［１６０：はい］、次の論理は以下の「すぐに利用可能なテーブル」と題した項目で説明される。もし必要な数のテーブルが利用可能でない場合［１６０：いいえ］、団体の幹事は、幹事とその団体が待つか待たないかを決定する［１７０］。もしその団体が待ちたくない場合［１７０：いいえ］、施設を退出することは自由である［１３０］。もしその団体が待つことを決めた場合［１７０：はい］、図８．１．３．２（手順３００：テーブルの利用可能性確認後）に示すように、団体の幹事は幹事の情報を入力しなければならない［１８０］。システムはその団体を（すべての利用可能なテーブルの）待機リストに追加する［１９０］。その後その団体はただ待っているだけでよい［２００］。テーブルが利用可能になったときに起こる論理は以下の「利用可能になったテーブル」と題した項目に記述される。 
【０２０９】 
　しばしば、どうしてもテーブルが利用できないことが起こる。（つまり、団体の規模に対してテーブルの席数の確認ができない）［３０：いいえ］このような場合には、団体はテーブルが利用可能になるのを待つかどうか決定できる［３００］。待ちたくない場合［３００：いいえ］、施設を退出しても良い［３１０］。しかし、待ちたい場合［３００：はい］、図８．１．３．２（手順３００：テーブルの利用可能性確認後）に特定されるように、団体幹事は自分の情報を入力しなければならない［３２０］。いったん入力が完了すると、その団体は待機リストに追加される［３３０］。 
【０２１０】 
　待合場所にゲスト用端末がある場合［３４０：はい］、団体は、図８．１．３．５（手順１０：端末）に示された論理に従ってメニューを閲覧したり、事前に注文をしたりすることができる［３５０］。ゲスト用端末がない場合でも［３４０：いいえ］、団体のメンバーはメニューを閲覧することができる［３８０］。もし、団体のメンバーが携帯機を持たない場合や、持っていても自分の携帯機を使ってメニューの閲覧／事前注文をしない場合は［３８０：いいえ］、テーブルが利用可能になるまで待たなければならない［４００］。テーブルが利用可能になったときに起こる論理は、以下の「利用可能になったテーブル」と題する項目に記述される。団体メンバーの誰かが自分の携帯機を使ってメニューの閲覧や事前注文をしたい場合［３８０：はい］、図８．１．３．５（手順１０：携帯）に明記されているようにして、それをすることができる［３９０］。 
【０２１１】 
　ゲスト用端末または携帯機がメニューの閲覧や事前注文に使用されるかどうかにかかわらず、テーブルが利用可能になったときの過程を表す論理は、以下の「利用可能になったテーブル」と題する項目に記述される。 
【０２１２】 
　　利用可能になったテーブル 
　施設が現金及び現金不要の支払いが可能なシステムを利用している場合［５００：現金＆現金不要支払い］、システムは特別な「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示する［５１０］。次の論理は、以下の「利用可能になったテーブル：来店スリップの確認」と題する項目に記述される。一方、施設が現金不要支払いのみのシステムを利用している場合［５００：現金不要支払いのみ］、「利用可能なテーブル」画面は、団体の幹事名、団体の人数、テーブル番号を表示する［５２０］。次の論理は、このまま続く（以下）。 
【０２１３】 
　　利用可能になったテーブル：来店スリップの確認 
　団体の幹事が来店スリップを持っている場合［５３０：はい］、幹事は自動着席案内または同様のサービスへと進み、自分の団体の来店スリップにあるバーコードをスキャンする［５４０］。システムは、来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し［５５０］、論理は以下の「来店コードを有効にする」と題する項目に続く。団体の幹事が来店スリップを持っていない場合［５３０：いいえ］、顧客／団体の幹事が短距離通信機能をもつ携帯機（つまり赤外線、ブルートゥース）を使用しているかどうかで論理が異なる［５６０］。幹事がそのような機能を持つ携帯機を使用していない場合［５６０：いいえ］、次の論理は以下の「来店コードを有効にする」と題する項目で説明される。団体の幹事がそのような機能を持った携帯機を利用している場合［５６０：はい］、幹事は顧客ＩＤとその他の情報を自動着席案内または同様の機器／端末に送信しなければならない［５７０］。するとシステムは、利用可能なテーブルの番号を顧客の携帯機にワイアレスで転送する［５８０］。次の論理は、以下の「来店コードを有効にする」と題する項目に記述される。 
【０２１４】 
　　すぐ利用可能なテーブル 
　図８．１．３．２（手順３００：テーブルの利用可能性確認後）に記述されているように、団体の幹事は幹事情報の入力へと進み［５０］、論理は以下に記述されるように続く。 
【０２１５】 
　　来店コードを有効にする 
　システムは、団体の来店コードまたは顧客のアカウントを有効にし［５９０］、論理の流れは、この図の論理に参照を付けた図へと戻る。 
【０２１６】 
　図８．１．３．２は、顧客情報の入力の過程論理を詳述したものであり、飲食店の自動着席案内の過程論理における図８．１．３．１によって主に使用される。過程が開始する時点は、自動着席案内過程論理の図［図８．１．３．１］から参照するタイミングによる［１０］。テーブルの利用可能性確認前に顧客情報の入力の要求が起こると［１０：テーブルの利用可能性確認前］、次の論理は以下の「テーブルの利用可能性確認前」と題した項目に記述される。しかし、テーブルが利用可能かどうかの確認の後に顧客情報の入力の要求が行われると［１０：テーブルの利用可能性確認後］、論理は以下の「テーブルの利用可能性確認後」と題した項目で説明される。 
【０２１７】 
　　テーブルの利用可能性確認前 
　顧客が短距離通信機能を備えた携帯機（つまり赤外線、ブルートゥース）も、注文システム専用のシステムカードも持たない場合［２０：いいえ］、顧客は専用の着席案内機器または端末を使用して、使用言語を選択しなければならない［３０］。次に、顧客は団体の人数と喫煙の有無を入力する［４０］。次の論理は、以下の「テーブルの利用可能性確認前：情報をサーバに転送する」と題する項目で説明される。 
　 
【０２２２】 
　　テーブルの利用可能性確認前：情報をサーバに転送する 
　顧客情報と嗜好はサーバに転送され［１６０］、論理はこの図の論理に参照を付けた図に戻る。 
【０２２３】 
　　テーブルの利用可能性確認後 
　顧客が、（テーブルの利用可能性確認前において）携帯機またはシステムカードを以前に使用したことがある場合［３００：はい］、次の論理は次の「テーブルの利用可能性確認後：利用履歴のある携帯機またはシステムカード」と題する項目に記述される。顧客が、携帯機またはシステムカードを以前に使用しなかった場合［３００：いいえ］、自動着席案内機器または端末は、支払い媒体の明細を含めた顧客情報を入力するよう要求する［３１０］。 
【０２２４】 
　システムが現金と現金不要支払いの両方の支払いを取り扱う場合［３２０：現金＆現金不要支払い］、顧客は希望の支払い媒体を選択する［３３０］。支払い媒体が現金と指定された場合［３４０：現金］、論理は以下の「テーブルの利用可能性確認後：名前の入力」と題した項目へと進む。希望の支払い媒体が現金不要支払いの場合［３４０：現金不要支払い］、次の論理は以下の「テーブルの利用可能性確認後：現金不要支払い媒体の選択」と題した項目に記述される。システムが現金不要支払いのみ処理する場合は［３２０：現金不要支払いのみ］、論理は以下のように進む。 
【０２２５】 
　　テーブルの利用可能性確認後：現金不要支払い媒体の選択 
　顧客は現金不要支払い媒体タイプ（つまり、クレジットカード、デビットカード、プリペイドカード、スマートカード）を自動着席案内機器／端末上で選択し［３５０］、媒体情報を自動着席案内機器／端末へ入力または転送する［３６０］。自動着席案内機器／端末が、顧客名を現金不要支払い媒体から識別することが可能であれば［３７０：はい］、論理は、以下の「テーブルの利用可能性確認後：システムタイプ」と題した項目に記述されるように続く。しかし、顧客名が媒体から確定できない場合［３７０：いいえ］、論理は以下のように進む。 
【０２２６】 
　　テーブルの利用可能性確認後：名前の入力 
　顧客はマニュアルで名前を入力する［３８０］。この名前はどんな恣意的な名前も可能で、必ずしもフルネームである必要もないことに注意する。次の論理は、採用されているシステムのタイプによって異なり［６００］、以下の「テーブルの利用可能性確認後：システムタイプ」と題した項目に記述される。 
【０２２７】 
　　テーブルの利用可能性確認後：利用履歴のある携帯機またはシステムカード 
　顧客が以前にシステムカードを利用して嗜好を転送／入力したことがある場合［５００：カード］、次の論理は以下の「テーブルの利用可能性確認後：システムタイプ」と題した項目に記述される。また、顧客が短距離通信機能（つまり、赤外線、ブルートゥース）を備えた携帯機を使用した場合［５００：携帯］、サーバは顧客のバーコードと来店コードを顧客の携帯機に転送、保存、そして表示する［５１０］。システムが顧客のためにテーブルがすぐに利用可能であると判断した場合［５２０：はい］、サーバは更に顧客のテーブル番号を顧客の携帯機に転送、保存、そして表示する［５３０］。
【０２２８】 
　テーブルが利用可能である（上記のように）かないかにかかわらず［５２０：いいえ］、施設の選択またはシステムによって、サーバは再確認のために顧客用スリップを印刷する必要があるかどうかも確認する［５４０］。その理由は、２組の顧客または団体が同じテーブルをめぐって矛盾を起こすとき（つまり、起こる可能性は非常に低いが顧客が正当に見える情報を作成するために偽の画像を携帯機に作成した場合）、スリップがどちらの顧客または団体が有効な情報を持っているかを最終的に決定する。そのようなシナリオはほとんど起こる可能性はないが、スリップの確認のための追加論理がセーフガードとして提供されている。印刷されたスリップによる確認が必要であれば［５４０：はい］、次の論理は以下の「テーブルの利用可能性確認後：システムタイプ」と題した項目に記述される。必要でない場合［５４０：いいえ］、論理の流れはこの図に記述された論理に参照を付けた図へ戻る。
【０２２９】 
　　テーブルの利用可能性確認後：システムタイプ 
　システムが現金及び現金不要支払い媒体を許容する場合［６００：現金＆現金不要支払い］、システムは来店コード及びバーコードの記載されたスリップを顧客及びその団体のために作成し印刷する［６１０］。次の論理は以下の「テーブルの利用可能性確認後：テーブルの利用可能性」と題した項目に記述される。システムが現金不要支払い媒体のみを許容する場合［６００：現金不要支払いのみ］、システムが現金不要支払いのみの環境でスリップを印刷するよう設定されているかどうか確認が行われる［６２０］。もし設定されていない場合［６２０：いいえ］、テーブルが利用可能であれば［６２４：はい］、顧客のテーブル番号が自動着席案内機器または端末に表示される［６２６］。（顧客が自分の携帯機ではなく自動着席案内機器または端末を使用している場合）しかし、もしテーブルが利用可能でない場合［６２４：いいえ］、論理の流れはこの論理図に参照を付けた論理図へ戻る。システムが現金不要支払いのみの設定においてスリップを印刷するよう設定されている場合［６２０：はい］、システムはバーコード及び顧客名が記載された顧客用来店スリップを作成し印刷する［６３０］。 
【０２３０】 
　　テーブルの利用可能性確認後：テーブルの利用可能性 
　テーブルが顧客のために利用可能であるとき［６４０：はい］、自動着席案内機器は顧客の来店スリップにテーブル番号も印刷する［６５０］。テーブルが利用可能であるかどうかにかかわらず［６４０：いいえ］、顧客は作成されたスリップを受け取り［６６０］、過程はこの論理図に参照を付けた論理図へ戻る。 
  
　以上の記載によれば、引用例には以下の発明（以下「引用発明」という。）が記載されていると認められる。 
　 
（Ａ）レストランや食事施設等において、自動座席配置（隣接するテーブルに着く選択も含む）を可能にするシステムであって、（【０００１】、【００３３】） 
（Ｂ）図６．１．１．１は、現金と現金不要支払い媒体の両方を受け入れるレストランにおいて端末使用するところの過程論理の図であり、過程は団体が店［１０］に入るところから始まり、店の経営者の好みにより、顧客が自分で席を選ぶことができ、全ての注文過程を手早く済ませ、店の労働コストを削減することができる自動着席案内システム［１５］を使うかどうかを選ぶことができき、もし店が自動着席案内システムを使っているならば［１５：はい］、論理は図８．１．３．１［２５］に描写されているように進み、後でテーブルへ向かっている団体に戻る［２２０］構成であり、（【００９５】） 
（Ｃ）図８．１．３．１は飲食店の自動着席案内の論理を詳述したものであり、図８．１．３．２（手順１０：テーブルの利用可能性確認前）に記述されるように、事前にテーブルの利用可能性を確認することから始まり［１０］、（【０２０５】） 
（Ｄ）図８．１．３．２は、顧客情報の入力の過程論理を詳述したものであり、飲食店の自動着席案内の過程論理における図８．１．３．１によって主に使用され、過程が開始する時点は、自動着席案内過程論理の図［図８．１．３．１］から参照するタイミングにより［１０］、テーブルの利用可能性確認前に顧客情報の入力の要求が起こると［１０：テーブルの利用可能性確認前］、次の論理は以下の「テーブルの利用可能性確認前」と題した項目に記述され、（【０２１６】） 
（Ｅ）顧客が短距離通信機能を備えた携帯機（つまり赤外線、ブルートゥース）も、注文システム専用のシステムカードも持たない場合［２０：いいえ］、顧客は専用の着席案内機器または端末を使用して、使用言語を選択し［３０］、次に、顧客は団体の人数と喫煙の有無を入力し［４０］、次の論理は、以下の「テーブルの利用可能性確認前：情報をサーバに転送する」と題する項目で説明され（【０２１７】テーブルの利用可能性確認前）
（Ｆ）顧客情報と嗜好はサーバに転送され［１６０］、論理はこの図の論理に参照を付けた図に戻り、（【０２２２】テーブルの利用可能性確認前：情報をサーバに転送する）（合議体注：構成（Ｄ）に戻るから、図８．１．３．１の［１０］に戻る） 
（Ｇ）入力された情報をもとにして、システムはテーブルが利用可能かどうか判断し［２０］、続いてシステムはテーブルが利用可能かどうか、自動着席案内システムが保留されていないかどうかの確認を行い［３０］、（【０２０５】） 
（Ｈ）利用可能なテーブルがあり、自動着席案内システムが保留になっていない場合［３０：はい］、システムは、利用可能なテーブルに顧客の団体の総人数が着席できるかどうか確認し［４０］、団体の規模が利用可能なテーブルの最大着席人数を超えない場合［４０：いいえ］、つまりその団体が着席できるテーブルが利用可能な場合には、論理は以下の「すぐに利用可能なテーブル」と題した項目に記述されるように続き、（【０２０６】）
（Ｉ）図８．１．３．２（手順３００：テーブルの利用可能性確認後）に記述されているように、団体の幹事は幹事情報の入力へと進み［５０］、（【０２１４】すぐ利用可能なテーブル） 
（Ｊ）顧客が、携帯機またはシステムカードを以前に使用しなかった場合［３００：いいえ］、自動着席案内機器または端末は、支払い媒体の明細を含めた顧客情報を入力するよう要求し［３１０］、（【０２２３】テーブルの利用可能性確認後） 
（Ｋ）支払い媒体が現金と指定された場合［３４０：現金］、論理は以下の「テーブルの利用可能性確認後：名前の入力」と題した項目へと進み、（【０２２４】） 
（Ｌ）顧客はマニュアルで名前を入力し［３８０］、次の論理は、採用されているシステムのタイプによって異なり［６００］、以下の「テーブルの利用可能性確認後：システムタイプ」と題した項目に記述され、（【０２２６】テーブルの利用可能性確認後：名前の入力） 
（Ｍ）システムが現金及び現金不要支払い媒体を許容する場合［６００：現金＆現金不要支払い］、システムは来店コード及びバーコードの記載されたスリップを顧客及びその団体のために作成し印刷し［６１０］、次の論理は以下の「テーブルの利用可能性確認後：テーブルの利用可能性」と題した項目に記述され、（【０２２９】テーブルの利用可能性確認後：システムタイプ） 
（Ｎ）テーブルが顧客のために利用可能であるとき［６４０：はい］、自動着席案内機器は顧客の来店スリップにテーブル番号も印刷し［６５０］、テーブルが利用可能であるかどうかにかかわらず［６４０：いいえ］、顧客は作成されたスリップを受け取り［６６０］、過程はこの論理図に参照を付けた論理図へ戻り、（【０２３０】テーブルの利用可能性確認後：テーブルの利用可能性）、（合議体注：構成（Ｉ）に戻るから、図８．１．３．１の［５０］に戻る） 
（Ｏ）システムは、団体の来店コードまたは顧客のアカウントを有効にし［５９０］、論理の流れは、この図の論理に参照を付けた図へと戻り、（【０２１５】）、（合議体注：構成（Ｉ）に戻るから、図６．１．１．１の［２５］、構成（Ｂ）に戻る） 
（Ｐ）どうしてもテーブルが利用できない（つまり、団体の規模に対してテーブルの席数の確認ができない）［３０：いいえ］場合には（合議体注：構成（Ｈ）の［３０：はい］でない場合）、団体はテーブルが利用可能になるのを待つ場合［３００：はい］、図８．１．３．２（手順３００：テーブルの利用可能性確認後）に特定されるように、団体幹事は自分の情報を入力しなければならず［３２０］、（【０２０９】）（合議体注：以下は、上記構成（Ｉ）〜（Ｎ）と同じであるが、戻るのは図８．１．３．１の［３２０］である）
（Ｑ）いったん入力が完了すると、その団体は待機リストに追加され［３３０］、（【０２０９】） 
（Ｒ）団体のメンバーが携帯機を持たない場合や、持っていても自分の携帯機を使ってメニューの閲覧／事前注文をしない場合は［３８０：いいえ］、テーブルが利用可能になるまで待たなければならず［４００］、テーブルが利用可能になったときに起こる論理は、以下の「利用可能になったテーブル」と題する項目に記述され、（【０２１０】） 
（Ｓ）施設が現金及び現金不要の支払いが可能なシステムを利用している場合［５００：現金＆現金不要支払い］、システムは特別な「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示し［５１０］、次の論理は、以下の「利用可能になったテーブル：来店スリップの確認」と題する項目に記述され、（【０２１２】）
（Ｔ）団体の幹事が来店スリップを持っている場合［５３０：はい］、幹事は自動着席案内または同様のサービスへと進み、自分の団体の来店スリップにあるバーコードをスキャンし［５４０］、システムは、来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し［５５０］、論理は以下の「来店コードを有効にする」と題する項目に続き、（【０２１３】利用可能になったテーブル：来店スリップの確認） 
（Ｕ）システムは、団体の来店コードまたは顧客のアカウントを有効にし［５９０］、論理の流れは、この図の論理に参照を付けた図へと戻る、（【０２１５】来店コードを有効にする）（合議体注：構成（Ｉ）に戻るから、図６．１．１．１の［２５］、構成（Ｂ）に戻る） 
（Ｖ）レストランや食事施設等において、自動座席配置を可能にするシステム。 
　 
（ウ）対比・判断 
　本件発明１について検討する。 
（ウ−１）引用発明の「自動着席案内システム」は、「レストランや食事施設等において、自動座席配置を可能にするシステム」であるから、「席案内装置」である。 
（ウ−２）引用発明の（Ａ）〜（Ｅ）の構成からみて、引用発明は、自動着席案内システムを使っているとき、顧客は専用の着席案内機器または端末を使用して、顧客は団体の人数と喫煙の有無を入力しているから、飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付けているといえ、上記受付のための手段である「飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付部」を有しているといえる。 
（ウ−３）引用発明の（Ｆ）〜（Ｈ）の構成からみて、引用発明は、上記条件受付部で受け付けた条件に適合する座席の有無を確認しており、上記確認のためには、確認時の座席の状態を知る必要があるから、座席の状態を含む座席データを有し、当該座席データを参照して適合する座席を検索していることは明らかであるから、引用発明は、本件発明１の構成（ｂ）を備えている。 
（ウ−４）引用発明の構成（Ｐ）によれば、座席が確保できないとき、構成（Ｉ）〜（Ｎ）の処理を行っている。上記（Ｉ）〜（Ｎ）の構成によれば、顧客はマニュアルで名前を入力し、システムは来店コード及びバーコードの記載されたスリップを顧客及びその団体のために作成し印刷している。上記スリップに印刷されたバーコードは、後に利用可能な座席が生じたとき、当該バーコードをスキャンすることで座席の案内を行っている（構成（Ｔ））から、「前記ユーザの認証用に付与され、ユーザを特定する認証情報」といえ、当該認証情報をスリップに印刷出力しているから、「認証情報を含む予約案内データを出力する予約情報出力部と」を有している。 
（ウ−５）引用発明の構成（Ｐ）、（Ｑ）によれば、構成（Ｐ）の後に「いったん入力が完了すると、その団体は待機リストに追加され」るから、上記予約案内出力の後、団体が待機リストに追加される。 
　構成（Ｒ）を参酌すると、団体が「テーブルが利用可能になるまで待」ち、テーブルが利用可能になったときに起こる論理に移行するとあり、テーブルが利用可能になったときに起こる論理は、構成（Ｓ）ないし（Ｕ）によれば、『「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示し』、『団体の幹事が来店スリップを持っている場合［５３０：はい］、幹事は自動着席案内または同様のサービスへと進み、自分の団体の来店スリップにあるバーコードをスキャンし［５４０］、システムは、来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し』ている。上記の表示やバーコードをスキャンして確認するには、これらの情報が登録されていることが必要であることは明白であるから、構成（Ｑ）で団体が待機リストに追加される際には、これらの情報が登録されることは明らかであり、これらの情報を登録する登録部を有している。そして、登録される「団体の人数」、「バーコード」は、それぞれ、本件発明１の「条件」、「ユーザを特定する認証情報」にそれぞれ対応することは明らかである。もっとも、引用発明は「予約の順番を特定する予約番号」に相当する構成を有していない。 
（ウ−６）引用発明では、構成（Ｑ）でリストに追加された後、構成（Ｒ）にて「テーブルが利用可能になるまで待たなければならず［４００］、テーブルが利用可能になったときに起こる論理」に移行する構成が開示されるのみであるが、上記テーブルが利用可能になったときとは、リストに追加された条件で、団体が希望するテーブルが利用可能になったときであることは明らかであり、そのためには、テーブルの利用状況が変化し、前記座席データが更新されると、更新された前記座席データから、前記予約データとして登録された前記座席の条件に適合する空席の座席を検索していることは明らかであるから、引用発明は、構成（ｅ）を備えているといえる。 
（ウ−７）引用発明の構成（Ｒ）の「利用可能になったテーブル」と題する項目に移行することは、上記（ウ−６）で検討したように「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索」した結果、「利用可能になったテーブル」が生じたことを意味するから、本件発明１の「前記第２検索部で条件に適合する座席が検索されると」に相当する。そして、引用発明の構成（Ｓ）、（Ｔ）によれば、バーコードをスキャンしており、引用発明のスリップは本件発明１の「認証情報」に相当するのであるから、引用発明は、本件発明１の構成（ｆ）を有しているといえる。 
　そして、引用発明では、『バーコードをスキャンし［５４０］、システムは、来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し』との構成を開示するのみであるが、上記スキャンの意味は、構成（Ｓ）にて『「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示し［５１０］』によって表示された団体と、『自分の団体の来店スリップにあるバーコードをスキャンし』の団体とが一致しているか否かを確認し、（スキャンされたバーコードが）正しい前記ユーザ（［５１０］で表示された団体）によって入力されたものと判定していることは明白であり、引用発明は、本件発明１の構成（ｇ）を備えている。 
（ウ−８）本件発明１の第１検索部は、上記（ウ−３）で検討したように、引用発明の（Ｆ）〜（Ｈ）の構成から導き出せる。そして、本件発明１の『前記第１検索部で条件に適合する座席が検索されると』に相当する判断は、引用発明の構成（Ｈ）の『その団体が着席できるテーブルが利用可能な場合には、論理は以下の「すぐに利用可能なテーブル」と題した項目に記述されるように続き』の判断に相当している。 
　このとき、引用発明では、構成（Ｉ）〜（Ｎ）の処理を行っている。そして、構成（Ｎ）では、『テーブルが顧客のために利用可能であるとき［６４０：はい］、自動着席案内機器は顧客の来店スリップにテーブル番号も印刷し［６５０］、テーブルが利用可能であるかどうかにかかわらず［６４０：いいえ］、顧客は作成されたスリップを受け取り［６６０］』の処理を行っているから、「前記第１検索部で検索された座席の情報を案内データとして出力し」ている。 
　また、引用発明の構成（Ｓ）、（Ｔ）において、来店スリップにあるバーコードをスキャンし、（正しいユーザであると判定されれば）来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し［５５０］ているから「前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第２検索部で検索された座席の情報を案内データとして出力」している。 
　もっとも、上記（Ｉ）〜（Ｎ）にてなされる出力と、（Ｓ）、（Ｔ）においてなされる出力は、なされるタイミングが異なるから、これらの出力部が同じかどうかは明らかではない。 
（ウ−９）引用発明では、座席の情報を案内データとして出力したユーザの情報について、そのデータ更新の詳細について特定する構成を備えていない。
（ウ−１０）以上まとめると、本件発明１と引用発明とを対比すると、両者は以下の一致点で一致し、相違点で相違する。 
　 
一致点 
　 
　飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付部と、 
　前記飲食店における各座席の状態を含む座席データを参照し、前記条件受付部で受け付けられた条件に適合する空席の座席を検索する第１検索部と、
　前記第１検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件とを含む予約データを登録する予約登録部と、 
　認証情報を含む予約案内データを出力する予約情報出力部と、 
　前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第２検索部と、 
　前記第２検索部で条件に適合する座席が検索されると、前記ユーザによって入力される認証情報を取得する取得部と、 
　前記取得部が取得した認証情報が、前記予約データが含む認証情報と一致するとき、前記取得部が取得した認証情報は正しい前記ユーザによって入力されたものと判定する認証処理部と、 
　前記第１検索部で条件に適合する座席が検索されると、前記第１検索部で検索された座席の情報を案内データとして出力する案内出力部と、 
　前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第２検索部で検索された座席の情報を案内データとして出力する案内出力部と、 
　を備える席案内装置。 
　 
相違点１ 
　本件発明１の予約登録部に登録される予約データは、「前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データ」であるのに対し、引用発明の予約登録部は「予約の順番を特定する予約番号」の構成を有さず、したがって、「前記予約番号と前記認証情報が関連付けされている」の構成も有していない点。 
　 
相違点２ 
　本件発明１の「予約情報出力部」は、「前記予約登録部が予約データを登録すると、前記予約データで登録された認証情報を含む予約案内データを出力する予約情報出力部」であるのに対し、引用発明では、予約情報を出力した後に予約情報を登録している点。 
　 
相違点３ 
　本件発明１の案内出力部は、「前記第１検索部で条件に適合する座席が検索されると、前記第１検索部で検索された座席の情報を案内データとして出力し、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第２検索部で検索された座席の情報を案内データとして出力する案内出力部」であるのに対し、引用発明では、「前記第１検索部で条件に適合する座席が検索されると、前記第１検索部で検索された座席の情報を案内データとして出力」する案内出力部と「前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第２検索部で検索された座席の情報を案内データとして出力」とが共通であるか明らかではない点。 
　
相違点４
　本件発明１は「前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新部」を備えているのに対し、引用発明は、当該構成を備えていない点。
　 
　事案に鑑み、相違点１について検討する 
　本件発明１の予約番号について発明の詳細な説明には以下のとおり記載されている。 
　 
「予約データ１２２は、予約の順序を特定する予約番号と、予約条件と、ユーザを特定する認証情報とを含むデータである。「予約番号」は、予約を登録する際に付与される。」（【００３０】） 
「図２（ｂ）に示す例では、予約番号「１２３」の予約は、「３名、禁煙席」を予約条件とし、認証情報として「ｕ１」、「ｕ２」及び「ｕ３」が設定されたものである。また、予約番号「１２４」の予約は、「４名、喫煙席」を予約条件とし、認証情報として「ｕ２」、「ｕ４」及び「ｕ５」が設定されたものである。さらに、予約番号「１２５」の予約は、「８名、禁煙席」を予約条件とし、認証情報として「ｕ３」、「ｕ５」及び「ｕ６」が設定されたものである。」（【００３２】） 
「具体的には、第２検索手段１０５は、予約データ１２２から、検索対象の予約条件を特定する。予約データ１２２において複数の予約が登録されているとき、先に登録された予約番号を検索対象として特定する。また、第２検索手段１０５は、検索対象として特定された予約番号の条件に適合する空席の座席を、座席データ１２１から検索する。その後、第２検索手段１０５は、予約データ１２２において、検索対象の予約番号と関連付けられる認証情報を抽出し、検索対象の予約番号と、検索結果で得られた座席番号と、抽出した認証情報とを取得部１１０に出力する。」（【００３９】） 
「取得部１１０は、第２検索手段１０５から予約番号、座席番号及び認証情報（以下、「登録認証情報」とする）が入力されると、ユーザによって入力される認証情報（以下、「入力認証情報」とする）を取得する。また、取得部１１０は、取得した入力認証情報、第２検索手段１０５から入力された座席番号及び登録認証情報を、認証処理部１１１に出力する。 
　例えば、取得部１１０は、ディスプレイ１４に予約番号を含む認証情報入力画面を表示してユーザに座席が空いた旨を通知するとともに認証情報の入力を促し、操作入力装置１３やマイク１７を介してユーザから入力される入力認証情報を取得することができる。また例えば、取得部１１０は、スピーカ１６を介して、入力された予約番号で予約された座席が空いた旨を通知するとともに認証情報の入力を促し、操作入力装置１３を介してユーザから入力される入力認証情報を取得することができる。」（【００４５】、【００４６】） 
　 
　以上の記載からみて、予約番号は、予約データの一部として予約を登録する際に付与され（【００３０】）、「取得部１１０は、ディスプレイ１４に予約番号を含む認証情報入力画面を表示してユーザに座席が空いた旨を通知するとともに認証情報の入力を促」（【００４６】）すから、予約したユーザに対して座席が空いた旨を通知する際に表示される番号であり、該当する予約番号が付与されたユーザの予約の順番が回ってきたかを知らせるための番号であるといえる。 
　これに対して、引用発明では、「システムは特別な「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示」（構成（Ｓ））するのであるから、予約したユーザに対して座席が空いた旨を通知する際に、該当する予約を行ったユーザを特定する情報としては、団体の幹事名を表示している。 
　そして、引用発明では、上記幹事名を表示するため、構成（Ｉ）〜（Ｌ）にあるとおり、幹事の情報を入力することが必須となっている。 
　引用例に記載された発明は、そもそも、 
「食事注文、食事品の準備処理、支払いを促進し、顧客の全体的なレストラン及びその他の飲食サービス施設における体験を改善する」（【０００１】） 
「本発明は、レストラン等の食事施設にて、顧客の為の食事料理注文処理システムを改善することを目的としている。本発明は、特別に設計された端末と、現存のインターネット・アクセス（接続）が可能な携帯機器を利用し、レストラン等の食事施設にて、顧客が従業員の介入なしに、飲料品や食事料理品を無線で注文したり、その支払いができるようにしている。それ故、本発明は、注文処理と支払い処理だけにとどまらず、注文から支払いまでの完全な遂行過程処理を含み、更に、多国言語使用、自動着席案内、事前注文、顧客への報奨ポイント、動的販売、余った在庫販売の促進等の、特別追加企画を含む。」（【００４２】） 
と記載されるとおり、レストラン等の食事施設において、注文処理と支払い処理だけにとどまらず、注文から支払いまでの完全な遂行過程処理の改善を目的とした、全体システムを提供しているのであり、引用例の記載では、例えば【０１０２】、【０１０３】にあるとおり、幹事名もその処理に利用することを前提としているから、引用例に記載された発明から、引用発明を抽出しても、「幹事名」の入力を省略することはできない。 
　したがって、引用発明において「該当する予約を行ったユーザを特定する情報として、団体の幹事名をしている」構成を、本件発明１のように予約番号とすることはできない。 
　異議申立人大薮朋子は、令和１年１２月２３日付け意見書にて、予約を特定するための情報として「予約の順番を特定する予約番号」を利用することは周知であるとして、甲第１０号証ないし甲第１４号証を新たに提示しているが、上記のとおり、引用発明において団体の幹事名を用いる構成を他の構成に変えることについて阻害要因があるから、仮に異議申立人大薮朋子の述べるように、予約を特定するための情報として「予約の順番を特定する予約番号」を利用することは周知であったとしても、引用発明に当該周知の事項を適用することはできない。 
　 
　なお、引用発明では、顧客を特定する情報として、バーコードの他に「来店コード」も生成している（構成Ｍ）。上記「来店コード」について、引用例の発明の詳細な説明を参酌すると、以下の記載がある。 
　 
「団体幹事の名前と来店コード（下参照）は注文システムにログインする安全な手段として一緒に使われている。」（【００９６】） 
「「来店コード」はアットランダムに作られるコードで、数字と文字によって成り立ち、団体が店にいる間、団体を識別するために用いられる。この来店コードは発行からその顧客の団体がログアウトし、勘定が支払われるまで有効である。つまり、来店コードは顧客が注文を入れる前に実際に店の中にいるということを確実にするための安全装置の役割をも果たす。これは現金支払いを食事の後に顧客から受けつける店において注文が携帯機器を用いて行われる場合に非常に重要である。もしなんらかの、団体が店で注文をしている間にのみ有効なアットランダムに作られたコードがなければ、誰かレストランの外にいる者が自分の携帯機器を使って悪ふざけで注文を入れるということも可能であるからである。更に、来店コードは顧客にテーブルが与えられて初めて使えるようになる。」（【００９７】） 
　 
　すなわち、団体を識別するための番号であって、アットランダムに作られるコードであるから本件発明１の予約番号とは異なるものである。 
　 
　よって、相違点２ないし相違点４について検討するまでもなく、本件請求項１に係る発明は、引用例が開示する発明から、当業者が容易に想到し得るものとはいえない。 
  
イ　訂正後の請求項２〜請求項１１について 
　訂正後の請求項２〜５、７〜９に係る特許は、請求項１の記載を引用して更に限定する構成を付加した発明であるから、本件発明１と同様の相違点を有し、上記アに示した理由と同様の理由により、引用例が開示する発明から、当業者が容易に想到し得るものとはいえない。 
　また、訂正後の請求項１０に係る特許は、本件発明１の「席案内装置」の発明を「席案内プログラム」とカテゴリを変えた発明であり、訂正後の請求項１１に係る特許は、本件発明１の「席案内装置」の発明を「席案内方法」とカテゴリを変えた発明であるから、実質的に本件発明１と同様の相違点１を含む発明であり、上記アに示した理由と同様の理由により、引用例が開示する発明から、当業者が容易に想到し得るものとはいえない。 
　訂正後の請求項６に係る特許は、上記訂正により削除されたから、取消理由の対象が存在しないものとなった。 
　 
ウ　以上のとおりであるから、取消理由（ア）は解消した。 
  
第５　取消理由通知において採用しなかった特許異議申立理由について 
１　申立理由１（申立０１）について 
　申立理由１の主引用例である１甲１の記載（段落【００２８】〜【００３７】、【００６２】、図７、図８、図１２）によれば、１甲１に記載されたシステムにおいては、座席予約ファイル３５２への登録は、名前、人数、禁煙喫煙の別を順次タッチ入力する毎にそれぞれの項目毎に行われており、「予約登録」に先立って「飲食店における各座席の状態を含む座席データを参照」して「ユーザ」（顧客）が「入力」した「希望の座席の条件」に「適合する空席の座席を検索」する「第１検索部」を備え、「第１検索部で条件に適合する座席が検索されないとき」に「予約データを登録する」ものでなく、かつ、座席予約ファイルに登録された内容に従って接客係の店員が用いるハンディターミナルに案内データを出力するのであって、「第１検索部で条件に適合する座席が検索されると、前記第１検索部で検索された座席の情報を案内データとして出力する」ものでない。この点は、本件発明１〜５、７〜１１のいずれと対比しても、相違点となる。 
　そして、１甲１においては、座席予約ファイル３５２への登録がなされない顧客は、いわば、ハンディターミナルを用いる接客係の店員が既に案内した顧客なのであって、改めて案内データをハンディターミナルに出力する必要がない。このことを踏まえれば、１甲１には、上記相違点を容易想到であるというために必要となる動機付けはなく、むしろ、阻害事由があるというべきである。 
　申立０１の申立人は、上記相違点を一致点と主張している。しかし、上記のとおりこの点は相違点であり、この主張を採用することはできない。 
  
２　申立理由３−２（申立０３）について 
　申立理由３−２の主引用例である３甲２の記載（段落【００２６】〜【００３２】、【００３６】〜【００４０】、図３、図６、図８）によれば、３甲２に記載されたシステムにおいては、予約管理テーブル１３２への登録は、所定の期間毎に予約受付画面に表示されて予約内容に対応する２次元コードが示すメールアドレスへのメール送信によって行われており、「予約登録」に先立って「飲食店における各座席の状態を含む座席データを参照」して「ユーザ」（顧客）が「入力」した「希望の座席の条件」に「適合する空席の座席を検索」する「第１検索部」を備えて「第１検索部で条件に適合する座席が検索されないとき」に「予約データを登録する」ものでなく、かつ、予約管理テーブルに登録された内容に従ってオペレータの操作により又は自動的に案内メールを作成して送信するのであって、「第１検索部で条件に適合する座席が検索されると、前記第１検索部で検索された座席の情報を案内データとして出力する」ものでない。この点は、本件発明１〜５、７〜１１のいずれと対比しても、相違点となる。 
　そして、３甲２においては、予約管理テーブル１３２への登録がなされない顧客は、そもそも予約受付画面に表示された２次元コードの読み込みを行っておらず、案内メールが送信されることがないし、その必要もない。このことを踏まえれば、３甲２には、上記相違点を容易想到であるというために必要となる動機付けはなく、むしろ、阻害事由があるというべきである。 
　申立０３の申立人は、上記相違点を相違点とした上で、相違点に対応する構成が周知技術である等と主張している。しかし、仮にこれが周知技術であるとしても、上記のとおり相違点について容易想到ということはできないから、この主張を採用することはできない。
  
第６　むすび 
　以上のとおりであるから、取消理由通知に記載した取消理由及び特許異議申立書に記載した特許異議申立理由によっては、本件請求項１〜５、７〜１１に係る特許を取り消すことはできない。
　また、他に本件請求項１〜５に、７〜１１に係る特許を取り消すべき理由を発見しない。
　請求項６に係る特許は、訂正により削除されることにより、申立ての対象が存在しないものとなるため、特許法第１２０条の８第１項で準用する同法第１３５条の規定により却下する。 
　よって、結論のとおり、決定する。
【異議決定日】
令和２年８月２６日（２０２０．８．２６）
【訂正の要旨】
審決（決定）の【理由】欄参照。
（５７）【特許請求の範囲】
　【請求項１】
　飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付部と、
　前記飲食店における各座席の状態を含む座席データを参照し、前記条件受付部で受け付けられた条件に適合する空席の座席を検索する第１検索部と、
　前記第１検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され
、ユーザを特定する
、
、予約の順番を特定する予約番号と
み、前記予約番号と前記認証情報が関連付けされている、
　前記予約登録部が予約データを登録すると、前記予約データで登録された認証情報を含む予約案内データを出力する予約情報出力部と、
　前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され
、前記座席の
　前記第２検索部で条件に適合する座席が検索されると、前記ユーザによって入力される認証情報を取得する取得部と、
　前記取得部が取得した認証情報が、前記予約データが含む認証情報と一致するとき、前記取得部が取得した認証情報は正しい前記ユーザによって入力されたものと判定する認証処理部と、
　前記第１検索部で条件に適合する座席が検索されると、前記第１検索部で検索された座席の情報を案内データとして出力し、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第２検索部で検索された座席の情報を案内データとして出力する案内出力部と、
　
前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新部と、
　を備える席案内装置。
　【請求項２】
　前記案内出力部が案内データを出力すると、前記案内データで前記ユーザに案内した座席の状態を着席に変更して前記座席データを更新する座席データ更新部をさらに備える、
　請求項１に記載の席案内装置。
　【請求項３】
　
前記予約データ更新部は、
　前記案内出力部が前記第２検索部で検索された座席の情報を案内データとして出力すると、案内データを提供した前記ユーザの認証情報と条件を削除して前記予約データを更新す
る
　請求項１又は２に記載の席案内装置。
　【請求項４】
　前記座席データの更新を検出し、座席データの更新を前記第２検索部に通知する検出部をさらに備える、
　請求項１乃至３のいずれか１項に記載の席案内装置。
　【請求項５】
　前記予約登録部は、予約の順序を特定する予約番号を含む予約データを登録し、
　前記第２検索部は、前記予約データが含む予約番号で先に予約が登録されたことが特定される条件の座席を検索対象とする
　請求項１乃至４のいずれか１項に記載の席案内装置。
　【請求項６】
　
（削除）　
　【請求項７】
　前記予約情報出力部は、予約情報を予約用紙に印刷する、予約情報を含む電子データを前記ユーザの端末に送信する、または、予約情報を含む表示画面をディスプレイに表示する
　請求項１乃至
５
　【請求項８】
　前記案内出力部は、案内データを案内用紙に印刷する、案内情報を含む電子データを前記ユーザの端末に送信する、案内情報を含む表示画面をディスプレイに表示する、または、案内情報を含む音声データをスピーカから出力する
　請求項１乃至
５、
　【請求項９】
　前記案内データの前記座席の情報とは、前記飲食店における当該座席の座席番号である
　請求項１乃至
５、７、
　【請求項１０】
　席案内装置のコンピュータに、
　飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付機能と、
　前記飲食店における各座席の状態を含む座席データを参照し、前記条件受付機能で受け付けられた条件に適合する空席の座席を検索する第１検索機能と、
　前記第１検索機能で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され
、ユーザを特定する
、
、予約の順番を特定する予約番号と
み、前記予約番号と前記認証情報が関連付けされている、
　前記予約登録機能が予約データを登録すると、前記予約データで登録された認証情報を含む予約案内データを出力する予約情報出力機能と、
　前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され
、前記座席の
　前記第２検索機能で条件に適合する座席が検索されると、前記ユーザによって入力される認証情報を取得する取得機能と、
　前記取得機能が取得した認証情報が、前記予約データが含む認証情報と一致するとき、前記取得機能が取得した認証情報は正しい前記ユーザによって入力されたものと判定する認証処理機能と、
　前記第１検索機能で条件に適合する座席が検索されると、前記第１検索機能で検索された座席の情報を案内データとして出力し、前記認証処理機能で正しい前記ユーザによって入力されたものと認証されると、前記第２検索機能で検索された座席の情報を案内データとして出力する案内出力機能と、
　
前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新機能と、
　して機能させる席案内プログラム。
　【請求項１１】
　コンピュータが実行する席案内方法であって、
　飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付ステップと、
　前記飲食店における各座席の状態を含む座席データを参照し、前記条件受付ステップで受け付けられた条件に適合する空席の座席を検索する第１検索ステップと、
　前記第１検索ステップで条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され
、ユーザを特定する
、
、予約の順番を特定する予約番号と
み、前記予約番号と前記認証情報が関連付けされている、
　前記予約登録ステップで予約データが登録されると、前記予約データで登録された認証情報を含む予約案内データを出力する予約情報出力ステップと、
　前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され
、前記座席の
　前記第２検索ステップで条件に適合する座席が検索されると、前記ユーザによって入力される認証情報を取得する取得ステップと、
　前記取得ステップが取得した認証情報が、前記予約データが含む認証情報と一致するとき、前記取得ステップが取得した認証情報は正しい前記ユーザによって入力されたものと判定する認証処理ステップと、
　前記第１検索ステップで条件に適合する座席が検索されると、前記第１検索ステップで検索された座席の情報を案内データとして出力し、前記認証処理ステップで正しい前記ユーザによって入力されたものと認証されると、前記第２検索ステップで検索された座席の情報を案内データとして出力する案内出力ステップと、
　
前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新ステップと、
　を有する席案内方法。