【事件の表示】
　特願２０１７−　７１９５７「発注処理装置および発注処理方法」拒絶査定不服審判事件〔平成３０年　６月１４日出願公開、特開２０１８−　９２５６８、請求項の数（６）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、平成２９年３月３１日の出願であって、平成２９年１２月８日付で拒絶理由が通知され、平成３０年３月１日に意見書及び手続補正書が提出されたものの、同年４月９日付で拒絶査定（以下、「原査定」という。）がなされ、その謄本が送達された。
　これに対し、同年７月９日に拒絶査定不服審判の請求がされ、当審より、令和元年７月８日付で拒絶理由（「以下、「当審拒絶理由」という。）を通知したところ、同年９月２日に意見書及び手続補正書が提出されたものである。
　
第２　原査定の概要
　原査定（平成３０年４月９日付拒絶査定）の概要は、次のとおりである。
　
　本願請求項１−５に係る発明は、本願の出願前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった以下の引用文献Ａ及びＢに記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。
　
　引用文献Ａ：特開２００４−９４９４４号公報
　引用文献Ｂ：特開２００５−１８４５３号公報
　
第３　当審拒絶理由の理由
　当審拒絶理由の概要は、次のとおりである。
　
　本願請求項１−５に係る発明は、本願の出願前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった以下の引用文献１に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。
　
　引用文献１：特開２００７−１８３０４号公報
　
第４　本願発明
　本願請求項１−６に係る発明（以下、それぞれ「本願発明１」−「本願発明６」という。）は、令和元年９月２日提出の手続補正書により補正された特許請求の範囲の請求項１−６に記載された事項により特定される発明であり、それぞれ、以下のとおりの発明である。
　
【請求項１】（本願発明１）
　タクシーチケットを発行するチケット発行会社が有し、複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理装置であって、
　前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付部と、
　前記発注受付部が受け付けた発注の履歴を記録する発注履歴データベースと、
　前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの全ての発注の一覧である履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理部と、を備えた発注処理装置。
【請求項２】（本願発明２）
　前記履歴データは、所定の期間における前記チケット利用会社の前記複数の通信端末からの全ての発注の一覧である、請求項１に記載の発注処理装置。
【請求項３】（本願発明３）
　前記照会処理部は、前記複数の通信端末のうち、少なくとも特定の端末からの照会要求を受け付ける、請求項１または２に記載の発注処理装置。
【請求項４】（本願発明４）
　前記特定の端末は、前記チケット利用会社のタクシーチケットの発注状況を管理する発注責任者が使用する端末である、請求項３に記載の発注処理装置。
【請求項５】（本願発明５）
　前記照会処理部が前記発注履歴データベースを参照するための参照条件を受け付ける参照条件受付部をさらに備え、
　前記照会処理部は、前記参照条件受付部が受け付けた前記参照条件に従って取得した履歴データを前記チケット利用会社に送信する、請求項１〜４のいずれかに記載の発注処理装置。
【請求項６】（本願発明６）
　タクシーチケットを発行するチケット発行会社が有する発注処理装置によって、複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理方法であって、
　前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付ステップと、
　前記発注受付ステップにおいて受け付けた発注の履歴を発注履歴データベースに記録する発注履歴記録ステップと、
　前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの全ての発注の一覧である履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理ステップと、
を備えた発注処理方法。
　
第５　引用文献の記載及び引用発明
１　引用文献１の記載事項
　引用文献１には、以下の事項が記載されている（下線は、当審で付した。以下同じ。）。
　
【００１４】・・・タクシーチケット処理システム１は、チケット申請端末１０、チケット申請サーバ２０、チケット生成システム３０、携帯電話機４０、タクシー装置５０、データ管理サーバ６０、チケット決済サーバ７０などを備え、申請に応じて、タクシーの利用料金の精算に用いられるタクシーチケットとなるチケットデータを生成し、その利用について処理を行うシステムである。
【００１５】 
チケット申請端末１０
申請者が入力するチケット申請情報をチケット申請サーバ２０へ送信する装置
【００１６】・・・
【００１７】チケット申請サーバ２０は、チケット生成システム３０と電話回線、光ケーブルその他の有線の通信回線、赤外線その他の無線の通信回線などの通信回線（図示しない。以下同じ。）を介して接続され、
チケット発券申請を管理するサーバ
申請者が属する企業が管理
チケット申請情報をチケット生成システム３０へ送信し、チケットデータの生成（タクシーチケットの発券）を依頼
【００１８】
  
