2022-008774

第１ 手続の経緯

本願は、令和２年３月３０日の出願であって、その手続の経緯は以下のとおりである。

第２ 原査定の概要

原査定（令和４年３月４日付け拒絶査定）の概要は次のとおりである。

本願請求項１－３、６－１０に係る発明は、以下の引用文献１、２、４、５に記載された発明に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。また、本願請求項４、５に係る発明は、以下の引用文献１－５に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

＜引用文献等一覧＞

１．特開２０１７－２２０１７３号公報

２．特開２０１８－１３６７４７号公報（周知技術を示す文献）

３．“岳温泉 あだたらの宿 扇やホームページ | ご予約・料金のご案内”，[online]，岳温泉 あだたらの宿 扇や，2019年09月07日，インターネット＜URL：http://www.oogi-ya.co.jp/reserve.html＞，［2021年10月19日検索］（周知技術を示す文献）

４．特許第６３０６２５４号公報（周知技術を示す文献）

５．特開２００２－５６２５８号公報（周知技術を示す文献）

第３ 本願発明

本願請求項１－１０に係る発明（以下、それぞれ「本願発明１」－「本願発明１０」という。）は、令和４年６月８日にされた手続補正で補正された特許請求の範囲の請求項１－１０に記載された事項により特定される発明であり、本願発明９は以下のとおりの発明である。

「【請求項９】

店舗にてサービスの提供を受ける利用者の前記サービスの予約に関し、予約日時を含み、前記サービスの一部として前記利用者が事前に注文する事前注文サービスに関する事前注文情報を含まない予約情報を取得する予約取得部と、

事前注文取得部であって、

前記予約日時に応じた所定のタイミングにおいて、予約確認画面を表示させるための予約確認情報を利用者端末に送信し、

前記予約確認画面における操作に基づいて、前記事前注文情報を、前記利用者が前記サービスの提供を受ける前に取得する、事前注文取得部と、

前記事前注文情報に基づいて、前記事前注文サービスの決済をするための決済処理部と、を備える、予約管理装置。」

また、本願発明１は、本願発明９に対応する「プログラム」の発明であり、本願発明９とカテゴリ表現が異なるだけの発明である。

さらに、本願発明２－８は、本願発明１を減縮した発明である。

加えて、本願発明１０は、本願発明９に対応する「予約管理方法」の発明であり、本願発明９とカテゴリ表現が異なるだけの発明である。

第４ 引用文献、引用発明等

１ 引用文献１について

原査定の拒絶の理由に引用された引用文献１には、図面とともに次の事項が記載されている（下線は、当審で付した。以下同じ。）。

「【００３５】

図２は、飲食店システムのブロック図である。飲食店システムを構成する店舗装置１は、格納部１１、注文情報受信部１２１、注文料理情報出力部１２２、進捗情報受付部１２３、進捗情報送信部１２４、価格情報取得部１２５、価格集計部１２６、総合価格情報送信部１２７、人数取得部１２８、各人価格取得部１２９、各人価格情報送信部１３０、ユーザ端末識別子受信部１３１、メニュー情報送信部１３２、テーブル使用状況情報取得部１３３、テーブル使用状況情報出力部１３４、予約情報受付部１３５、予約情報出力部１３７、事前注文情報受付部１３８、事前注文情報蓄積部１３９、事前注文料理情報出力部１４０を備える。格納部１１は、メニュー情報格納部１１１、予約情報格納部１１２、事前注文情報格納部１１３を備える。ユーザ端末２は、端末格納部２１、端末受付部２２、端末出力部２３、端末受信部２４、端末送信部２５を備える。」

「【００６８】

