異議の決定｜異議2018-701047 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判全部申し立て特29条の2 G06Q 審判全部申し立て 2項進歩性 G06Q 審判全部申し立て特36条6項1、2号及び3号請求の範囲の記載不備 G06Q
管理番号	1368057
異議申立番号	異議2018-701047
総通号数	252
発行国	日本国特許庁(JP)
公報種別	特許決定公報
発行日	2020-12-25
種別	異議の決定
異議申立日	2018-12-25
確定日	2020-09-04
異議申立件数	3
訂正明細書	有
事件の表示	特許第6401741号発明「席案内装置、席案内プログラム及び席案内方法」の特許異議申立事件について、次のとおり決定する。
結論	特許第6401741号の特許請求の範囲を訂正請求書(令和2年5月28日付け)に添付された特許請求の範囲のとおり、訂正後の請求項〔1-9〕、10、11について訂正することを認める。特許第6401741号の請求項1ないし5、7ないし11に係る特許を維持する。特許第6401741号の請求項6に係る特許についての特許異議の申立てを却下する。
理由	第1 手続の経緯ア経緯特許第6401741号の請求項1ないし11に係る特許についての出願は、平成28年6月14日に特許出願され、平成30年9月14日にその特許権の設定登録がされ、平成30年10月10日に特許掲載公報が発行された。その後、本件特許に対して3の特許異議の申立てがあり、次のとおりに手続が行われた。平成30年12月25日 :特許異議申立人加藤隆登による請求項1ないし4、7ないし11に係る特許に対する異議の申し立て(以下、「申立01」という。) 平成31年 1月23日 :特許異議申立人大薮朋子による請求項1ないし4、7ないし11に係る特許に対する異議の申し立て(同「申立02」) 平成31年 4月 9日 :特許異議申立人野中啓孝による請求項1ないし11に係る特許に対する異議の申し立て(同「申立03」) 令和元年 8月 1日付け:取消理由通知書令和元年10月24日 :特許権者による意見書の提出及び訂正請求令和元年12月16日 :特許異議申立人野中啓孝による意見書の提出令和元年12月23日 :特許異議申立人大薮朋子による意見書の提出 (特許異議申立人加藤隆登からは、令和元年10月24日の訂正請求に対して意見書は提出されていない。) 令和 2年 2月26日付け:取消理由通知書(決定の予告) 令和 2年 5月28日 :特許権者による意見書の提出及び訂正請求 (令和元年10月24日の訂正請求は取下げられたものとみなされた。) 令和 2年 6月22日 :特許異議申立人野中啓孝による意見書の提出 (特許異議申立人加藤隆登、同大薮朋子からは、令和2年5月28日の訂正請求に対して意見書は提出されていない。) イ申立の概要 (イ-1)異議申立人加藤隆登による異議申立の理由は、おおむね以下のとおりである。主たる証拠として以下の甲第1号証を及び従たる証拠として以下の甲第2号証?甲第4号証を提出し、請求項1ないし4、7ないし11に係る特許は、特許法第29条第2項の規定に違反してされたものであるから、上記請求項に係る特許を取り消すべきものである(以下、申立理由1という。)。(以下、異議申立人加藤隆登の提出した甲第1号証ないし甲第4号証は他の異議申立人の提出した証拠と区別するため、それぞれ、1甲1、1甲2等と記載する。) 1甲1:特開2007-164654号公報(甲第1号証) 1甲2:特開2004-199411号公報(甲第2号証) 1甲3:特開2008-250711号公報(甲第3号証) 1甲4:特開2004-199412号公報(甲第4号証) (イ-2)異議申立人大薮朋子による異議申立の理由は、おおむね以下のとおりである。主たる証拠として以下の甲第1号証を提出し、請求項1ないし4、7ないし11に係る特許は、特許法第29条第1項の規定に違反してされたものであるから、上記請求項に係る特許を取り消すべきものである(以下、申立理由2-1という)、および、主たる証拠として以下の甲第1号証及び従たる証拠として以下の甲第2号証?甲第9号証を提出し、請求項1ないし4、7ないし11に係る特許は、特許法第29条第2項の規定に違反してされたものであるから、上記請求項に係る特許を取り消すべきものである(以下、申立理由2-2という)。(以下、異議申立人大薮朋子の提出した甲第1号証ないし甲9号証は他の異議申立人の提出した証拠と区別するため、それぞれ、2甲1、2甲2等と記載する。) 2甲1:特表2005-527017号公報(甲第1号証) 2甲2:特開2008-77528号公報(甲第2号証) 2甲3:特開2002-311170号公報(甲第3号証) 2甲4:特開2002-279262号公報(甲第4号証) 2甲5:特開2009-199299号公報(甲第5号証) 2甲6:特開2009-122769号公報(甲第6号証) 2甲7:特開2003-271767号公報(甲第7号証) 2甲8:特開2002-140767号公報(甲第8号証) 2甲9:特開2000-123258号公報(甲第9号証) (イ-3)異議申立人野中啓孝による異議申立の理由は、おおむね以下のとおりである。証拠として以下の甲第1号証を提出し、請求項1ないし5、7ないし11に係る特許は、特許法第29条の2の規定に違反してされたものであるから、上記請求項に係る特許を取り消すべきものである(以下、申立理由3-1という)、および、主たる証拠として以下の甲第2号証及び従たる証拠として以下の甲第3号証?甲第6号証を提出し、請求項1ないし11に係る特許は、特許法第29条第2項の規定に違反してされたものであるから、上記請求項に係る特許を取り消すべきものである(以下、申立理由3-2という)。(以下、異議申立人野中啓孝の提出した甲第1号証ないし甲6号証は他の異議申立人の提出した証拠と区別するため、それぞれ、3甲1、3甲2等と記載する。) 3甲1:特願2015-156848号(特開2017-37384号公報)(甲第1号証) 3甲2:特開2008-77528号公報(甲第2号証) 3甲3:特開2003-296423号公報(甲第3号証) 3甲4:特開平9-245262号公報(甲第4号証) 3甲5:特開2000-207469号公報(甲第5号証) 3甲6:特開2003-167972号公報(甲第6号証) 第2 訂正の適否についての判断 (1)訂正の内容令和2年5月28日の訂正請求による訂正の内容は以下のアないしキのとおりである。ア訂正事項1 特許請求の範囲の請求項1の「前記第1検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与された認証情報と前記条件とを含む予約データを登録する予約登録部と」の記載を「前記第1検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録部と」の記載と訂正する。イ訂正事項2 特許請求の範囲の請求項1の「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され条件に適合する空席の座席を検索する第2検索部と」の記載を「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第2検索部と」の記載と訂正する。ウ訂正事項3 特許請求の範囲の請求項1の「前記第1検索部で条件に適合する座席が検索されると、前記第1検索部で検索された座席の情報を案内データとして出力し、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第2検索部で検索された座席の情報を案内データとして出力する案内出力部と、を備える席案内装置。」の記載を「前記第1検索部で条件に適合する座席が検索されると、前記第1検索部で検索された座席の情報を案内データとして出力し、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第2検索部で検索された座席の情報を案内データとして出力する案内出力部と、前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新部と、を備える席案内装置。」の記載と訂正する。エ訂正事項4 特許請求の範囲の請求項3の「前記案内出力部が前記第2検索部で検索された座席の情報を案内データとして出力すると」の記載を「前記予約データ更新部は、前記案内出力部が前記第2検索部で検索された座席の情報を案内データとして出力すると」の記載と訂正する。オ訂正事項5 特許請求の範囲の請求項3の「案内データを提供した前記ユーザの認証情報と条件を削除して前記予約データを更新する予約データ更新部をさらに備える」の記載を「案内データを提供した前記ユーザの認証情報と条件を削除して前記予約データを更新する」の記載と訂正する。カ訂正事項6 特許請求の範囲の請求項6を削除する。キ訂正事項7 特許請求の範囲の請求項7の「請求項1乃至6のいずれか1項に記載の席案内装置。」の記載を「請求項1乃至5のいずれか1項に記載の席案内装置。」の記載と訂正する。ク訂正事項8 特許請求の範囲の請求項8の「請求項1乃至7のいずれか1項に記載の席案内装置。」の記載を「請求項1乃至5、7のいずれか1項に記載の席案内装置。」の記載と訂正する。ケ訂正事項9 特許請求の範囲の請求項9の「請求項1乃至8のいずれか1項に記載の席案内装置。」の記載を「請求項1乃至5、7、8のいずれか1項に記載の席案内装置。」の記載と訂正する。コ訂正事項10 特許請求の範囲の請求項10の「前記第1検索機能で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与された認証情報と前記条件とを含む予約データを登録する予約登録機能と」の記載を「前記第1検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録機能と」の記載と訂正する。サ訂正事項11 特許請求の範囲の請求項10の「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され条件に適合する空席の座席を検索する第2検索機能と」の記載を「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第2検索機能と」の記載と訂正する。シ訂正事項12 特許請求の範囲の請求項10の「前記第1検索機能で条件に適合する座席が検索されると、前記第1検索機能で検索された座席の情報を案内データとして出力し、前記認証処理機能で正しい前記ユーザによって入力されたものと認証されると、前記第2検索機能で検索された座席の情報を案内データとして出力する案内出力機能と、して機能させる席案内プログラム。」の記載を「前記第1検索機能で条件に適合する座席が検索されると、前記第1検索機能で検索された座席の情報を案内データとして出力し、前記認証処理機能で正しい前記ユーザによって入力されたものと認証されると、前記第2検索機能で検索された座席の情報を案内データとして出力する案内出力機能と、前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新機能と、して機能させる席案内プログラム。」の記載と訂正する。ス訂正事項13 特許請求の範囲の請求項11の「前記第1検索ステップで条件に適合する座席が検索されないとき、前記ユーザの認証用に付与された認証情報と前記条件とを含む予約データを登録する予約登録ステップと」の記載を「前記第1検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録ステップと」の記載と訂正する。セ訂正事項14 特許請求の範囲の請求項11の「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され条件に適合する空席の座席を検索する第2検索ステップと」の記載を「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第2検索ステップと」の記載と訂正する。ソ訂正事項15 特許請求の範囲の請求項11の「前記第1検索ステップで条件に適合する座席が検索されると、前記第1検索ステップで検索された座席の情報を案内データとして出力し、前記認証処理ステップで正しい前記ユーザによって入力されたものと認証されると、前記第2検索ステップで検索された座席の情報を案内データとして出力する案内出力ステップと、を有する席案内方法。」の記載を「前記第1検索ステップで条件に適合する座席が検索されると、前記第1検索ステップで検索された座席の情報を案内データとして出力し、前記認証処理ステップで正しい前記ユーザによって入力されたものと認証されると、前記第2検索ステップで検索された座席の情報を案内データとして出力する案内出力ステップと、前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新ステップと、を有する席案内方法。」の記載と訂正する。なお、訂正前の請求項1?9は、請求項2ないし9が、訂正の請求の対象である請求項1の記載を引用する関係にあるから、本件訂正は、一群の請求項〔1?9〕、及び請求項10、請求項11について請求されている。 (2)訂正の目的の適否、新規事項の有無、特許請求の範囲の拡張・変更の存否ア訂正事項1、訂正事項10、訂正事項13 訂正事項1に係る請求項1についての訂正は、予約登録部が登録する予約データについて、訂正前は「前記ユーザの認証用に付与された認証情報と前記条件とを含む予約データ」と特定されていたのに対し、訂正後は、上記「認証情報」と「前記条件」に加えて「予約番号」を含む構成とし、加えて予約番号と認証情報が関連付けられていることをさらに特定しているから特許請求の範囲の減縮を目的とするものである。そして、当該構成は発明の詳細な説明の【0030】に「予約データ122は、予約の順序を特定する予約番号と、予約条件と、ユーザを特定する認証情報とを含むデータである。「予約番号」は、予約を登録する際に付与される。」との記載が、【0039】に「その後、第2検索手段105は、予約データ122において、検索対象の予約番号と関連付けられる認証情報を抽出し、検索対象の予約番号と、検索結果で得られた座席番号と、抽出した認証情報とを取得部110に出力する。」との記載があるから、新規事項の追加に該当しない。また、上記訂正により実質上特許請求の範囲を拡張し、又は変更するものでもない。訂正事項1が「座席案内装置」の予約登録部が登録するデータに関する訂正であるのに対し、訂正事項10は「座席案内プログラム」の予約登録機能において登録されるデータについて、訂正事項1と同様の訂正を行うものであり、また、訂正事項13は「座席案内方法」の予約登録ステップにおいて登録されるデータについて、訂正事項1と同様の訂正を行うものであるから、訂正事項10及び訂正事項13は、訂正事項1と同様特許請求の範囲の減縮を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。イ訂正事項2、訂正事項11、訂正事項14 訂正事項2に係る請求項1についての訂正は、訂正前の「前記予約データで登録され条件に適合する空席の座席を検索する第2検索部」の記載では、「前記予約データで登録され」と「条件に適合する空席の座席を検索する第2検索部」の係り受けが不明であり、「条件」がどのように特定されているか明確ではない記載であったのに対し、「前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第2検索部」との記載とすることで、「条件」は、「前記座席の条件」すなわち、「飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付部」と特定される条件受付部で受け付け、「前記予約データで登録され」た、すなわち、「前記第1検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録部」(訂正後)と特定される予約登録部で登録された条件であることが明確となったから、明瞭でない記載の釈明を目的とするものである。そして、当該構成は発明の詳細な説明に、「条件受付部102は、飲食店で空席の座席を求める来店者(以下、「ユーザ」とする)によって入力される希望の座席の条件を受け付ける。また、条件受付部102は、座席の条件を、検索部103に出力する。」(【0035】) 「検索部103は、ユーザの希望する条件に適合する空席の座席を検索する第1検索手段104及び第2検索手段105を備える。」(【0036】) 「第1検索手段104は、条件受付部102から条件が入力されると、記憶装置12が記憶する座席データ121を参照し、条件受付部102で受付された条件に適合する空席の座席を検索する。また、第1検索手段104は、検索された座席の番号を案内出力部112に出力する。条件に適合する座席がないとき、第1検索手段104は、座席の条件を認証情報生成部106に出力する。」(【0037】) 「認証情報生成部106は、第1検索手段104から条件が入力されると、ユーザを特定する認証情報を設定する。また、認証情報生成部106は、設定した認証情報を、入力された条件とともに予約登録部107に出力する。」(【0041】) 「予約登録部107は、認証情報生成部106から条件及び認証情報が入力されると、入力された条件及び認証情報を予約の順序を特定する予約番号とともに、予約データ122として記憶装置12に登録する。」(【0042】) の記載があるから、新規事項の追加に該当しない。また、上記訂正により実質上特許請求の範囲を拡張し、又は変更するものでもない。訂正事項2が「座席案内装置」の第2検索部が座席を検索する条件に関する訂正であるのに対し、訂正事項11は「座席案内プログラム」の第2検索機能機能において検索されるデータについて、訂正事項2と同様の訂正を行うものであり、また、訂正事項14は「座席案内方法」の第2検索ステップにおいて検索されるデータについて、訂正事項2と同様の訂正を行うものであるから、訂正事項11及び訂正事項14は、訂正事項2と同様、明瞭でない記載の釈明を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。ウ訂正事項3、訂正事項12、訂正事項15 訂正事項3に係る請求項1についての訂正は、訂正前の請求項1の座席案内装置に対して、さらに「前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新部」の構成を付加するものであるから特許請求の範囲の減縮を目的とするものである。そして、当該構成は、訂正前の請求項3に「前記案内出力部が前記第2検索部で検索された座席の情報を案内データとして出力すると、案内データを提供した前記ユーザの認証情報と条件を削除して前記予約データを更新する予約データ更新部をさらに備える」の記載があり、また、発明の詳細な説明に「予約データ更新部114は、案内出力部112が第2検索手段105で検索された座席の情報を案内データとして出力すると、案内データを提供したユーザの認証情報と条件を削除して記憶装置12が記憶する予約データ122を更新する。」(【0051】)、「また、席案内装置1は、記憶装置12が記憶する予約データ122を更新する(S13)。」(【0068】)等の記載があるから、新規事項の追加に該当しない。また、上記訂正により実質上特許請求の範囲を拡張し、又は変更するものでもない。訂正事項3が「座席案内装置」に予約データ更新部を付加する訂正であるのに対し、訂正事項12は「座席案内プログラム」の予約データ更新機能を付加する、訂正事項1と同様の訂正を行うものであり、また、訂正事項15は「座席案内方法」の予約データ更新ステップを付加する、訂正事項1と同様の訂正を行うものであるから、訂正事項12及び訂正事項15は、訂正事項1と同様特許請求の範囲の減縮を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。エ訂正事項4、訂正事項5 訂正事項4、訂正事項5に係る請求項3についての訂正は、訂正事項3において、訂正前請求項3の構成が有していた一部の構成を請求項1に付加したため、請求項1の記載を引用する請求項3の記載が、訂正後の請求項1の記載と矛盾しないように訂正するものである。したがって、訂正事項4、訂正事項5に係る訂正は、明瞭でない記載の釈明を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。オ訂正事項6ないし訂正事項9 訂正事項6に係る訂正は、特許請求の範囲の請求項6を削除する訂正であるから、特許請求の範囲の減縮を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。また、訂正事項7ないし訂正事項9は、訂正前、請求項6の記載を引用する請求項7ないし請求項9の記載について、訂正事項6により請求項6が削除されたことにより、それぞれ、請求項6の記載の引用を削除する訂正であり、明瞭でない記載の釈明を目的とするものであり、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。 (3)小括上記のとおり、訂正事項1ないし15に係る訂正は、特許法第120条の5第2項ただし書第1号又は第3号に掲げる事項を目的とするものであり、かつ、同条第9項で準用する同法第126条第5項及び第6項の規定に適合する。したがって、特許請求の範囲を、訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項[1?9]、10、11について訂正することを認める。第3 取消理由(令和2年2月26日付け)の概要訂正(令和2年5月28日)前の請求項1、2、4、5、7?11に係る特許に対して、当審が令和2年2月26日に特許権者に通知した取消理由の要旨は、次のとおりである。請求項1、2、4、5、7?11に係る発明は、特願2015-156848号(先願、特開2017-37384号公報/3甲1)の願書に最初に添付された明細書、特許請求の範囲又は図面に記載された発明と同一である。よって、請求項1、2、4、5、7?11に係る特許は、特許法第29の2の規定に違反してされたものであり、取り消されるべきものである。第4 当審の判断 1 訂正後の本件請求項1に係る特許 (1)本件発明1について上記訂正後の請求項1に係る発明(以下「本件発明1」という。)は、以下のとおりである。((a)?(j)は当審で付与した。) 【請求項1】 (a)飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付部と、 (b)前記飲食店における各座席の状態を含む座席データを参照し、前記条件受付部で受け付けられた条件に適合する空席の座席を検索する第1検索部と、 (c)前記第1検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録部と、 (d)前記予約登録部が予約データを登録すると、前記予約データで登録された認証情報を含む予約案内データを出力する予約情報出力部と、 (e)前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第2検索部と、 (f)前記第2検索部で条件に適合する座席が検索されると、前記ユーザによって入力される認証情報を取得する取得部と、 (g)前記取得部が取得した認証情報が、前記予約データが含む認証情報と一致するとき、前記取得部が取得した認証情報は正しい前記ユーザによって入力されたものと判定する認証処理部と、 (h)前記第1検索部で条件に適合する座席が検索されると、前記第1検索部で検索された座席の情報を案内データとして出力し、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第2検索部で検索された座席の情報を案内データとして出力する案内出力部と、 (i)前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新部と、 (j)を備える席案内装置。 (2)先願明細書の記載・引用発明(先願) 上記先願明細書には以下のとおりの記載がある。【0013】以下、この発明の実施の形態を添付図面に基づいて説明する。実施の形態1. 図1に、本発明の実施の形態1に係る空き設備管理システム100を含む構成の例を示す。空き設備管理システム100は、設備の占有状況、すなわち設備が使用中であるか空いているかを表す情報を管理する。本実施形態では、設備の例としてフードコート等に設置される卓40を管理対象とする。【0014】空き設備管理システム100は、制御装置10と、受付装置20と、複数のポケットベル23(待機者用受信機)と、調理指示端末30と、複数の客席端末41(設備端末)とを備える。また、空き設備管理システム100は、状況表示ランプ42(設備状態表示装置)および座席50を備える。この状況表示ランプ42および座席50は、卓40のそれぞれに関連して設けられる。【0038】図7は、空き設備管理システム100が所定の卓要求操作を受け付けた場合に実行する動作の流れの例を示す。制御装置10は、卓要求操作(設備要求操作)を受け付ける(ステップS11)。卓要求操作とは、上述のように、新たな顧客が卓の割り当てを要求する操作である。この操作は、制御装置10が受付端末21を介して受け付けてもよい。ここで制御装置10は、卓要求操作を表す受付番号を決定する。【0039】図8に、この卓要求操作の受け付けに関連して表示される画面の例を示す。卓要求操作は、対応する卓(または卓の集合)を特定するものであってもよい。たとえば図8の例では、顧客は、所定のボタンを選択して操作することにより、卓要求操作に対応して希望する卓の集合を指定することができる。たとえば顧客が第1エリアを選択した場合には、第1エリアに配置された卓(図4の例では卓番号A001?A003等の卓)に対応する卓要求操作が受け付けられることになる。【0040】次に、制御装置10は、受け付けた卓要求操作に対応する卓のいずれかが空いているか否かを判定する(ステップS12)。この判定は、たとえば卓状況DB73において利用状況が「空き」となっているか否かに基づいて行われる。【0041】対応する卓のいずれかが空いている場合には、制御装置10は、処理中の卓要求操作を表す受付番号に対応する行を受付管理DB72に追加する(ステップS13)。ここで追加される行は、受付番号と、受付時刻(たとえばステップS11が実行された時刻)と、希望エリア(たとえばステップS11において選択された領域)と、受付時点で空きが存在していたことを示す情報とを含む。【0042】次に、制御装置10は、顧客に利用させるべき卓を決定する(ステップS14)。たとえば、卓要求操作に対応する卓のうちから、所定の基準(たとえば最も長時間空いているもの等)に基づいて1つの卓を選択する。【0043】次に、制御装置10は、ステップS14で決定された卓がもはや空いていないことを示すよう、卓状況DB73において利用状況を更新する(ステップS15)。たとえば利用状況を「着席待ち」に変更する。ここで、制御装置10はさらに、卓状況DB73において、その卓に、受付番号および受付時刻を関連付けて記憶する。【0044】次に、制御装置10は、ステップS14で決定された卓に設置された状況表示ランプ42を所定の状態に変更させる(たとえば青色で点灯させる)(ステップS16)。ただしステップS16は省略可能である。その場合には状況表示ランプ42の状態は変更されない。【0045】次に、制御装置10は、その卓を特定する案内情報を出力することにより、顧客に対して案内を行う(ステップS17)。案内情報はたとえば受付端末21に送信され、受付端末21において表示される。案内情報は、本実施形態では地図の表示を含む。地図は、たとえば所定の領域(客席エリアA2等)においてステップS14で決定された卓に対応する位置にマーク表示を付した画像である。【0046】図9に、この案内表示に関連して表示される画面の例を示す。案内表示は、地図の他に、たとえば、卓が空いていたことまたは卓を確保したことを示すメッセージと、受付番号と、着席後に所定の着席操作を行うこと(たとえば客席端末41から受付番号を入力すること)を促すメッセージとを含む。【0047】ここで、顧客は案内表示に従って決定された卓に移動し、その卓の客席端末41において着席操作を行うことになる。本実施形態では、顧客は受付番号を入力する。図10は、着席操作に関連して表示される画面の例を示す。顧客は数字を表すボタンを操作することにより受付番号を入力することができる。【0048】客席端末41は、この着席操作を受け付け(ステップS18)、着席操作が行われたことを示す着席通知を制御装置10に送信する(ステップS19)。着席通知は、その着席通知を送信する客席端末41自身の卓番号を含む。また、本実施形態では、着席通知は、着席操作に関連して入力された受付番号を含む。【0049】とくに図示しないが、制御装置10は、卓状況DB73を参照し、受信した着席通知に含まれる卓番号に関連付けられた受付番号と、受信した着席通知に含まれる受付番号とが一致するか否かを判定してもよく、一致しない場合にはエラー表示を行った後に処理をステップS18に戻してもよい。【0050】制御装置10は、着席通知を受信することに応じて、卓状況DB73においてその卓の利用状況を「利用中」に変更する(ステップS20)。ここで、制御装置10はさらに、卓状況DB73において、その卓に、着席時刻(たとえばステップS19が実行された時刻)を関連付けて記憶する。次に、制御装置10は、その卓に設置された状況表示ランプ42を所定の状態に変更させる(たとえば赤色に点灯させる)(ステップS21)。【0051】ステップS12において、卓要求操作に対応する卓がいずれも空いていない場合には、制御装置10は、その顧客に対してポケットベル23を供給する(ステップS22)。ポケットベル23は、たとえば受付装置20の取出口22を介して提供される。なお、制御装置10の制御に応じて取出口22からポケットベル23を提供するための受付装置20の構成は、当業者が任意に設計可能である。【0052】図11は、ステップS22の実行に関連して表示される画面の例を示す。この表示はたとえば受付端末21に表示される。この表示は、たとえば、卓が空いていないことを示すメッセージと、ポケットベル23を受け取ることを促すメッセージと、ポケットベル23の番号(以下「ポケベル番号」)(待機者識別情報)を受付装置20に入力することを促すメッセージ(この図ではバーコードリーダ24に読み取らせることを促すメッセージ)と、卓が空いたことに応じてポケットベル23に通知が行われることを示すメッセージと、受付番号とを含む。【0053】次に、制御装置10は、その卓要求操作に関連付けられるポケベル番号(待機者識別情報)を取得する(ステップS23)。たとえばポケベル番号は、顧客がポケットベル23に印刷されたバーコードをバーコードリーダ24に読み取らせることに応じ、バーコードリーダ24が取得して制御装置10に送信する。【0054】ポケベル番号の取得は、様々な方法で行うことができる。たとえば受付装置20の付近に店員を配置し、店員がポケットベル23をバーコードリーダ24にかざしてもよい。または、受付装置20がポケットベル23の提供に伴って自動的に取得してもよい。または、ポケットベル23がポケベル番号を動的に変更可能なものである場合には、制御装置10がポケベル番号を決定し、これを取得した後にポケットベル23に付与してもよい。【0055】次に、制御装置10は、処理中の卓要求操作を表す受付番号に対応する行を受付管理DB72に追加する(ステップS24)。ここで追加される行は、受付番号と、受付時刻(たとえばステップS11が実行された時刻)と、希望エリア(たとえばステップS11において選択された領域)と、受付時点で空きが存在していなかったことを示す情報と、ステップS23で取得したポケベル番号とを含む。【0068】客席端末41は、終了操作を受け付けると、終了操作が行われたことを示す終了通知を制御装置10に送信する(ステップS42)。終了通知は、その終了通知を送信する客席端末41自身の卓番号を含む。制御装置10は、終了通知を受信することに応じて、該当する卓に設置された状況表示ランプ42(言い換えると、終了通知に含まれる卓番号に係る状況表示ランプ42)を所定の状態に変更させる(たとえば青色に点灯させる)(ステップS43)。【0071】ステップS44において、その卓を希望している待機中の顧客が存在する場合には、制御装置10は、その卓に案内すべき顧客を決定する(ステップS46)。たとえば、その卓に対応する卓要求操作のうちから、受付時刻が最も早いものを選択する。ここで、待機中の顧客の卓要求操作にはそれぞれポケベル番号が付与されているので、制御装置10は、終了通知を受信することに応じて、ポケットベル23のいずれかを、その終了通知に含まれる卓番号に関連付けるということができる。【0073】このように、制御装置10は、終了通知を受信することに応じて、受付管理DB72(第1のデータベース)に基づき、その終了通知に含まれる卓番号と、いずれかのポケベル番号とを関連付けて、卓状況DB73(第2のデータベース)に記憶する。より詳しく表現すると、制御装置10は、受付管理DB72において該当のポケベル番号に関連付けられた卓要求操作に対応する各卓(すなわちその卓要求操作において指定された希望エリアに配置された各卓)に係る各卓番号のいずれかを含む終了通知を受信することに応じて、その終了通知に含まれる卓番号と、そのポケベル番号とを関連付けて、卓状況DB73に記憶する。【0074】ここで、制御装置10は、受付管理DB72においてそのポケベル番号を消去してもよい。【0075】次に、制御装置10は、ステップS46において決定された顧客に対し、呼出通知を送信する(ステップS48)。たとえば、ステップS46において選択された卓要求操作に関連付けられたポケベル番号を参照し、対応するポケットベル23に対して呼出通知を送信する。呼出通知とは、たとえば顧客を受付端末21に呼び出すための通知である。【0077】次に、制御装置10は、所定の呼出応答操作を受け付ける(ステップS49)。呼出応答操作とは、顧客が呼出通知に応答して呼び出されたことを制御装置10に通知する操作である。呼出応答操作はポケベル番号の入力を含み、たとえば受付装置20を介して受け付けられる。呼出応答操作はたとえば、顧客がポケットベル23に印刷されたバーコードをバーコードリーダ24に読み取らせる操作に対応する。この操作に応じ、制御装置10は、対応するポケベル番号を取得する。【0078】制御装置10は、卓状況DB73においていずれかの卓番号に関連付けられているポケベル番号を取得することに応じ、その卓の利用状況を「着席待ち」に変更する(ステップS50)。ここで、制御装置10はさらに、卓状況DB73において、その卓に関連付けられたポケベル番号を消去してもよい。【0080】次に、空き設備管理システム100は、図7のステップS17?S21と同様の処理を実行する(ステップS51?S55)。なお、ステップS51において表示される案内情報は、ステップS42において送受信された終了通知に含まれる卓番号に係る卓を示す情報(たとえば図9のように、所定の領域においてその卓に対応する位置にマーク表示を付した画像等)を含む。【0091】実施の形態1ではポケットベル23を用いているが、ポケットベル23を用いない構成としてもよい。たとえば、空き設備管理システム100は印刷装置を備えてもよく、ステップS22において、ポケットベル23に代えて、受付番号または待機者識別情報を印刷した紙片を提供してもよい。受付番号または待機者識別情報の双方を印刷してもよく、その場合には一方を文字または数字で、他方をバーコードにより印刷してもよい。その場合には、ステップS48の処理に代えて、特定の受付番号または待機者識別情報を与えられた顧客を呼び出す呼出処理が行われる。図5 図6 以上の記載からみて、先願明細書には以下の発明(以下「引用発明(先願)」という。)が記載されていると認められる。 (A)「フードコート等に設置される卓40を管理対象と」し(【0013】)、 (B)「制御装置10と、受付装置20と、複数のポケットベル23(待機者用受信機)と、調理指示端末30と、複数の客席端末41(設備端末)と」、「卓40のそれぞれに関連して設けられる」、「状況表示ランプ42(設備状態表示装置)および座席50を備え」(【0014】)、 (C)図7は、空き設備管理システム100が所定の卓要求操作を受け付けた場合に実行する動作の流れの例を示し(【0038】)、 (D)制御装置10は、卓要求操作(設備要求操作)を受け付ける(ステップS11)。卓要求操作とは、上述のように、新たな顧客が卓の割り当てを要求する操作であり、この操作は、制御装置10が受付端末21を介して受け付けてもよく、ここで制御装置10は、卓要求操作を表す受付番号を決定し(【0038】) (E)卓要求操作は、対応する卓(または卓の集合)を特定するものであってもよく、たとえば図8の例では、顧客は、所定のボタンを選択して操作することにより、卓要求操作に対応して希望する卓の集合を指定することができ、たとえば顧客が第1エリアを選択した場合には、第1エリアに配置された卓(図4の例では卓番号A001?A003等の卓)に対応する卓要求操作が受け付けられることになるものであり(【0039】)、 (F)制御装置10は、受け付けた卓要求操作に対応する卓のいずれかが空いているか否かを判定し(ステップS12)【0040】、 (G)対応する卓のいずれかが空いている場合には、制御装置10は、処理中の卓要求操作を表す受付番号に対応する行を受付管理DB72に追加し、(【0041】) (H)制御装置10は、顧客に利用させるべき卓を決定(ステップS14)し(【0042】)、制御装置10は、ステップS14で決定された卓がもはや空いていないことを示すよう、卓状況DB73において利用状況を更新し(【0043】)、 (I)制御装置10は、その卓を特定する案内情報を出力することにより、顧客に対して案内を行い(ステップS17)(【0045】)、 (J)顧客は案内表示に従って決定された卓に移動し、その卓の客席端末41において着席操作を行うことになる。本実施形態では、顧客は受付番号を入力し(【0047】)、 (K)着席後の処理(S18?S21)をおこなう(【0048】-【0050】)、 (L)ステップS12において、卓要求操作に対応する卓がいずれも空いていない場合には、制御装置10は、その顧客に対してポケットベル23を供給し(ステップS22)【0051】、 (M)制御装置10は、その卓要求操作に関連付けられるポケベル番号(待機者識別情報)を取得する(ステップS23)。たとえばポケベル番号は、顧客がポケットベル23に印刷されたバーコードをバーコードリーダ24に読み取らせることに応じ、バーコードリーダ24が取得して制御装置10に送信し(【0053】)、 (N)ポケベル番号の取得は、様々な方法で行うことができる。たとえば受付装置20の付近に店員を配置し、店員がポケットベル23をバーコードリーダ24にかざしてもよい。または、受付装置20がポケットベル23の提供に伴って自動的に取得してもよい。または、ポケットベル23がポケベル番号を動的に変更可能なものである場合には、制御装置10がポケベル番号を決定し、これを取得した後にポケットベル23に付与してもよく(【0054】)、 (O)制御装置10は、処理中の卓要求操作を表す受付番号に対応する行を受付管理DB72に追加する(ステップS24)。ここで追加される行は、受付番号と、受付時刻(たとえばステップS11が実行された時刻)と、希望エリア(たとえばステップS11において選択された領域)と、受付時点で空きが存在していなかったことを示す情報と、ステップS23で取得したポケベル番号とを含み(【0055】)、 (P)客席端末41は、終了操作を受け付けると、終了操作が行われたことを示す終了通知を制御装置10に送信する(ステップS42)。終了通知は、その終了通知を送信する客席端末41自身の卓番号を含む。制御装置10は、終了通知を受信することに応じて、該当する卓に設置された状況表示ランプ42(言い換えると、終了通知に含まれる卓番号に係る状況表示ランプ42)を所定の状態に変更させる(たとえば青色に点灯させる)(ステップS43)(【0068】)。 (Q)ステップS44において、その卓を希望している待機中の顧客が存在する場合には、制御装置10は、その卓に案内すべき顧客を決定する(ステップS46)。たとえば、その卓に対応する卓要求操作のうちから、受付時刻が最も早いものを選択する。ここで、待機中の顧客の卓要求操作にはそれぞれポケベル番号が付与されているので、制御装置10は、終了通知を受信することに応じて、ポケットベル23のいずれかを、その終了通知に含まれる卓番号に関連付けるということができ(【0071】)、 (R)制御装置10は、終了通知を受信することに応じて、受付管理DB72(第1のデータベース)に基づき、その終了通知に含まれる卓番号と、いずれかのポケベル番号とを関連付けて、卓状況DB73(第2のデータベース)に記憶する。より詳しく表現すると、制御装置10は、受付管理DB72において該当のポケベル番号に関連付けられた卓要求操作に対応する各卓(すなわちその卓要求操作において指定された希望エリアに配置された各卓)に係る各卓番号のいずれかを含む終了通知を受信することに応じて、その終了通知に含まれる卓番号と、そのポケベル番号とを関連付けて、卓状況DB73に記憶し(【0073】)、 (S)制御装置10は、ステップS46において決定された顧客に対し、呼出通知を送信する(ステップS48)。たとえば、ステップS46において選択された卓要求操作に関連付けられたポケベル番号を参照し、対応するポケットベル23に対して呼出通知を送信し(【0075】)、 (T)制御装置10は、所定の呼出応答操作を受け付ける(ステップS49)。呼出応答操作とは、顧客が呼出通知に応答して呼び出されたことを制御装置10に通知する操作であり、呼出応答操作はポケベル番号の入力を含み、たとえば受付装置20を介して受け付けられ、呼出応答操作はたとえば、顧客がポケットベル23に印刷されたバーコードをバーコードリーダ24に読み取らせる操作に対応し、この操作に応じ、制御装置10は、対応するポケベル番号を取得し(【0077】)、 (U)制御装置10は、卓状況DB73においていずれかの卓番号に関連付けられているポケベル番号を取得することに応じ、その卓の利用状況を「着席待ち」に変更し、ここで、制御装置10はさらに、卓状況DB73において、その卓に関連付けられたポケベル番号を消去してもよく(【0078】)、 (V)空き設備管理システム100は、図7のステップS17?S21と同様の処理を実行する(ステップS51?S55)(【0080】)、 (W)実施の形態1ではポケットベル23を用いているが、ポケットベル23を用いない構成としてもよく、たとえば、空き設備管理システム100は印刷装置を備えてもよく、ステップS22において、ポケットベル23に代えて、受付番号または待機者識別情報を印刷した紙片を提供してもよいものであり、受付番号または待機者識別情報の双方を印刷してもよく、その場合には一方を文字または数字で、他方をバーコードにより印刷することも可能であり、この場合には、ステップS48の処理に代えて、特定の受付番号または待機者識別情報を与えられた顧客を呼び出す呼出処理が行われる(【0091】) (X)空き設備管理システム。 (3)対比・判断ア引用発明(先願)では、(A)?(E)において、フードコート等に設置される卓を要求する顧客が卓要求操作を受け付ける空き設備管理システムであって、上記卓要求は、対応する卓(または卓の集合)を特定するものを含むものであってもよいから、本件発明1の構成(a)を備える。イ引用発明(先願)では、(F)において、受け付けた卓要求操作に対応する卓のいずれかが空いているか否かを判定しているから、本件発明1の構成(b)を備える。ウ引用発明(先願)では、図5によれば、(F)において受付時空きなしの場合、(L)?(N)のポケベルを用いた実施例では、「受付番号」、「希望エリア」、「ポケベル番号」を登録するものであるが、これを(W)のポケベルを用いない例としたときには、受付番号または待機者識別情報の双方を印刷するものであってもよいから、ポケベル番号の代わりが「待機者識別情報」となることは明らかであることを鑑みれば、本件発明1の構成(c)を備える。エウのとおり、引用発明(先願)では、受付番号または待機者識別情報の双方を印刷するから、構成(d)を備える。オ引用発明(先願)では、(P)?(R)において、客席端末で顧客が、卓の利用を終了する処理を行うと、その卓を希望する次の利用者がいるか否か判別しているから、構成(e)を備える。カ引用発明(先願)では、(R)?(T)において、上記終了処理において終了処理がなされた卓番号にポケットベルの番号を関連付け、対応するポケットベルを呼出し、ポケベル番号の入力を含む呼出し応答操作を行うとされており、(W)の例の場合、ポケベル番号の代わりに待機者識別情報が関連付けされること先の検討のとおりであるから、上記(R)?(T)において、(ポケベル番号の代わりに)待機者識別番号の入力を受け付けることは明らかであり、構成(f)を備える。キ引用発明(先願)では、(U)において、「いずれかの卓番号に関連付けられているポケベル番号を取得することに応じ、その卓の利用状況を「着席待ち」に変更し」ており、W)の例とすれば、ポケベル番号に代わる待機者識別番号が正しいかどうか判別することは明白であるから、構成(g)を備える。ク引用発明(先願)では、(G)、(H)にて卓の空きがあるとき(I)の「その卓を特定する案内情報を出力することにより、顧客に対して案内を行い(ステップS17)」の処理を行こと、および、(U)にて「いずれかの卓番号に関連付けられているポケベル番号を取得する」とその卓の利用状況を「着席待ち」に変更し、さらに(V)にて「空き設備管理システム100は、図7のステップS17?S21と同様の処理を実行する」から、構成(h)を備える。ケ引用発明(先願)では、卓を特定する案内情報を出力することにより、顧客に対して案内を行った(案内データを提供)後の処理について、着席処理などは特定されているが、「前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除」することについて特定されていない。以下、この点について詳細に検討する。本件発明1の構成(i)は、構成(h)において、検索された座席の情報を案内データとして出力し、前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能であることを特定している。上記本件発明1の構成と引用発明(先願)との構成とを対比すれば、引用発明(先願)では、構成(S)にて呼出し通知を受けた顧客が、構成(T)にてポケットベルの番号を制御装置に通知することで、構成(U)により、制御装置が卓番号に関連付けられているポケベル番号を取得したとき、構成(V)にて、顧客に対して案内を行う(ステップS17)が、この際に、その卓に関連付けられたポケベル番号を消去(すなわち、認証情報の削除)が可能である構成を有しているから、この点で、上記本件発明1の構成(i)の「前記案内データを提供した前記ユーザの認証情報を削除可能である」構成と一応対応する。しかし、引用発明(先願)の「卓状態DB73」には、本件発明1の「条件」に相当する情報がなく、また、引用発明(先願)の受付管理DB72の「希望エリア」が本件発明1の「条件」に相当するとしても、これを削除可能であることは記載されていない。よって「座席の条件を削除可能である」ことについては、引用発明(先願)との対比における相違点となる。この点、異議申立人野中啓孝は、令和2年6月22日付け意見書3頁の上段にて、先願明細書の78段落と図5を摘記して、意見を述べている。しかし、78段落にて、「その卓に関連付けられたポケベル番号を消去してもよく」と説明されているのは、「卓状況DB73」のことであり、対応する図面として、図5(受付管理DB72)を用いているのは誤りであり、図5において、ポケベル番号を消去することが可能であることは直接記載がない事項である。また、同意見書5頁において「そして、受付番号1300、1302のようにポケベル番号を付与したケースであっても、希望エリアに空きが生じて顧客を呼び出した後はポケベル番号が不要になることから、ポケベル番号を消去しても良いことが記載されている(【0078】)、この際、ポケベル番号には希望エリアが関連付けられていることから(【0055】【0056】【図5】)、ポケベル番号番号を消去することには、条件を削除することも含まれていることが明らかである。」と主張している。しかし、「ポケベル番号には希望エリアが関連付けられている」ことと、「ポケベル番号を消去することには、条件を削除することも含まれていることが明らかである」との関係が何ら説明されていない。仮に、図6のポケベル番号の削除に伴って、図5のポケベル番号が削除されるとしても、本件発明1の「前記座席の条件を削除可能である」を、引用発明(先願)との一致点とすることはできない。図5において、各行中の「希望エリア」の欄(例えば、受付番号1300の行の「第1エリア」という部分)を削除するには、i)受付番号1300の行そのもののレコードを全て削除する、ii)受付番号1300の行のレコードは残し、「第1エリア」の記録だけ削除するの二つが考えられるものの、先願明細書の図5の受付番号1233、1234等の行(受付時に空きがあり、既に顧客を座席に案内した受付番号のレコードである)によれば、図5の受付管理DBにおいて、テーブルに空きがあり顧客をテーブルに案内した後も受け付けたレコードは削除されておらず、i)の処理は行っていない。そして、「受付時空き」が「あり」のレコードにおいて、希望エリアの記録が削除されていないから、顧客をテーブルに案内することに伴って「ポケベル番号」を削除するとしても、希望エリアの記録を削除することは、処理として不自然であり、ii)の処理が行われていると認定することもできない。以上のとおり、図5に記載された受付管理DB(72)における、各受付番号のレコードの記録状態からみて、「希望エリア」の列の記録は削除されておらず、引用発明(先願)は構成(i)を備えていない。コ上記引用発明(先願)が備えていない構成について、先願出願時点において、周知慣用手段であって、先願明細書に記載されているに等しい事項であるということはできない。 (4)してみると、本件発明1は、その出願の日前の特許出願であって、その出願後に出願公開がされた特願2015-156848号の特許出願の願書に最初に添付された明細書、特許請求の範囲又は図面に記載された発明と同一であるということはできず、特許法第29条の2の規定に違反してなされたものであるということはできない。 2 請求項2?請求項5、請求項7?9に係る特許について上記請求項に係る特許は、請求項1の記載を引用し、更に限定する構成を付加したものであるから、請求項1について検討したのと同様、先願明細書に記載された発明であるということはできない。 3 請求項10、請求項11について請求項10、請求項11は、請求項1の「案内装置」の発明を、それぞれ、「席案内プログラム」、「席案内方法」としたのみであり、請求項1と同様の構成であるから、請求項1と同様、先願明細書に記載された発明であるということはできない。第5 令和元年8月1日付けで通知した取消理由について 1 訂正(令和元年10月24日)前の請求項1?11に係る特許に対して、当審は、申立02の申立理由2-1及び2-2をふまえ、令和元年8月1日付けで下記の取消理由(ア)?(ウ)を特許権者に通知した。 (ア)(進歩性)請求項1ないし5、7ないし11に係る発明は、本件特許出願前に日本国内または外国において、頒布された下記の引用例に記載された発明に基いて、本件特許出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、請求項1ないし5、7ないし11に係る特許は、特許法第29条第2項の規定に違反してされたものである。 (イ)(明確性)本件請求項1ないし11特許は、特許請求の範囲の記載が不備のため、特許法第36条第6項第2号に規定する要件を満たしていない特許出願に対してされたものである。 (ウ)(サポート要件)本件請求項6ないし9に係る特許は、明細書の記載が不備のため、特許法第36条第6項第1号に規定する要件を満たしていない特許出願に対してされたものである。 2 以下に示すとおり、取消理由(ア)?(ウ)は令和2年5月28日の訂正請求により解消する。 (1)取消理由(イ) 訂正事項2、訂正事項11、訂正事項14により、特許請求の範囲が訂正されることにより、上記第3(2)イで検討したとおり第2検索部(第2検索機能、第2検索ステップ)により検索される条件は、明確となったから取消理由(イ)は解消した。 (2)取消理由(ウ) 訂正事項6ないし9により、明細書の記載と対応しない請求項は削除されたから、取消理由(ウ)は解消した。 (3)取消理由(ア) ア訂正後の請求項1に係る発明 (ア)本件発明1について上記訂正請求により訂正された訂正後の請求項1に係る発明(以下「本件発明1」という。)は、上記第4 1(1)のとおりである。 (イ)引用例の記載・引用発明取消理由(ア)において引用した特表2005-527017号公報(2甲1、以下引用例という。)には以下の事項が記載されている。【0001】本発明は、食事注文、食事品の準備処理、支払いを促進し、顧客の全体的なレストラン及びその他の飲食サービス施設における体験を改善するという分野に関する。特に、この発明は、一つまたはそれ以上のサーバに無線で接続された、薄いタッチ式画面端末と携帯機を含有し、顧客が自分自身で迅速に、効率よく食事の注文及び支払いができるシステムに関する。【発明が解決しようとする課題】【0021】それ故、本発明は、以前の発明における多くの技術的欠点を克服するものである。本発明の目的には、飲食業界における最適なハードウエア機器の使用と施行により、顧客が従業員の介入なしで無線で注文できることを含有する。【0022】完全な注文処理解決で、注文受付や、注文遂行過程処理、支払い処理方法に対処することが、本発明の更なる目的である。【0023】低コストで信頼性のある、安全なシステムで、飲食業者の運用をより効率良くするシステムを提供することが、本発明の更なる目的である。【0024】顧客の待ち時間を最小限にし、顧客へのサービスと、顧客の飲食業店における全体的な体験を改善することが、本発明の更なる目的である。【0025】従業員不足と従業員費用増加を緩和するシステムを提供することが、本発明の更なる目的である。【0026】固定した端末または携帯機を使用し、注文受付や支払い処理のできるシステムを提供することが、本発明の更なる目的である。携帯機には、携帯電話や、PDA、及びそれ以外の無線機器が含まれる。【0033】レストランや食事施設等において、自動座席配置(隣接するテーブルに着く選択も含む)を可能にすることが、本発明の更なる目的である。【課題を解決するための手段】【0042】本発明は、レストラン等の食事施設にて、顧客の為の食事料理注文処理システムを改善することを目的としている。本発明は、特別に設計された端末と、現存のインターネット・アクセス(接続)が可能な携帯機器を利用し、レストラン等の食事施設にて、顧客が従業員の介入なしに、飲料品や食事料理品を無線で注文したり、その支払いができるようにしている。それ故、本発明は、注文処理と支払い処理だけにとどまらず、注文から支払いまでの完全な遂行過程処理を含み、更に、多国言語使用、自動着席案内、事前注文、顧客への報奨ポイント、動的販売、余った在庫販売の促進等の、特別追加企画を含む。【0043】費用効率の良い、信頼性の高い、安全なシステムに加えて、この発明は、全体の注文処理を非常に早め、顧客の待ち時間を減らし、レストラン等の食事施設における運営の効率を向上させ、顧客へのサービスを増し、顧客のレストラン等での総合的体験を改善する。その上、この発明技術を取り入れることにより、レストラン等の食事施設の持ち主は、従業員不足と従業員費用の心配から緩和される。【0095】図6.1.1.1は、現金と現金不要支払い媒体の両方を受け入れるレストランにおいて端末使用するところの過程論理の図である。示されているように、過程は団体が店[10]に入るところから始まる。この言葉「団体」は、首尾一貫性のために、顧客が数人であろうが一人であろうが用いられる。店の経営者の好みにより、顧客が自分で席を選ぶことができ、全ての注文過程を手早く済ませ、店の労働コストを削減することができる自動着席案内システム[15]を使うかどうかを選ぶことができる。もし店が自動着席案内システムを使っているならば[15:はい]、論理は図8.1.3.1[25]に描写されているように進み、後でテーブルへ向かっている団体に戻る[220]。しかし、もし店が自動着席案内システムを使っていなければ[15:いいえ]、従業員は団体の幹事から名前、人数、禁煙席か喫煙席かを聞かなければならない[30]。【0096】団体幹事の名前と来店コード(下参照)は注文システムにログインする安全な手段として一緒に使われている。付加して、団体幹事の名前は、「団体名」の役割を果たし、特に団体がいくつかのテーブルに分かれて座っていて、注文をするのに違う端末を使っている場合に、団体のメンバーを一まとめにすることに役立つ。団体幹事は名前が明記されている現金不要支払いカードを提示することにより、若しくはこのシステムのために特別にデザインされたカード(もしそのようなカードが使われるようになれば)を使うことにより、従業員に名前を知らせることもできるということは言及すべきである。【0097】そして従業員は顧客の名前、団体の人数、禁煙席か喫煙席かをシステムに入力する[40]。情報を入力することにより、システムはその団体のための「来店コード」を発行する[50]。「来店コード」はアットランダムに作られるコードで、数字と文字によって成り立ち、団体が店にいる間、団体を識別するために用いられる。この来店コードは発行からその顧客の団体がログアウトし、勘定が支払われるまで有効である。つまり、来店コードは顧客が注文を入れる前に実際に店の中にいるということを確実にするための安全装置の役割をも果たす。これは現金支払いを食事の後に顧客から受けつける店において注文が携帯機器を用いて行われる場合に非常に重要である。もしなんらかの、団体が店で注文をしている間にのみ有効なアットランダムに作られたコードがなければ、誰かレストランの外にいる者が自分の携帯機器を使って悪ふざけで注文を入れるということも可能であるからである。更に、来店コードは顧客にテーブルが与えられて初めて使えるようになる。【0098】その次に従業員は来店コードとバーコードが含まれたスリップを発行し、団体の幹事に手渡す[60]。このスリップはステップ50で来店コードが作られた後、システムによって自動的にプリントされることもできる。次に従業員は席が空いているかどうかを確認する[70]。もし空席があれば[70:はい]従業員は特定のテーブル用に来店コードを使用可能にし[210]、そして団体にテーブル番号を知らせる、若しくは団体にテーブルを示す[215]。その後団体はテーブルへと進む[220]。もし空席がなければ[70:いいえ]、団体は待合室内の「ゲスト用端末」が空いているかを見ることができる[80]。「ゲスト用端末」は、実際のテーブルで使えるのと同じような注文端末である。しかしながらこれはあくまでも閲覧するためと、その日可能なメニューアイテムの前注文をするためのみに使うことができる。顧客はまだ席に着いていないので、前注文されたアイテムはキッチンには送られず、臨時的に記憶されて、後に着席した後、回復することができる。【0102】もし、団体の誰も携帯機を持っていない場合[150:いいえ]従業員が、テーブルに案内するまで、待つことになる。しかし、団体が、携帯機を持っている場合[150:はい]、図形8.1.5に表されている説明に基づきメニューを見たり、前もって注文することができる。テーブルが空くと、従業員が、団体の情報をシステムより読み取る[200]。前にも述べたように、システムは、どの団体に、テーブルが利用できるか、表示することができる。それで、従業員が、団体の来店コードを利用できるテーブル用にアクティブ化する[215]。そして、団体はテーブルに案内される[220]。【0103】団体がテーブルに案内されると、幹事となる人が言語を選択する[225]、その店舗の所在する所で通常使われている言語と異なっていても、システムと店舗との設定がされていれば、選択された言語が端末のスクリーンに表示される。それから幹事が、名前と来店コードを端末に入力して、ログインする[230]。一つの団体が複数のテーブルを使用する場合、複数の端末を使用することになるので、システムはログインした人が幹事かどうかを確認する必要がある[240]。団体が二つ以上のテーブルと端末を使用する場合(テーブル一つに一端末と仮定して)、他のメンバーが端末に団体の来店コードでログインすることは可能だが、個人名意外に団体の幹事の名前を指定しなければならない。団体の幹事がログインした場合には他の人が同じ来店コードでログインするこが出来ない事を覚えておく必要がある。幹事以外の人が図形8.3.1に示された様に注文に追加することはできるが注文自体をすることはできない。幹事は注文担当を指名する場合以外は、メンバーの注文を確認する必要がある[図8.3.1:104-106]、その場合には、メンバーが直接注文することができる。【0205】図8.1.3.1は飲食店の自動着席案内の論理を詳述したものである。この過程は、図8.1.3.2(手順10:テーブルの利用可能性確認前)に記述されるように、事前にテーブルの利用可能性を確認することから始まる[10]。入力された情報をもとにして、システムはテーブルが利用可能かどうか判断する[20]。続いてシステムはテーブルが利用可能かどうか、自動着席案内システムが保留されていないかどうかの確認を行う[30]。従業員は、様々な理由から必要と判断すれば、着席案内をマニュアルで行う。その場合はシステムにより自動的に顧客が着席案内されるのを一時的に望まないため、自動着席案内システムを保留にすることができる。【0206】利用可能なテーブルがあり、自動着席案内システムが保留になっていない場合[30:はい]、システムは、利用可能なテーブルに顧客の団体の総人数が着席できるかどうか確認する[40]。団体の規模が利用可能なテーブルの最大着席人数を超えない場合[40:いいえ]、つまりその団体が着席できるテーブルが利用可能な場合には、論理は以下の「すぐに利用可能なテーブル」と題した項目に記述されるように続く。【0207】どの利用可能なテーブルにもその団体が着席できない場合[40:はい]、システムは2つの隣接したテーブルが利用可能かどうか確認する[100]。もしあれば[100:はい]、次の論理は以下の「すぐに利用可能なテーブル」と題した項目で説明される。一方、もし2つの隣接するテーブルが利用可能でない場合[100:いいえ]、その旨を示すメッセージが団体の幹事に表示される[110]。団体の幹事は、幹事とその団体は1)どんなテーブルの組み合わせでもその団体が着席できるか確認したい、2)隣接したテーブルが空くのを待ちたい、または3)待ちたくない(施設を去る)のいずれかを示唆しなければならない[120]。【0208】団体が待ちたくない場合[120:待たない]、施設を退出してもよい[130]。団体が隣接したテーブルが空くのを待ちたい場合[120:隣接したテーブルを待つ]、図8.1.3.2(手順300:テーブルの利用可能性確認後)に示すように、団体の幹事は幹事の情報をログイン端末/機器に入力する[140]。するとシステムはその団体を(隣接するテーブルの)待機リストに追加する[150]。その団体は隣接するテーブルが利用可能になるまで待たなくてはならない[200]。テーブルが利用可能となったときに起こる論理は、以下の「利用可能になったテーブル」と題した項目に記述される。もし、その団体の幹事がどんなテーブルの組み合わせも受容すると決定した場合[120:全てのテーブル]、システムはその団体に必要な数のテーブルが利用可能かどうか確認する[160]。もしあれば[160:はい]、次の論理は以下の「すぐに利用可能なテーブル」と題した項目で説明される。もし必要な数のテーブルが利用可能でない場合[160:いいえ]、団体の幹事は、幹事とその団体が待つか待たないかを決定する[170]。もしその団体が待ちたくない場合[170:いいえ]、施設を退出することは自由である[130]。もしその団体が待つことを決めた場合[170:はい]、図8.1.3.2(手順300:テーブルの利用可能性確認後)に示すように、団体の幹事は幹事の情報を入力しなければならない[180]。システムはその団体を(すべての利用可能なテーブルの)待機リストに追加する[190]。その後その団体はただ待っているだけでよい[200]。テーブルが利用可能になったときに起こる論理は以下の「利用可能になったテーブル」と題した項目に記述される。【0209】しばしば、どうしてもテーブルが利用できないことが起こる。(つまり、団体の規模に対してテーブルの席数の確認ができない)[30:いいえ]このような場合には、団体はテーブルが利用可能になるのを待つかどうか決定できる[300]。待ちたくない場合[300:いいえ]、施設を退出しても良い[310]。しかし、待ちたい場合[300:はい]、図8.1.3.2(手順300:テーブルの利用可能性確認後)に特定されるように、団体幹事は自分の情報を入力しなければならない[320]。いったん入力が完了すると、その団体は待機リストに追加される[330]。【0210】待合場所にゲスト用端末がある場合[340:はい]、団体は、図8.1.3.5(手順10:端末)に示された論理に従ってメニューを閲覧したり、事前に注文をしたりすることができる[350]。ゲスト用端末がない場合でも[340:いいえ]、団体のメンバーはメニューを閲覧することができる[380]。もし、団体のメンバーが携帯機を持たない場合や、持っていても自分の携帯機を使ってメニューの閲覧/事前注文をしない場合は[380:いいえ]、テーブルが利用可能になるまで待たなければならない[400]。テーブルが利用可能になったときに起こる論理は、以下の「利用可能になったテーブル」と題する項目に記述される。団体メンバーの誰かが自分の携帯機を使ってメニューの閲覧や事前注文をしたい場合[380:はい]、図8.1.3.5(手順10:携帯)に明記されているようにして、それをすることができる[390]。【0211】ゲスト用端末または携帯機がメニューの閲覧や事前注文に使用されるかどうかにかかわらず、テーブルが利用可能になったときの過程を表す論理は、以下の「利用可能になったテーブル」と題する項目に記述される。【0212】利用可能になったテーブル施設が現金及び現金不要の支払いが可能なシステムを利用している場合[500:現金＆現金不要支払い]、システムは特別な「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示する[510]。次の論理は、以下の「利用可能になったテーブル:来店スリップの確認」と題する項目に記述される。一方、施設が現金不要支払いのみのシステムを利用している場合[500:現金不要支払いのみ]、「利用可能なテーブル」画面は、団体の幹事名、団体の人数、テーブル番号を表示する[520]。次の論理は、このまま続く(以下)。【0213】利用可能になったテーブル:来店スリップの確認団体の幹事が来店スリップを持っている場合[530:はい]、幹事は自動着席案内または同様のサービスへと進み、自分の団体の来店スリップにあるバーコードをスキャンする[540]。システムは、来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し[550]、論理は以下の「来店コードを有効にする」と題する項目に続く。団体の幹事が来店スリップを持っていない場合[530:いいえ]、顧客/団体の幹事が短距離通信機能をもつ携帯機(つまり赤外線、ブルートゥース)を使用しているかどうかで論理が異なる[560]。幹事がそのような機能を持つ携帯機を使用していない場合[560:いいえ]、次の論理は以下の「来店コードを有効にする」と題する項目で説明される。団体の幹事がそのような機能を持った携帯機を利用している場合[560:はい]、幹事は顧客IDとその他の情報を自動着席案内または同様の機器/端末に送信しなければならない[570]。するとシステムは、利用可能なテーブルの番号を顧客の携帯機にワイアレスで転送する[580]。次の論理は、以下の「来店コードを有効にする」と題する項目に記述される。【0214】すぐ利用可能なテーブル図8.1.3.2(手順300:テーブルの利用可能性確認後)に記述されているように、団体の幹事は幹事情報の入力へと進み[50]、論理は以下に記述されるように続く。【0215】来店コードを有効にするシステムは、団体の来店コードまたは顧客のアカウントを有効にし[590]、論理の流れは、この図の論理に参照を付けた図へと戻る。【0216】図8.1.3.2は、顧客情報の入力の過程論理を詳述したものであり、飲食店の自動着席案内の過程論理における図8.1.3.1によって主に使用される。過程が開始する時点は、自動着席案内過程論理の図[図8.1.3.1]から参照するタイミングによる[10]。テーブルの利用可能性確認前に顧客情報の入力の要求が起こると[10:テーブルの利用可能性確認前]、次の論理は以下の「テーブルの利用可能性確認前」と題した項目に記述される。しかし、テーブルが利用可能かどうかの確認の後に顧客情報の入力の要求が行われると[10:テーブルの利用可能性確認後]、論理は以下の「テーブルの利用可能性確認後」と題した項目で説明される。【0217】テーブルの利用可能性確認前顧客が短距離通信機能を備えた携帯機(つまり赤外線、ブルートゥース)も、注文システム専用のシステムカードも持たない場合[20:いいえ]、顧客は専用の着席案内機器または端末を使用して、使用言語を選択しなければならない[30]。次に、顧客は団体の人数と喫煙の有無を入力する[40]。次の論理は、以下の「テーブルの利用可能性確認前:情報をサーバに転送する」と題する項目で説明される。【0222】テーブルの利用可能性確認前:情報をサーバに転送する顧客情報と嗜好はサーバに転送され[160]、論理はこの図の論理に参照を付けた図に戻る。【0223】テーブルの利用可能性確認後顧客が、(テーブルの利用可能性確認前において)携帯機またはシステムカードを以前に使用したことがある場合[300:はい]、次の論理は次の「テーブルの利用可能性確認後:利用履歴のある携帯機またはシステムカード」と題する項目に記述される。顧客が、携帯機またはシステムカードを以前に使用しなかった場合[300:いいえ]、自動着席案内機器または端末は、支払い媒体の明細を含めた顧客情報を入力するよう要求する[310]。【0224】システムが現金と現金不要支払いの両方の支払いを取り扱う場合[320:現金＆現金不要支払い]、顧客は希望の支払い媒体を選択する[330]。支払い媒体が現金と指定された場合[340:現金]、論理は以下の「テーブルの利用可能性確認後:名前の入力」と題した項目へと進む。希望の支払い媒体が現金不要支払いの場合[340:現金不要支払い]、次の論理は以下の「テーブルの利用可能性確認後:現金不要支払い媒体の選択」と題した項目に記述される。システムが現金不要支払いのみ処理する場合は[320:現金不要支払いのみ]、論理は以下のように進む。【0225】テーブルの利用可能性確認後:現金不要支払い媒体の選択顧客は現金不要支払い媒体タイプ(つまり、クレジットカード、デビットカード、プリペイドカード、スマートカード)を自動着席案内機器/端末上で選択し[350]、媒体情報を自動着席案内機器/端末へ入力または転送する[360]。自動着席案内機器/端末が、顧客名を現金不要支払い媒体から識別することが可能であれば[370:はい]、論理は、以下の「テーブルの利用可能性確認後:システムタイプ」と題した項目に記述されるように続く。しかし、顧客名が媒体から確定できない場合[370:いいえ]、論理は以下のように進む。【0226】テーブルの利用可能性確認後:名前の入力顧客はマニュアルで名前を入力する[380]。この名前はどんな恣意的な名前も可能で、必ずしもフルネームである必要もないことに注意する。次の論理は、採用されているシステムのタイプによって異なり[600]、以下の「テーブルの利用可能性確認後:システムタイプ」と題した項目に記述される。【0227】テーブルの利用可能性確認後:利用履歴のある携帯機またはシステムカード顧客が以前にシステムカードを利用して嗜好を転送/入力したことがある場合[500:カード]、次の論理は以下の「テーブルの利用可能性確認後:システムタイプ」と題した項目に記述される。また、顧客が短距離通信機能(つまり、赤外線、ブルートゥース)を備えた携帯機を使用した場合[500:携帯]、サーバは顧客のバーコードと来店コードを顧客の携帯機に転送、保存、そして表示する[510]。システムが顧客のためにテーブルがすぐに利用可能であると判断した場合[520:はい]、サーバは更に顧客のテーブル番号を顧客の携帯機に転送、保存、そして表示する[530]。【0228】テーブルが利用可能である(上記のように)かないかにかかわらず[520:いいえ]、施設の選択またはシステムによって、サーバは再確認のために顧客用スリップを印刷する必要があるかどうかも確認する[540]。その理由は、2組の顧客または団体が同じテーブルをめぐって矛盾を起こすとき(つまり、起こる可能性は非常に低いが顧客が正当に見える情報を作成するために偽の画像を携帯機に作成した場合)、スリップがどちらの顧客または団体が有効な情報を持っているかを最終的に決定する。そのようなシナリオはほとんど起こる可能性はないが、スリップの確認のための追加論理がセーフガードとして提供されている。印刷されたスリップによる確認が必要であれば[540:はい]、次の論理は以下の「テーブルの利用可能性確認後:システムタイプ」と題した項目に記述される。必要でない場合[540:いいえ]、論理の流れはこの図に記述された論理に参照を付けた図へ戻る。【0229】テーブルの利用可能性確認後:システムタイプシステムが現金及び現金不要支払い媒体を許容する場合[600:現金＆現金不要支払い]、システムは来店コード及びバーコードの記載されたスリップを顧客及びその団体のために作成し印刷する[610]。次の論理は以下の「テーブルの利用可能性確認後:テーブルの利用可能性」と題した項目に記述される。システムが現金不要支払い媒体のみを許容する場合[600:現金不要支払いのみ]、システムが現金不要支払いのみの環境でスリップを印刷するよう設定されているかどうか確認が行われる[620]。もし設定されていない場合[620:いいえ]、テーブルが利用可能であれば[624:はい]、顧客のテーブル番号が自動着席案内機器または端末に表示される[626]。(顧客が自分の携帯機ではなく自動着席案内機器または端末を使用している場合)しかし、もしテーブルが利用可能でない場合[624:いいえ]、論理の流れはこの論理図に参照を付けた論理図へ戻る。システムが現金不要支払いのみの設定においてスリップを印刷するよう設定されている場合[620:はい]、システムはバーコード及び顧客名が記載された顧客用来店スリップを作成し印刷する[630]。【0230】テーブルの利用可能性確認後:テーブルの利用可能性テーブルが顧客のために利用可能であるとき[640:はい]、自動着席案内機器は顧客の来店スリップにテーブル番号も印刷する[650]。テーブルが利用可能であるかどうかにかかわらず[640:いいえ]、顧客は作成されたスリップを受け取り[660]、過程はこの論理図に参照を付けた論理図へ戻る。以上の記載によれば、引用例には以下の発明(以下「引用発明」という。)が記載されていると認められる。 (A)レストランや食事施設等において、自動座席配置(隣接するテーブルに着く選択も含む)を可能にするシステムであって、(【0001】、【0033】) (B)図6.1.1.1は、現金と現金不要支払い媒体の両方を受け入れるレストランにおいて端末使用するところの過程論理の図であり、過程は団体が店[10]に入るところから始まり、店の経営者の好みにより、顧客が自分で席を選ぶことができ、全ての注文過程を手早く済ませ、店の労働コストを削減することができる自動着席案内システム[15]を使うかどうかを選ぶことができき、もし店が自動着席案内システムを使っているならば[15:はい]、論理は図8.1.3.1[25]に描写されているように進み、後でテーブルへ向かっている団体に戻る[220]構成であり、(【0095】) (C)図8.1.3.1は飲食店の自動着席案内の論理を詳述したものであり、図8.1.3.2(手順10:テーブルの利用可能性確認前)に記述されるように、事前にテーブルの利用可能性を確認することから始まり[10]、(【0205】) (D)図8.1.3.2は、顧客情報の入力の過程論理を詳述したものであり、飲食店の自動着席案内の過程論理における図8.1.3.1によって主に使用され、過程が開始する時点は、自動着席案内過程論理の図[図8.1.3.1]から参照するタイミングにより[10]、テーブルの利用可能性確認前に顧客情報の入力の要求が起こると[10:テーブルの利用可能性確認前]、次の論理は以下の「テーブルの利用可能性確認前」と題した項目に記述され、(【0216】) (E)顧客が短距離通信機能を備えた携帯機(つまり赤外線、ブルートゥース)も、注文システム専用のシステムカードも持たない場合[20:いいえ]、顧客は専用の着席案内機器または端末を使用して、使用言語を選択し[30]、次に、顧客は団体の人数と喫煙の有無を入力し[40]、次の論理は、以下の「テーブルの利用可能性確認前:情報をサーバに転送する」と題する項目で説明され(【0217】テーブルの利用可能性確認前) (F)顧客情報と嗜好はサーバに転送され[160]、論理はこの図の論理に参照を付けた図に戻り、(【0222】テーブルの利用可能性確認前:情報をサーバに転送する)(合議体注:構成(D)に戻るから、図8.1.3.1の[10]に戻る) (G)入力された情報をもとにして、システムはテーブルが利用可能かどうか判断し[20]、続いてシステムはテーブルが利用可能かどうか、自動着席案内システムが保留されていないかどうかの確認を行い[30]、(【0205】) (H)利用可能なテーブルがあり、自動着席案内システムが保留になっていない場合[30:はい]、システムは、利用可能なテーブルに顧客の団体の総人数が着席できるかどうか確認し[40]、団体の規模が利用可能なテーブルの最大着席人数を超えない場合[40:いいえ]、つまりその団体が着席できるテーブルが利用可能な場合には、論理は以下の「すぐに利用可能なテーブル」と題した項目に記述されるように続き、(【0206】) (I)図8.1.3.2(手順300:テーブルの利用可能性確認後)に記述されているように、団体の幹事は幹事情報の入力へと進み[50]、(【0214】すぐ利用可能なテーブル) (J)顧客が、携帯機またはシステムカードを以前に使用しなかった場合[300:いいえ]、自動着席案内機器または端末は、支払い媒体の明細を含めた顧客情報を入力するよう要求し[310]、(【0223】テーブルの利用可能性確認後) (K)支払い媒体が現金と指定された場合[340:現金]、論理は以下の「テーブルの利用可能性確認後:名前の入力」と題した項目へと進み、(【0224】) (L)顧客はマニュアルで名前を入力し[380]、次の論理は、採用されているシステムのタイプによって異なり[600]、以下の「テーブルの利用可能性確認後:システムタイプ」と題した項目に記述され、(【0226】テーブルの利用可能性確認後:名前の入力) (M)システムが現金及び現金不要支払い媒体を許容する場合[600:現金＆現金不要支払い]、システムは来店コード及びバーコードの記載されたスリップを顧客及びその団体のために作成し印刷し[610]、次の論理は以下の「テーブルの利用可能性確認後:テーブルの利用可能性」と題した項目に記述され、(【0229】テーブルの利用可能性確認後:システムタイプ) (N)テーブルが顧客のために利用可能であるとき[640:はい]、自動着席案内機器は顧客の来店スリップにテーブル番号も印刷し[650]、テーブルが利用可能であるかどうかにかかわらず[640:いいえ]、顧客は作成されたスリップを受け取り[660]、過程はこの論理図に参照を付けた論理図へ戻り、(【0230】テーブルの利用可能性確認後:テーブルの利用可能性)、(合議体注:構成(I)に戻るから、図8.1.3.1の[50]に戻る) (O)システムは、団体の来店コードまたは顧客のアカウントを有効にし[590]、論理の流れは、この図の論理に参照を付けた図へと戻り、(【0215】)、(合議体注:構成(I)に戻るから、図6.1.1.1の[25]、構成(B)に戻る) (P)どうしてもテーブルが利用できない(つまり、団体の規模に対してテーブルの席数の確認ができない)[30:いいえ]場合には(合議体注:構成(H)の[30:はい]でない場合)、団体はテーブルが利用可能になるのを待つ場合[300:はい]、図8.1.3.2(手順300:テーブルの利用可能性確認後)に特定されるように、団体幹事は自分の情報を入力しなければならず[320]、(【0209】)(合議体注:以下は、上記構成(I)?(N)と同じであるが、戻るのは図8.1.3.1の[320]である) (Q)いったん入力が完了すると、その団体は待機リストに追加され[330]、(【0209】) (R)団体のメンバーが携帯機を持たない場合や、持っていても自分の携帯機を使ってメニューの閲覧/事前注文をしない場合は[380:いいえ]、テーブルが利用可能になるまで待たなければならず[400]、テーブルが利用可能になったときに起こる論理は、以下の「利用可能になったテーブル」と題する項目に記述され、(【0210】) (S)施設が現金及び現金不要の支払いが可能なシステムを利用している場合[500:現金＆現金不要支払い]、システムは特別な「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示し[510]、次の論理は、以下の「利用可能になったテーブル:来店スリップの確認」と題する項目に記述され、(【0212】) (T)団体の幹事が来店スリップを持っている場合[530:はい]、幹事は自動着席案内または同様のサービスへと進み、自分の団体の来店スリップにあるバーコードをスキャンし[540]、システムは、来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し[550]、論理は以下の「来店コードを有効にする」と題する項目に続き、(【0213】利用可能になったテーブル:来店スリップの確認) (U)システムは、団体の来店コードまたは顧客のアカウントを有効にし[590]、論理の流れは、この図の論理に参照を付けた図へと戻る、(【0215】来店コードを有効にする)(合議体注:構成(I)に戻るから、図6.1.1.1の[25]、構成(B)に戻る) (V)レストランや食事施設等において、自動座席配置を可能にするシステム。 (ウ)対比・判断本件発明1について検討する。 (ウ-1)引用発明の「自動着席案内システム」は、「レストランや食事施設等において、自動座席配置を可能にするシステム」であるから、「席案内装置」である。 (ウ-2)引用発明の(A)?(E)の構成からみて、引用発明は、自動着席案内システムを使っているとき、顧客は専用の着席案内機器または端末を使用して、顧客は団体の人数と喫煙の有無を入力しているから、飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付けているといえ、上記受付のための手段である「飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付部」を有しているといえる。 (ウ-3)引用発明の(F)?(H)の構成からみて、引用発明は、上記条件受付部で受け付けた条件に適合する座席の有無を確認しており、上記確認のためには、確認時の座席の状態を知る必要があるから、座席の状態を含む座席データを有し、当該座席データを参照して適合する座席を検索していることは明らかであるから、引用発明は、本件発明1の構成(b)を備えている。 (ウ-4)引用発明の構成(P)によれば、座席が確保できないとき、構成(I)?(N)の処理を行っている。上記(I)?(N)の構成によれば、顧客はマニュアルで名前を入力し、システムは来店コード及びバーコードの記載されたスリップを顧客及びその団体のために作成し印刷している。上記スリップに印刷されたバーコードは、後に利用可能な座席が生じたとき、当該バーコードをスキャンすることで座席の案内を行っている(構成(T))から、「前記ユーザの認証用に付与され、ユーザを特定する認証情報」といえ、当該認証情報をスリップに印刷出力しているから、「認証情報を含む予約案内データを出力する予約情報出力部と」を有している。 (ウ-5)引用発明の構成(P)、(Q)によれば、構成(P)の後に「いったん入力が完了すると、その団体は待機リストに追加され」るから、上記予約案内出力の後、団体が待機リストに追加される。構成(R)を参酌すると、団体が「テーブルが利用可能になるまで待」ち、テーブルが利用可能になったときに起こる論理に移行するとあり、テーブルが利用可能になったときに起こる論理は、構成(S)ないし(U)によれば、『「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示し』、『団体の幹事が来店スリップを持っている場合[530:はい]、幹事は自動着席案内または同様のサービスへと進み、自分の団体の来店スリップにあるバーコードをスキャンし[540]、システムは、来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し』ている。上記の表示やバーコードをスキャンして確認するには、これらの情報が登録されていることが必要であることは明白であるから、構成(Q)で団体が待機リストに追加される際には、これらの情報が登録されることは明らかであり、これらの情報を登録する登録部を有している。そして、登録される「団体の人数」、「バーコード」は、それぞれ、本件発明1の「条件」、「ユーザを特定する認証情報」にそれぞれ対応することは明らかである。もっとも、引用発明は「予約の順番を特定する予約番号」に相当する構成を有していない。 (ウ-6)引用発明では、構成(Q)でリストに追加された後、構成(R)にて「テーブルが利用可能になるまで待たなければならず[400]、テーブルが利用可能になったときに起こる論理」に移行する構成が開示されるのみであるが、上記テーブルが利用可能になったときとは、リストに追加された条件で、団体が希望するテーブルが利用可能になったときであることは明らかであり、そのためには、テーブルの利用状況が変化し、前記座席データが更新されると、更新された前記座席データから、前記予約データとして登録された前記座席の条件に適合する空席の座席を検索していることは明らかであるから、引用発明は、構成(e)を備えているといえる。 (ウ-7)引用発明の構成(R)の「利用可能になったテーブル」と題する項目に移行することは、上記(ウ-6)で検討したように「前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索」した結果、「利用可能になったテーブル」が生じたことを意味するから、本件発明1の「前記第2検索部で条件に適合する座席が検索されると」に相当する。そして、引用発明の構成(S)、(T)によれば、バーコードをスキャンしており、引用発明のスリップは本件発明1の「認証情報」に相当するのであるから、引用発明は、本件発明1の構成(f)を有しているといえる。そして、引用発明では、『バーコードをスキャンし[540]、システムは、来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し』との構成を開示するのみであるが、上記スキャンの意味は、構成(S)にて『「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示し[510]』によって表示された団体と、『自分の団体の来店スリップにあるバーコードをスキャンし』の団体とが一致しているか否かを確認し、(スキャンされたバーコードが)正しい前記ユーザ([510]で表示された団体)によって入力されたものと判定していることは明白であり、引用発明は、本件発明1の構成(g)を備えている。 (ウ-8)本件発明1の第1検索部は、上記(ウ-3)で検討したように、引用発明の(F)?(H)の構成から導き出せる。そして、本件発明1の『前記第1検索部で条件に適合する座席が検索されると』に相当する判断は、引用発明の構成(H)の『その団体が着席できるテーブルが利用可能な場合には、論理は以下の「すぐに利用可能なテーブル」と題した項目に記述されるように続き』の判断に相当している。このとき、引用発明では、構成(I)?(N)の処理を行っている。そして、構成(N)では、『テーブルが顧客のために利用可能であるとき[640:はい]、自動着席案内機器は顧客の来店スリップにテーブル番号も印刷し[650]、テーブルが利用可能であるかどうかにかかわらず[640:いいえ]、顧客は作成されたスリップを受け取り[660]』の処理を行っているから、「前記第1検索部で検索された座席の情報を案内データとして出力し」ている。また、引用発明の構成(S)、(T)において、来店スリップにあるバーコードをスキャンし、(正しいユーザであると判定されれば)来店スリップまたは別の用紙にその団体のテーブル番号を任意で印刷し[550]ているから「前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第2検索部で検索された座席の情報を案内データとして出力」している。もっとも、上記(I)?(N)にてなされる出力と、(S)、(T)においてなされる出力は、なされるタイミングが異なるから、これらの出力部が同じかどうかは明らかではない。 (ウ-9)引用発明では、座席の情報を案内データとして出力したユーザの情報について、そのデータ更新の詳細について特定する構成を備えていない。 (ウ-10)以上まとめると、本件発明1と引用発明とを対比すると、両者は以下の一致点で一致し、相違点で相違する。一致点飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付部と、前記飲食店における各座席の状態を含む座席データを参照し、前記条件受付部で受け付けられた条件に適合する空席の座席を検索する第1検索部と、前記第1検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件とを含む予約データを登録する予約登録部と、認証情報を含む予約案内データを出力する予約情報出力部と、前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第2検索部と、前記第2検索部で条件に適合する座席が検索されると、前記ユーザによって入力される認証情報を取得する取得部と、前記取得部が取得した認証情報が、前記予約データが含む認証情報と一致するとき、前記取得部が取得した認証情報は正しい前記ユーザによって入力されたものと判定する認証処理部と、前記第1検索部で条件に適合する座席が検索されると、前記第1検索部で検索された座席の情報を案内データとして出力する案内出力部と、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第2検索部で検索された座席の情報を案内データとして出力する案内出力部と、を備える席案内装置。相違点1 本件発明1の予約登録部に登録される予約データは、「前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データ」であるのに対し、引用発明の予約登録部は「予約の順番を特定する予約番号」の構成を有さず、したがって、「前記予約番号と前記認証情報が関連付けされている」の構成も有していない点。相違点2 本件発明1の「予約情報出力部」は、「前記予約登録部が予約データを登録すると、前記予約データで登録された認証情報を含む予約案内データを出力する予約情報出力部」であるのに対し、引用発明では、予約情報を出力した後に予約情報を登録している点。相違点3 本件発明1の案内出力部は、「前記第1検索部で条件に適合する座席が検索されると、前記第1検索部で検索された座席の情報を案内データとして出力し、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第2検索部で検索された座席の情報を案内データとして出力する案内出力部」であるのに対し、引用発明では、「前記第1検索部で条件に適合する座席が検索されると、前記第1検索部で検索された座席の情報を案内データとして出力」する案内出力部と「前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第2検索部で検索された座席の情報を案内データとして出力」とが共通であるか明らかではない点。相違点4 本件発明1は「前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新部」を備えているのに対し、引用発明は、当該構成を備えていない点。事案に鑑み、相違点1について検討する本件発明1の予約番号について発明の詳細な説明には以下のとおり記載されている。「予約データ122は、予約の順序を特定する予約番号と、予約条件と、ユーザを特定する認証情報とを含むデータである。「予約番号」は、予約を登録する際に付与される。」(【0030】) 「図2(b)に示す例では、予約番号「123」の予約は、「3名、禁煙席」を予約条件とし、認証情報として「ｕ1」、「ｕ2」及び「ｕ3」が設定されたものである。また、予約番号「124」の予約は、「4名、喫煙席」を予約条件とし、認証情報として「ｕ2」、「ｕ4」及び「ｕ5」が設定されたものである。さらに、予約番号「125」の予約は、「8名、禁煙席」を予約条件とし、認証情報として「ｕ3」、「ｕ5」及び「ｕ6」が設定されたものである。」(【0032】) 「具体的には、第2検索手段105は、予約データ122から、検索対象の予約条件を特定する。予約データ122において複数の予約が登録されているとき、先に登録された予約番号を検索対象として特定する。また、第2検索手段105は、検索対象として特定された予約番号の条件に適合する空席の座席を、座席データ121から検索する。その後、第2検索手段105は、予約データ122において、検索対象の予約番号と関連付けられる認証情報を抽出し、検索対象の予約番号と、検索結果で得られた座席番号と、抽出した認証情報とを取得部110に出力する。」(【0039】) 「取得部110は、第2検索手段105から予約番号、座席番号及び認証情報(以下、「登録認証情報」とする)が入力されると、ユーザによって入力される認証情報(以下、「入力認証情報」とする)を取得する。また、取得部110は、取得した入力認証情報、第2検索手段105から入力された座席番号及び登録認証情報を、認証処理部111に出力する。例えば、取得部110は、ディスプレイ14に予約番号を含む認証情報入力画面を表示してユーザに座席が空いた旨を通知するとともに認証情報の入力を促し、操作入力装置13やマイク17を介してユーザから入力される入力認証情報を取得することができる。また例えば、取得部110は、スピーカ16を介して、入力された予約番号で予約された座席が空いた旨を通知するとともに認証情報の入力を促し、操作入力装置13を介してユーザから入力される入力認証情報を取得することができる。」(【0045】、【0046】) 以上の記載からみて、予約番号は、予約データの一部として予約を登録する際に付与され(【0030】)、「取得部110は、ディスプレイ14に予約番号を含む認証情報入力画面を表示してユーザに座席が空いた旨を通知するとともに認証情報の入力を促」(【0046】)すから、予約したユーザに対して座席が空いた旨を通知する際に表示される番号であり、該当する予約番号が付与されたユーザの予約の順番が回ってきたかを知らせるための番号であるといえる。これに対して、引用発明では、「システムは特別な「利用可能なテーブル」の画面に、団体の幹事名、団体の人数、団体の着席の確認手段を表示」(構成(S))するのであるから、予約したユーザに対して座席が空いた旨を通知する際に、該当する予約を行ったユーザを特定する情報としては、団体の幹事名を表示している。そして、引用発明では、上記幹事名を表示するため、構成(I)?(L)にあるとおり、幹事の情報を入力することが必須となっている。引用例に記載された発明は、そもそも、「食事注文、食事品の準備処理、支払いを促進し、顧客の全体的なレストラン及びその他の飲食サービス施設における体験を改善する」(【0001】) 「本発明は、レストラン等の食事施設にて、顧客の為の食事料理注文処理システムを改善することを目的としている。本発明は、特別に設計された端末と、現存のインターネット・アクセス(接続)が可能な携帯機器を利用し、レストラン等の食事施設にて、顧客が従業員の介入なしに、飲料品や食事料理品を無線で注文したり、その支払いができるようにしている。それ故、本発明は、注文処理と支払い処理だけにとどまらず、注文から支払いまでの完全な遂行過程処理を含み、更に、多国言語使用、自動着席案内、事前注文、顧客への報奨ポイント、動的販売、余った在庫販売の促進等の、特別追加企画を含む。」(【0042】) と記載されるとおり、レストラン等の食事施設において、注文処理と支払い処理だけにとどまらず、注文から支払いまでの完全な遂行過程処理の改善を目的とした、全体システムを提供しているのであり、引用例の記載では、例えば【0102】、【0103】にあるとおり、幹事名もその処理に利用することを前提としているから、引用例に記載された発明から、引用発明を抽出しても、「幹事名」の入力を省略することはできない。したがって、引用発明において「該当する予約を行ったユーザを特定する情報として、団体の幹事名をしている」構成を、本件発明1のように予約番号とすることはできない。異議申立人大薮朋子は、令和1年12月23日付け意見書にて、予約を特定するための情報として「予約の順番を特定する予約番号」を利用することは周知であるとして、甲第10号証ないし甲第14号証を新たに提示しているが、上記のとおり、引用発明において団体の幹事名を用いる構成を他の構成に変えることについて阻害要因があるから、仮に異議申立人大薮朋子の述べるように、予約を特定するための情報として「予約の順番を特定する予約番号」を利用することは周知であったとしても、引用発明に当該周知の事項を適用することはできない。なお、引用発明では、顧客を特定する情報として、バーコードの他に「来店コード」も生成している(構成M)。上記「来店コード」について、引用例の発明の詳細な説明を参酌すると、以下の記載がある。「団体幹事の名前と来店コード(下参照)は注文システムにログインする安全な手段として一緒に使われている。」(【0096】) 「「来店コード」はアットランダムに作られるコードで、数字と文字によって成り立ち、団体が店にいる間、団体を識別するために用いられる。この来店コードは発行からその顧客の団体がログアウトし、勘定が支払われるまで有効である。つまり、来店コードは顧客が注文を入れる前に実際に店の中にいるということを確実にするための安全装置の役割をも果たす。これは現金支払いを食事の後に顧客から受けつける店において注文が携帯機器を用いて行われる場合に非常に重要である。もしなんらかの、団体が店で注文をしている間にのみ有効なアットランダムに作られたコードがなければ、誰かレストランの外にいる者が自分の携帯機器を使って悪ふざけで注文を入れるということも可能であるからである。更に、来店コードは顧客にテーブルが与えられて初めて使えるようになる。」(【0097】) すなわち、団体を識別するための番号であって、アットランダムに作られるコードであるから本件発明1の予約番号とは異なるものである。よって、相違点2ないし相違点4について検討するまでもなく、本件請求項1に係る発明は、引用例が開示する発明から、当業者が容易に想到し得るものとはいえない。イ訂正後の請求項2?請求項11について訂正後の請求項2?5、7?9に係る特許は、請求項1の記載を引用して更に限定する構成を付加した発明であるから、本件発明1と同様の相違点を有し、上記アに示した理由と同様の理由により、引用例が開示する発明から、当業者が容易に想到し得るものとはいえない。また、訂正後の請求項10に係る特許は、本件発明1の「席案内装置」の発明を「席案内プログラム」とカテゴリを変えた発明であり、訂正後の請求項11に係る特許は、本件発明1の「席案内装置」の発明を「席案内方法」とカテゴリを変えた発明であるから、実質的に本件発明1と同様の相違点1を含む発明であり、上記アに示した理由と同様の理由により、引用例が開示する発明から、当業者が容易に想到し得るものとはいえない。訂正後の請求項6に係る特許は、上記訂正により削除されたから、取消理由の対象が存在しないものとなった。ウ以上のとおりであるから、取消理由(ア)は解消した。第5 取消理由通知において採用しなかった特許異議申立理由について 1 申立理由1(申立01)について申立理由1の主引用例である1甲1の記載(段落【0028】?【0037】、【0062】、図7、図8、図12)によれば、1甲1に記載されたシステムにおいては、座席予約ファイル352への登録は、名前、人数、禁煙喫煙の別を順次タッチ入力する毎にそれぞれの項目毎に行われており、「予約登録」に先立って「飲食店における各座席の状態を含む座席データを参照」して「ユーザ」(顧客)が「入力」した「希望の座席の条件」に「適合する空席の座席を検索」する「第1検索部」を備え、「第1検索部で条件に適合する座席が検索されないとき」に「予約データを登録する」ものでなく、かつ、座席予約ファイルに登録された内容に従って接客係の店員が用いるハンディターミナルに案内データを出力するのであって、「第1検索部で条件に適合する座席が検索されると、前記第1検索部で検索された座席の情報を案内データとして出力する」ものでない。この点は、本件発明1?5、7?11のいずれと対比しても、相違点となる。そして、1甲1においては、座席予約ファイル352への登録がなされない顧客は、いわば、ハンディターミナルを用いる接客係の店員が既に案内した顧客なのであって、改めて案内データをハンディターミナルに出力する必要がない。このことを踏まえれば、1甲1には、上記相違点を容易想到であるというために必要となる動機付けはなく、むしろ、阻害事由があるというべきである。申立01の申立人は、上記相違点を一致点と主張している。しかし、上記のとおりこの点は相違点であり、この主張を採用することはできない。 2 申立理由3-2(申立03)について申立理由3-2の主引用例である3甲2の記載(段落【0026】?【0032】、【0036】?【0040】、図3、図6、図8)によれば、3甲2に記載されたシステムにおいては、予約管理テーブル132への登録は、所定の期間毎に予約受付画面に表示されて予約内容に対応する2次元コードが示すメールアドレスへのメール送信によって行われており、「予約登録」に先立って「飲食店における各座席の状態を含む座席データを参照」して「ユーザ」(顧客)が「入力」した「希望の座席の条件」に「適合する空席の座席を検索」する「第1検索部」を備えて「第1検索部で条件に適合する座席が検索されないとき」に「予約データを登録する」ものでなく、かつ、予約管理テーブルに登録された内容に従ってオペレータの操作により又は自動的に案内メールを作成して送信するのであって、「第1検索部で条件に適合する座席が検索されると、前記第1検索部で検索された座席の情報を案内データとして出力する」ものでない。この点は、本件発明1?5、7?11のいずれと対比しても、相違点となる。そして、3甲2においては、予約管理テーブル132への登録がなされない顧客は、そもそも予約受付画面に表示された2次元コードの読み込みを行っておらず、案内メールが送信されることがないし、その必要もない。このことを踏まえれば、3甲2には、上記相違点を容易想到であるというために必要となる動機付けはなく、むしろ、阻害事由があるというべきである。申立03の申立人は、上記相違点を相違点とした上で、相違点に対応する構成が周知技術である等と主張している。しかし、仮にこれが周知技術であるとしても、上記のとおり相違点について容易想到ということはできないから、この主張を採用することはできない。第6 むすび以上のとおりであるから、取消理由通知に記載した取消理由及び特許異議申立書に記載した特許異議申立理由によっては、本件請求項1?5、7?11に係る特許を取り消すことはできない。また、他に本件請求項1?5に、7?11に係る特許を取り消すべき理由を発見しない。請求項6に係る特許は、訂正により削除されることにより、申立ての対象が存在しないものとなるため、特許法第120条の8第1項で準用する同法第135条の規定により却下する。よって、結論のとおり、決定する。
発明の名称	(57)【特許請求の範囲】【請求項1】飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付部と、前記飲食店における各座席の状態を含む座席データを参照し、前記条件受付部で受け付けられた条件に適合する空席の座席を検索する第1検索部と、前記第1検索部で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録部と、前記予約登録部が予約データを登録すると、前記予約データで登録された認証情報を含む予約案内データを出力する予約情報出力部と、前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第2検索部と、前記第2検索部で条件に適合する座席が検索されると、前記ユーザによって入力される認証情報を取得する取得部と、前記取得部が取得した認証情報が、前記予約データが含む認証情報と一致するとき、前記取得部が取得した認証情報は正しい前記ユーザによって入力されたものと判定する認証処理部と、前記第1検索部で条件に適合する座席が検索されると、前記第1検索部で検索された座席の情報を案内データとして出力し、前記認証処理部で正しい前記ユーザによって入力されたものと認証されると、前記第2検索部で検索された座席の情報を案内データとして出力する案内出力部と、前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新部と、を備える席案内装置。【請求項2】前記案内出力部が案内データを出力すると、前記案内データで前記ユーザに案内した座席の状態を着席に変更して前記座席データを更新する座席データ更新部をさらに備える、請求項1に記載の席案内装置。【請求項3】前記予約データ更新部は、前記案内出力部が前記第2検索部で検索された座席の情報を案内データとして出力すると、案内データを提供した前記ユーザの認証情報と条件を削除して前記予約データを更新する、請求項1又は2に記載の席案内装置。【請求項4】前記座席データの更新を検出し、座席データの更新を前記第2検索部に通知する検出部をさらに備える、請求項1乃至3のいずれか1項に記載の席案内装置。【請求項5】前記予約登録部は、予約の順序を特定する予約番号を含む予約データを登録し、前記第2検索部は、前記予約データが含む予約番号で先に予約が登録されたことが特定される条件の座席を検索対象とする請求項1乃至4のいずれか1項に記載の席案内装置。【請求項6】 (削除) 【請求項7】前記予約情報出力部は、予約情報を予約用紙に印刷する、予約情報を含む電子データを前記ユーザの端末に送信する、または、予約情報を含む表示画面をディスプレイに表示する請求項1乃至5のいずれか1項に記載の席案内装置。【請求項8】前記案内出力部は、案内データを案内用紙に印刷する、案内情報を含む電子データを前記ユーザの端末に送信する、案内情報を含む表示画面をディスプレイに表示する、または、案内情報を含む音声データをスピーカから出力する請求項1乃至5、7のいずれか1項に記載の席案内装置。【請求項9】前記案内データの前記座席の情報とは、前記飲食店における当該座席の座席番号である請求項1乃至5、7、8のいずれか1項に記載の席案内装置。【請求項10】席案内装置のコンピュータに、飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付機能と、前記飲食店における各座席の状態を含む座席データを参照し、前記条件受付機能で受け付けられた条件に適合する空席の座席を検索する第1検索機能と、前記第1検索機能で条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録機能と、前記予約登録機能が予約データを登録すると、前記予約データで登録された認証情報を含む予約案内データを出力する予約情報出力機能と、前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第2検索機能と、前記第2検索機能で条件に適合する座席が検索されると、前記ユーザによって入力される認証情報を取得する取得機能と、前記取得機能が取得した認証情報が、前記予約データが含む認証情報と一致するとき、前記取得機能が取得した認証情報は正しい前記ユーザによって入力されたものと判定する認証処理機能と、前記第1検索機能で条件に適合する座席が検索されると、前記第1検索機能で検索された座席の情報を案内データとして出力し、前記認証処理機能で正しい前記ユーザによって入力されたものと認証されると、前記第2検索機能で検索された座席の情報を案内データとして出力する案内出力機能と、前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新機能と、して機能させる席案内プログラム。【請求項11】コンピュータが実行する席案内方法であって、飲食店で空席の座席を求めるユーザによって入力される希望の座席の条件を受け付ける条件受付ステップと、前記飲食店における各座席の状態を含む座席データを参照し、前記条件受付ステップで受け付けられた条件に適合する空席の座席を検索する第1検索ステップと、前記第1検索ステップで条件に適合する座席が検索されないとき、前記ユーザの認証用に付与され、ユーザを特定する認証情報と、前記条件と、予約の順番を特定する予約番号とを含み、前記予約番号と前記認証情報が関連付けされている、予約データを登録する予約登録ステップと、前記予約登録ステップで予約データが登録されると、前記予約データで登録された認証情報を含む予約案内データを出力する予約情報出力ステップと、前記座席データが更新されると、更新された前記座席データから、前記予約データで登録され、前記座席の条件に適合する空席の座席を検索する第2検索ステップと、前記第2検索ステップで条件に適合する座席が検索されると、前記ユーザによって入力される認証情報を取得する取得ステップと、前記取得ステップが取得した認証情報が、前記予約データが含む認証情報と一致するとき、前記取得ステップが取得した認証情報は正しい前記ユーザによって入力されたものと判定する認証処理ステップと、前記第1検索ステップで条件に適合する座席が検索されると、前記第1検索ステップで検索された座席の情報を案内データとして出力し、前記認証処理ステップで正しい前記ユーザによって入力されたものと認証されると、前記第2検索ステップで検索された座席の情報を案内データとして出力する案内出力ステップと、前記案内データを提供した前記ユーザの認証情報と前記座席の条件を削除可能である、前記予約データを更新する予約データ更新ステップと、を有する席案内方法。
訂正の要旨	審決(決定)の【理由】欄参照。
異議決定日	2020-08-26
出願番号	特願2016-117980(P2016-117980)
審決分類	P 1 651・ 16- YAA (G06Q) P 1 651・ 537- YAA (G06Q) P 1 651・ 121- YAA (G06Q)
最終処分	維持
前審関与審査官	阿部潤
特許庁審判長	佐藤聡史
特許庁審判官	相崎裕恒渡邊聡
登録日	2018-09-14
登録番号	特許第6401741号(P6401741)
権利者	株式会社ゼンショーホールディングス
発明の名称	席案内装置、席案内プログラム及び席案内方法
代理人	特許業務法人白坂
代理人	鈴木敏弘
代理人	特許業務法人白坂

プライバシーポリシーセキュリティーポリシー運営会社概要サービスに関しての問い合わせ