チケット生成システム３０は
又はこの企業から委託された他の企業が管理している。
【００１９】
  
チケット生成部３２は、通信部３１がチケット申請サーバ２０から申請情報を受信し、チケット発券の依頼を受けた場合に、このチケット申請情報に基づいてチケットデータを生成する。
チケット生成部３２は、チケット申請情報及びチケットデータをタクシー会社選択部３３へ送るとともに、発券履歴ＤＢ３５へ登録する
【００２０】タクシー会社選択部３３は、タクシー会社情報ＤＢ３６に格納されているタクシー会社情報と（後述する図３参照。）、チケット生成部３２から受け取ったチケット申請情報に含まれる利用内容情報とに基づいてタクシー会社を選択する。例えば、乗車エリアが運行エリア内にあり、車種や利用目的、希望サービスにあったサービスを提供するタクシー会社や、料金の低額なタクシー会社を選択する。タクシー会社選択部３３は、選択したタクシー会社の識別情報を、発券履歴ＤＢ３５へ登録する（後述する図２参照。）。
【００２１】
チケット提供部３４は、チケット生成部３２から受け取ったチケット申請情報に含まれる配信先情報のメールアドレス宛（携帯電話機４０のメールアドレス宛）に、利用者識別情報、申請者識別情報、チケットＩＤ、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）、生成した認証情報などを含む電子メールを送信する。ＵＲＬは、タクシーチケットアプリケーションのダウンロード用サイトのインターネット上の位置を示している。
チケット提供部３４は、携帯電話機４０からチケットデータ提供要求を受信し、携帯電話機４０の利用者の認証ができた場合に、チケットデータ及びタクシー会社情報とを含むタクシーチケットアプリケーションを携帯電話機４０へ送信する。
　
「【００２２】
  図２は、発券履歴ＤＢ３５に格納されている発券履歴情報を説明するための図である。
  図２に示すように、
発券履歴ＤＢ３５
チケットＩＤ
タクシー会社選択部３３が選択したタクシー会社を示すタクシー会社識別情報
発券履歴情報
　
「【００２６】タクシー装置５０は、携帯電話機４０と通信を行い、電子署名に基づいてチケットデータの正当性（認証及び完全性）の検証、利用料金の算出、利用料金及びチケットデータに基づいて利用料金の後日決済のための支払処理などを行う。タクシー装置５０は、運行中に、乗車時からの運行距離及び時間に基づいて利用料金を算出し、現在地検出装置によって検出される位置を記録し、運行ルートとして記憶する。タクシー装置５０は、利用実績情報を生成し、データ管理サーバ６０、チケット決済サーバ７０などに送信し、支払処理を行う。
利用実績情報
使用されたチケットデータのチケットＩＤ
【００２７】データ管理サーバ６０は、通信回線を介して、タクシー装置５０、チケット決済サーバ７０などと通信を行うことが可能であって、タクシー会社におけるデータ処理を管理するサーバである。また、データ管理サーバ６０は、タクシー装置５０へ指示などを送信し、タクシー装置５０から現在地を示す情報を受信するなど、各タクシーを管理する。データ管理サーバ６０は、タクシー装置５０から利用実績情報を受信し、タクシーＩＤごとに記憶し、管理する。データ管理サーバ６０は、記憶している利用実績情報におけるチケットデータによって支払処理が行われた利用料金を定期的に集計し、集計結果を決済代行会社のチケット決済サーバ７０へ送信し、この料金の支払を要求する。
【００２８】チケット決済サーバ７０は、通信回線を介して、チケット生成システム３０、タクシー装置５０、データ管理サーバ６０などと通信を行うことが可能であって、チケットデータによるタクシー料金支払いの決済を行うサーバであって、企業に代わって決済を行う決済代行会社によって管理されている。チケット決済サーバ７０は、チケット生成システム３０から受信する発券履歴情報を記憶し、
タクシー装置５０から利用実績情報を受信した場合に、チケットＩＤで対応する発券履歴情報と照らし合わせ
　
「【００３５】
（変形例）
【００３６】タクシーチケット処理システム１は、携帯端末として携帯電話機４０を備えているがこれに限定されず、ＰＤＡなど他の携帯型の通信端末であってもよい。
  また、チケット生成システム３０は、配車依頼先情報として、配車依頼先の電話番号をタクシー会社ＤＢ３６に記憶しているが、これに限定されず、配車依頼を行うことができるサイトのＵＲＬなど、他の配車依頼先情報を記憶していてもよい。
  タクシーチケット処理システム１において、