予約情報受付部１３５は、予約情報を受け付ける。予約情報とは、店舗の予約を行うための情報であり、特に、店舗内のテーブルを予約するための情報をいう。予約情報は、好ましくは、テーブル識別子と、ユーザ端末識別子と、日時と、人数とを有する。ただし、予約情報は、ユーザ端末識別子、人数を有していなくてもよく、そのデータ構造は問わない。予約情報受付部１３５は、予約情報を、例えば、入力デバイスを介して受け付けてもよいし、ユーザ端末２から受信しても構わない。なお、日時は、開始時刻を示す情報でも良いし、時間帯を示す情報（開始時刻と終了時刻とを示す情報）でも良い。」

「【００８８】

図３および図４は、店舗装置１の動作例を説明するフローチャートである。

【００８９】

（ステップＳ３０１）予約情報受付部１３５は、予約情報を受け付けたか否か（ユーザ端末２から受信したか否か）を判別する。予約情報を受け付けた（ユーザ端末２から受信した）と判別された場合はステップＳ３０２に進み、受け付けていない（ユーザ端末２から受信していない）と判別された場合はステップＳ３０４に進む。

続きを表示（全12行）

【００９０】

（ステップＳ３０２）予約情報蓄積部１３６は、予約情報受付部１３５が受け付けた予約情報を、予約情報格納部１１２に蓄積する。

【００９１】

（ステップＳ３０３）予約情報出力部１３７は、予約情報受付部１３５が受け付けた予約情報を識別する予約識別子を、当該予約情報が有するユーザ端末識別子で識別されるユーザ端末２に送信する。なお、予約情報出力部１３７は、予約情報受付部１３５が受け付けた予約情報を、例えば、このタイミングで、ディスプレイ等の出力デバイスを介して出力してもよい。その後、ステップＳ３０１に戻る。

【００９２】

（ステップＳ３０４）事前注文情報受付部１３８は、当該予約情報に対応する事前注文情報を受け付けたか否か（ユーザ端末２から受信したか否か）を判別する。予約情報受付部１３５が当該予約情報に対応する事前注文情報を受け付けた（ユーザ端末２から受信した）と判別された場合はステップＳ３０５に進み、受け付けていない（ユーザ端末２から受信していない）と判別された場合はステップＳ３０６に進む。

【００９３】

（ステップＳ３０５）事前注文情報蓄積部１３９は、事前注文情報受付部１３８が受け付けた事前注文情報を、事前注文情報格納部１１３に蓄積する。その後、ステップＳ３０１に戻る。」

【図２】「

［図：0001395049000001.jpg］

」

ここで、図２の記載から、「店舗装置１は、予約情報蓄積部１３６を備える」ことが記載されていると認められる。

【図３】「

［図：0001395049000002.jpg］

」

したがって、引用文献１には次の発明（以下「引用発明」という。）が記載されていると認められる。

「飲食店システムを構成する店舗装置１は、格納部１１、予約情報受付部１３５、予約情報蓄積部１３６、事前注文情報受付部１３８、事前注文情報蓄積部１３９を備え、

格納部１１は、予約情報格納部１１２、事前注文情報格納部１１３を備え、

予約情報とは、店舗内のテーブルを予約するための情報をいい、

予約情報は、日時を有し、

予約情報受付部１３５は、予約情報を受け付けたか否か（ユーザ端末２から受信したか否か）を判別し、

予約情報を受け付けた（ユーザ端末２から受信した）と判別された場合、予約情報蓄積部１３６は、予約情報受付部１３５が受け付けた予約情報を、予約情報格納部１１２に蓄積し、

事前注文情報受付部１３８は、当該予約情報に対応する事前注文情報を受け付けたか否か（ユーザ端末２から受信したか否か）を判別し、

予約情報受付部１３５が当該予約情報に対応する事前注文情報を受け付けた（ユーザ端末２から受信した）と判別された場合、事前注文情報蓄積部１３９は、事前注文情報受付部１３８が受け付けた事前注文情報を、事前注文情報格納部１１３に蓄積する、店舗装置１。」

２ 引用文献２について

原査定の拒絶の理由に引用された引用文献２には、図面とともに次の事項が記載されている。

「【００２６】