チケット申請サーバ２０を企業が管理し
・・・
【００４０】タクシーチケット処理システム１において、
タクシー装置５０から、又は、データ管理サーバ６０を介して利用実績情報をチケット生成システム３０へ送信し、チケット生成システム３０がこれをデータベース化して記憶していてもよい
企業のチケット申請サーバ２０などからの利用についての問い合わせに対して適当な利用実績情報を提供するなど、企業側の利便性を向上することが可能となる
　
２　引用発明の認定
　以上の記載からみて、引用文献１には、「チケットの申請者が属する企業」と「この企業から委託された他の企業」（【００１８】）のうち後者の企業が管理する「チケット生成システム」の変形例として、「タクシー装置」から「データ管理サーバ」を介して送信された「利用実績情報」を「チケット生成システム」が「データベース化して記憶」するもの（【００４０】）について、次の発明（以下、「引用発明」という。）が記載されている。
　
「チケット申請端末、チケット申請サーバ、チケット生成システム、携帯電話機、タクシー装置、データ管理サーバ、チケット決済サーバなどを備え、申請に応じてタクシーチケットとなるチケットデータを生成し、その利用について処理を行うシステム（【００１４】、図１）であって、
　チケット申請サーバは、企業により管理されるものであり（【００１７】、【００３６】）、
チケット申請端末からのチケット申請情報をチケット生成システムへ送信し
　チケット生成システムは、チケットの申請者が属する企業から委託された他の企業が管理するものであって（【００１８】）、通信部、チケット生成部、タクシー会社選択部、チケット提供部、発券履歴ＤＢ、タクシー会社情報ＤＢなどを備えたものであり（【００１８】）、
　通信部は、
チケット通信サーバからチケット申請情報を受信し
通信部が申請情報を受信してチケット発券の依頼を受けた場合
チケット申請情報及びチケットデータをタクシー会社選択部へ送るとともに発券履歴ＤＢへ登録
　タクシー会社選択部は、タクシー会社情報ＤＢとチケット申請情報に含まれる利用内容情報とに基づいてタクシー会社を選択し、選択したタクシー会社の識別情報を発券履歴ＤＢへ登録し（【００２０】）、
　チケット提供部は、チケット申請情報に含まれる配信先情報のメールアドレスである携帯電話機のメールアドレス宛に、利用者識別情報、申請者識別情報、チケットＩＤ、ＵＲＬ、生成した認証情報などを含む電子メールを送信し、携帯電話からチケットデータ提供要求を受信し、携帯電話機の利用者認証ができた場合に、チケットデータ及びタクシー会社情報を含むタクシーチケットアプリケションを携帯電話機に送信し（【００２１】）、
　タクシー装置は、携帯電話機と通信を行い、運行中に利用料金を算出し、現在地検出装置によって検出される位置を記録し、利用実績情報を生成し、データ管理サーバやチケット決済サーバなどに送信して支払い処理を行い（【００２６】）、
　
データ管理サーバは、タクシー装置から利用実績情報を受信し
利用料金を定期的に集計して
料金の支払いを要求
　チケット決済サーバは、企業に代わって決済を行う決済代行会社によって管理されており、チケット生成システムから受信する発券履歴情報を記憶し、タクシー装置から利用実績情報を受信した場合に、対応する発券履歴情報と照らし合わせ、正当にチケットデータが使用されたかを確認し、データ管理サーバから利用料金の集計結果を受信し、記憶している利用実績情報と照らし合わせ、支払額の正当性を確認し、タクシー会社へ利用料金を支払い、利用料金の決済を行い、更に、利用内容、タクシー会社に支払った利用料金、支払い代行サービス料金をチケット申請サーバに通知し、これらの料金の支払いを要求し（【００２８】）、
　企業は、この要求に対して
チケット生成システムの発券履歴ＤＢ内の情報を参照し、支払額の正当性を確認し、決済代行会社へ料金を支払う
　タクシー装置からデータ管理サーバを介して利用実績情報をチケット生成システムへ送信し、チケット生成システムがこれをデータベース化して記憶することで、チケット生成システムにおいて、不正利用の検出が可能となるとともに、
企業のチケット申請サーバなどからの利用についての問い合わせに対して適当な利用実績情報を提供する
　タクシーチケット処理システム。」
　
第６　対比、判断
１　本願発明１について
（１）対比
ア　引用発明における「タクシーチケット（タクシーチケットアプリケション）」は、タクシーチケットとして「発券」されるものであって、本願発明１の「タクシーチケット」に相当するといえる。そして、引用発明におけるタクシーチケットの「発券」と「発券」のための「申請」は、それぞれ、本願発明１におけるタクシーチケットの「発行」と発行のための「発注」に相当する。（「タクシーチケット」の文言は、もともとは「チケット」という用語で有体物を示していたとしても、本願出願時においては有体物（本願明細書段落【００２１】）に限定して用いられる用語ではない。この点、引用文献１のみならず、引用文献１で引用する「特開２００３−２９６７６７号においても、有体物でないものについて「タクシーチケット」の用語が用いられている。）
　
イ　引用発明の「チケットの申請者が属する企業」、「チケット申請端末」は、本願発明１の「チケット利用会社」、「チケット利用会社の通信端末」に相当する。また、引用発明の「チケットの申請者が属する企業から委託された他の企業」は、チケット生成システムを管理しており、本願発明１の「チケット発行会社」に相当する。
　
ウ　引用発明の「チケット生成システム」の「通信部」は、チケット利用会社の通信端末からのチケット申請情報の受信によってタクシーチケットの発注を受け付けるものであり、本願発明１の「発注受付部」に相当する。
　引用発明の「発券履歴ＤＢ」は、受信したチケット申請情報が登録されて受け付けた発注の履歴が記録されるものであるから、本願発明１の「発注履歴データベース」に相当する。
　
エ　引用発明の「チケット生成システム」は、発注受付部と発注履歴データベースを備えるとともに、発注されたチケットを提供するチケット提供部を備えてこれを発行するものであり、チケットの発注を処理する「発注処理装置」であるといえる。
　さらに、引用発明では、この発注処理装置において、決済代行会社への料金の支払いにあたって支払額の正当性を確認するために「発券履歴ＤＢ」の情報を企業に参照させるとともに、「企業のチケット申請サーバなど」からの「利用についての問い合わせ」に対して「データベース化」された「利用実績情報」によって「適当な利用実績情報」を提供するものであるため、この「利用についての問い合わせ」は、本願発明１の「チケット利用会社からの発注履歴の照会要求」に相当するものである。
　このことから、引用発明は、チケット利用会社からの発注履歴の照会要求によって取得される履歴データが「全ての発注の一覧」であるとはされていないものの、「チケット利用会社からの発注履歴の照会要求」に応じて「発注」の「履歴データ」を「取得し」、これを「チケット利用会社に送信する」ものであるということができ、この点において、本願発明１の「照会処理部」に対応する機能手段を備えたものであるといえる。
　
オ　してみると、本願発明１と引用発明との一致点は、次のとおりである。
　
＜一致点＞
　タクシーチケットを発行するチケット発行会社が有し、複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理装置であって、
　前記チケット利用会社の通信端末からタクシーチケットの発注を受け付ける発注受付部と、
　前記発注受付部が受け付けた発注の履歴を記録する発注履歴データベースと、
　前記チケット利用会社からの発注履歴の照会要求に応じて、前記発注履歴データベースを参照して、前記チケット利用会社の前記複数の通信端末からの発注の履歴データを取得し、当該履歴データを前記チケット利用会社に送信する照会処理部と、
を備えた発注処理装置
　
カ　そして、両者の相違点は、次のとおりである。
　
＜相違点＞
　本願発明１では、発注履歴の照会要求に応じて「発注履歴データベースを参照」し、発注の履歴データとして「全ての発注の一覧」を取得するのに対し、引用発明では、「データベース化」された「利用実績情報」によって発注の履歴データとして「適当な利用実績情報」を取得しており、「全ての発注の一覧」であるとされていない点
　
（２）　判断
　引用文献１において、「
利用実績情報」が「発券履歴ＤＢ」の「発券履歴情報」と同様に「チケットＩＤ」を含み（引用文献１の段落【００２２】【００２６】）、この「チケットＩＤ」によって「発券履歴情報」と照らし合わせられる（引用文献１の段落【００２８】）ものである旨が記載されており、これらの記載からみて、「利用実績情報」が「発券履歴情報」と同様に「チケットＩＤ」をキーとして格納することが可能な情報であって、「利用実績情報」の「データベース化」にあたって「
　しかしながら、引用文献１における照会は、「企業側の利便性を向上することが可能となる」ように「適当な利用実績情報」を提供（引用文献１の段落【００４０】）するためのものであって、あくまで「利用に対する問い合わせ」であるから、利用されていない分を含めた「全ての発注の一覧」を取得するようにこれを変更することが動機付けられることはない。この点、本願における発注履歴の照会要求は、「発注責任者」において「タクシーチケットが漏れなく発注されているか否か」の確認のためにも行われるものであるところ（本願明細書【００７６】）、引用文献１における照会は、このような確認のために用いることが想定されておらず、このような確認のために用いることができるように照会の内容を変更することが動機付けられることもない。
　してみると、上記の相違点について容易想到であるとすることはできないから、本願発明１は、当業者であっても引用発明に基づいて容易に発明をすることができたものであえるとはいえない。
　
２　本願発明２−本願発明５について
　本願発明２−本願発明５も、本願発明１と同様に上記相違点に係る構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても引用発明に基づいて容易に発明をすることができたものとはいえない。
　
３　本願発明６について
　本願発明６は、本願発明１に対応する方法発明であり、上記相違点に係る構成に対応する構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても引用発明に基づいて容易に発明をすることができたものとはいえない。
　
第７　原査定についての判断
　本願発明１−本願発明５は、「タクシーチケットを発行するチケット発行会社が有し、複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理装置」であり、本願発明６は、「タクシーチケットを発行するチケット発行会社が有する発注処理装置によって、複数の通信端末を有するチケット利用会社からのタクシーチケットの発注を処理する発注処理方法」であるところ、原査定が引用する引用文献Ａ及び引用文献Ｂは、いずれも、「タクシーチケットを発行するチケット発行会社が有するものである「発注処理装置」における「複数の通信端末を有するチケット利用会社からのタクシーチケットの発注」の「処理」に係る技術的事項を記載するものといえない。
　本願発明１−本願発明６は、「チケット利用会社のタクシーチケットの発注状況を管理するための事務作業の負担」の「軽減」のため（本願明細書段落【０００７】【０００８】）に、チケット利用会社からチケット発行会社へのタクシーチケットの発注履歴の照会要求を可能とするものであり、本願発明１−本願発明６の課題は、タクシーチケット以外のチケットにおける課題とは異質のものであるところ、引用文献Ａは、旅行代理店等が発券する交通機関やホテル等のチケットについての予約や購入についてのものであってタクシーチケットを取り扱うものでなく、本願発明１−本願発明６の課題の前提を欠くものである。このことを踏まえれば、引用文献Ｂに「チケット」に「タクシーチケット」が含まれる旨の記載があっても、引用文献Ａを主引用発明として本願発明１−本願発明６の進歩性を否定することはできない。
　
第８　むすび
　以上のとおり、原査定の理由によって、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。