伝票番号は、一括での決済の対象となる複数の注文に共通して割り当てられ、かつ別の決済の対象となる注文とは別に割り当てられる番号である。テーブル番号は上記の店舗において客が利用するテーブルに割り当てられた番号である。注文通番は、同じ伝票番号が割り当てられた複数の注文の個々に割り当てられる番号である。メニューコードは、注文の対象となった飲食物を識別するコードである。数量は、上記のメニューコードで識別される飲食物の注文数である。単価は、上記のメニューコードで識別される飲食物の１つ当たりの価格である。ステータスは、当該注文データが表す注文への対応状況を表す。事前注文フラグは、該当する注文が事前注文であるか否かを表すフラグである。本実施形態において事前注文フラグは、セット状態であるときに事前注文であることを示すこととする。決済フラグは、事前注文の際に決済が終了しているか否かを表すフラグである。本実施形態において決済フラグは、セット状態であるときに決済が終了していることを示すこととする。事前注文の際に決済可能な決済種別は、例えばクレジットカード決済である。事前注文の際に決済が行われる場合には、各店舗の代わりに、受注サーバ２０を管理運営する、あるいは事前注文サービスを店舗に提供する第三者がクレジットカード決済を代行する。したがって、事前注文の際に決済が終了している飲食物の代金は、受注サーバ２０を管理運営する、或いは事前注文サービスを店舗に提供する第三者から、後日、振込等で各店舗へ支払われる。」

３ 引用文献３について

原査定の拒絶の理由に引用された引用文献３には、次の事項が記載されている。

「追加オプション

・・・（中略）・・・

ケーキ 4号サイズ（約12cm） 2,700円

前日までのご予約で、地元洋菓子店の手作りケーキをご用意出来ます。

続きを表示（全13行）

メッセージを無料でお入れすることが出来ます。

（チョコ等のメッセージプレートです）

・お電話でのご予約では、ご予約時でお伝えください。

・予約フォームでは、

「ご要望欄」や「備考」にお書き添え下さい。

（例：「お父さん還暦おめでとう」「まゆみちゃんお誕生日おめでとう」

「祝 合格」）

※ご夕食開始時や食後など、ケーキをお出しするタイミングもご指定頂けます。

2,700円 で4号サイズケーキをご用意出来ます。お出しするタイミングもご指定頂けます。」

４ 引用文献４について

原査定の拒絶の理由に引用された引用文献４には、図面とともに次の事項が記載されている。

「【００５０】

予約処理の後、サーバ１００の予約部１５０において、選択されたサービス候補情報に含まれるサービス利用日に基づいて、予約リマインド・メッセージを一般ユーザにプッシュ通知する（Ｓ１５）。ユーザ端末３００の出力部２５０には、チャット・アプリケーションからの通知として「［予約リマインド］本日１７：００より銀座店」のような予約リマインド・メッセージが表示される（画面Ｄ３）。通知のタイミングは、予約情報１９６ａに含まれるサービス利用日に従い、例えば、サービス利用日当日の午前零時に通知を行うのがよい。また、予約リマインド・メッセージもユーザの予約情報１９６ａに含まれる情報を用いて生成するのがよい。

【００５１】

予約催促メッセージを確認した一般ユーザは、アプリケーション部２７０によるチャット・アプリケーションを起動し、トークルーム「予約チャット」内で予約情報の詳細を確認、或いは、予約の変更または取り消しを行うことができる（Ｓ３３）。予約の変更または取り消しを行う際には、ユーザ端末２００のアプリケーション部２７０は、やはり、サーバ１００のアプリケーション部１７０との間でチャットによる対話処理を行う。サーバ１００のアプリケーション部１７０は、予約処理と同様の手法で予約修正処理を実施する（Ｓ１７）。予約の変更の場合は、店舗、時間、および担当者の何れか１つ以上を変更することになる。

【００５２】

一実施形態によれば、サービス候補を検索する際に、ユーザは全てのパラメータを入力する必要なくサービス候補の提示を受けることができる。これにより、従来の予約サイトのように、候補を検索する度に同じ情報を入力しなければならないという手間を解消することができる。特に、サービス店舗毎に空き時間を確認しなければならないという手間を解消することができる。

【００５３】

また、チャット・アプリケーションを通じたサービス予約支援方法を提供することにより、一般ユーザからの予約を、営業時間に制約されることなく、２４時間受け付けることを可能にする。実際のサービス予約に要する時間は１分程度のため効率的である。これにより、ユーザは隙間時間を利用してチャットにより簡単に予約可能となり、また、ユーザ端末３００の操作を行う場所や環境も制限されることはない。

【００５４】

更に、一実施形態によれば、ユーザは、予約催促受領、予約操作、および予約確認の一連の操作を同一トークルーム内、即ち同一インタフェースで実施し完了させることができる点で有利である。これにより、例えば、従来の予約サイトでの予約確認を電子メールで受信した場合に、ユーザの受信ボックス内で予約確認メールが埋もれてしまうというような事態を回避することができる。」

５ 引用文献５について

原査定の拒絶の理由に引用された引用文献５には、図面とともに次の事項が記載されている。

「【請求項１５】 サービスを提供する店舗に備えた店舗クライアントと、該店舗のサービスの予約を行うユーザが所有するユーザ端末とに通信ネットワークを介して接続された予約サーバであって、

ユーザの予約情報を格納した予約情報ファイルと、

前記ユーザ端末に予約画面を送信する送信手段と、

前記予約画面において、前記ユーザが記入又は選択した予約に係る情報を受信する受信手段とを有し、

前記予約に係る情報を受信して、前記予約情報ファイルに予約に係る情報の追加、変更又は削除を行うことを特徴とする予約サーバ。」

「【請求項２０】 前記予約サーバは、ユーザの予約の所定時間前に、ユーザ端末に、予約確認のメールを送信することを特徴とする請求項１５記載の予約サーバ。」

第５ 対比・判断

１ 本願発明９について

（１）対比

本願発明９と引用発明とを対比すると、次のことがいえる。

ア 引用発明の「店舗装置１」は、「予約情報受付部１３５、予約情報蓄積部１３６、予約情報出力部１３７」を備えるから、予約を管理する装置であるといえる。したがって、引用発明の「店舗装置１」は、本願発明９の「予約管理装置」に相当する。

イ 引用発明の「予約情報」は、利用者が飲食店の店舗にてサービスの提供を受けるために「店舗内のテーブルを予約」することに関し、「日時を有」するものであるといえるから、本願発明９の「店舗にてサービスの提供を受ける利用者の前記サービスの予約に関し、予約日時を含」む「予約情報」に相当する。また、引用発明の「予約情報受付部１３５」は、予約を取得するものであるといえるから、本願発明９の「予約取得部」に相当するといえる。

したがって、引用発明の「予約情報受付部１３５」は、本願発明９の「店舗にてサービスの提供を受ける利用者の前記サービスの予約に関し、予約日時を含み、前記サービスの一部として前記利用者が事前に注文する事前注文サービスに関する事前注文情報を含まない予約情報を取得する予約取得部」と、「店舗にてサービスの提供を受ける利用者の前記サービスの予約に関し、予約日時を含み、予約情報を取得する予約取得部」である点で共通する。

ウ 引用発明の「事前注文情報受付部１３８」は、事前注文情報を取得するものであるといえるから、本願発明９の「事前注文取得部」に相当するといえる。また、引用発明において、利用者がサービスの提供を受ける前に事前注文情報を受け付けていることは明らかである。

したがって、引用発明の「事前注文情報受付部１３８」は、本願発明９の「前記予約確認画面における操作に基づいて、前記事前注文情報を、前記利用者が前記サービスの提供を受ける前に取得する、事前注文取得部」と、「前記事前注文情報を、前記利用者が前記サービスの提供を受ける前に取得する、事前注文取得部」である点で共通する。

エ 引用発明において、「店舗装置１」は、「予約情報受付部１３５」、「事前注文情報受付部１３８」を備えているから、上記ア－ウを踏まえると、本願発明９と引用発明は、「予約取得部と、事前注文取得部と、を備える、予約管理装置」である点で一致する。

したがって、本願発明９と引用発明との間には、次の一致点、相違点があるといえる。

（一致点）

「店舗にてサービスの提供を受ける利用者の前記サービスの予約に関し、予約日時を含み、予約情報を取得する予約取得部と、

事前注文取得部であって、

前記事前注文情報を、前記利用者が前記サービスの提供を受ける前に取得する、事前注文取得部と、を備える、予約管理装置。」

（相違点１）

予約情報において、本願発明９では、「前記サービスの一部として前記利用者が事前に注文する事前注文サービスに関する事前注文情報を含まない」のに対し、引用発明では、このような構成について特定されていない点。

（相違点２）

事前注文取得部において、本願発明９では、「前記予約日時に応じた所定のタイミングにおいて、予約確認画面を表示させるための予約確認情報を利用者端末に送信」するのに対し、引用発明では、このような構成について特定されていない点。

（相違点３）

前記事前注文情報を、前記利用者が前記サービスの提供を受ける前に取得することにおいて、本願発明９では、「前記予約確認画面における操作に基づいて」取得するのに対し、引用発明では、このような構成について特定されていない点。

（相違点４）

本願発明９では、「前記事前注文情報に基づいて、前記事前注文サービスの決済をするための決済処理部」を備えるのに対し、引用発明では、このような構成について特定されていない点。

（２）相違点についての判断

上記相違点１－４は、「事前注文」に関するものである点で互いに関連しているので、まとめて検討する。

上記第４の２の記載及びテイクアウト事前注文のビジネス慣行から、「事前注文の際に事前注文の決済を行うこと」は、本願の出願前において周知技術であったと認められる。

また、上記第４の４、５の記載から、「予約日時に応じた所定のタイミングにおいて、予約情報を確認させるメール等をユーザに送信し、必要であればユーザに予約情報を修正させること」は、本願の出願前において周知技術であったと認められる。

しかしながら、上記周知技術を考慮しても、引用文献２－５には、上記相違点１－４に係る本願発明９の構成、すなわち、予約時の予約情報には、サービスの一部として利用者が事前に注文する事前注文サービスに関する事前注文情報を含まず、予約日時に応じた所定のタイミングにおいて表示した予約確認画面における操作に基づいて、前記事前注文情報を、利用者が前記サービスの提供を受ける前に取得し、前記事前注文情報に基づいて、前記事前注文サービスの決済をすることについて記載も示唆もなく、この構成までが本願の出願前において周知技術であったともいえない。

そして、本願発明９は、上記相違点１－４に係る構成により、「店舗にてサービスの提供を受ける利用者による店舗への予約が適切に守られることを可能にする（本願明細書【００１３】参照。）」という格別の効果を奏するものであるから、このような構成とすることが単なる設計的事項であるとはいえない。

したがって、当業者といえども、引用発明及び引用文献２－５に記載された技術的事項から、上記相違点１－４に係る本願発明９の構成を容易に想到することはできない。

よって、本願発明９は、当業者であっても、引用発明及び引用文献２－５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

２ 本願発明１、１０について

本願発明１、１０は、上記相違点１－４に係る本願発明９の構成に対応する構成を実質的に備えるものであるから、本願発明９と同じ理由により、当業者であっても、引用発明及び引用文献２－５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

３ 本願発明２－８について

本願発明２－８は、本願発明１と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明及び引用文献２－５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

第６ むすび

以上のとおり、本願発明１－１０は、当業者が引用発明及び引用文献２－５に記載された技術的事項に基づいて容易に発明をすることができたものではない。

したがって、原査定の理由によっては、本願を拒絶することはできない。

また、他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。