【事件の表示】
　特願２０１７−１２７５８７「カーシェアリングシステム及びカーシェアリング方法」拒絶査定不服審判事件〔平成３１年　１月２４日出願公開、特開２０１９−　１２３３８、請求項の数（１２）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、平成２９年６月２９日の出願であって、令和元年６月５日付けで拒絶理由通知がされ、令和元年８月９日に手続補正がされ、令和２年１月２３日付けで拒絶査定（原査定）がされ、これに対し、令和２年４月２２日に拒絶査定不服審判の請求がされると同時に手続補正がされ、令和２年６月２２日付けで前置報告がされ、令和３年１月１４日付けで拒絶理由通知がされ、令和３年３月１７日に手続補正がされたものである。
第２　本願発明について
１　本願発明
　本願請求項１〜１２に係る発明（以下、それぞれ「本願発明１」〜「本願発明１２」という。）は、令和３年３月１７日の手続補正で補正された特許請求の範囲の請求項１〜１２に記載された事項により特定される発明であり、本願発明１は以下のとおりの発明である。
「【請求項１】
　複数人によりシェアされる車両の機器を、既設の電子キーと同様の無線による処理を経るＩＤ照合を通じて操作可能とするキー機能部と、
　携帯端末で前記機器を操作するにあたり、外部で生成された鍵情報を携帯端末経由で取得し、前記鍵情報の認証が成立しつつ使用が予約時間内であれば、前記キー機能部を有効にして、前記車両の機器を操作可能とするユーザ認証機能部と、を備えたカーシェア装置を有し、
　前記鍵情報は、使用が１度のみが許可されたワンタイムキーからなり、前記カーシェア装置が個々に有する固有のカーシェア装置固有鍵によって暗号化されており、
　前記携帯端末は、ユーザ認証鍵を用いて前記カーシェア装置と暗号通信を行い、
　前記ユーザ認証機能部は、前記鍵情報が登録済みの携帯端末との通信において、前回の通信接続時に使用していた旧ユーザ認証鍵により認証を行い、当該認証が成立すれば、旧ユーザ認証鍵を新ユーザ認証鍵に更新することを特徴とするカーシェアリングシステム。」
　なお、本願発明２〜１２の概要は以下のとおりである。
　本願発明２〜１１は、本願発明１を減縮した発明である。
　本願発明１２は、本願発明１に対応する方法の発明であり、本願発明１とカテゴリ表現が異なるだけの発明である。
２　拒絶の理由
（１）原査定の拒絶の理由
　原査定（令和２年１月２３日付け拒絶査定）の拒絶の理由の概要は次のとおりである。
　請求項１〜１４に係る発明は、引用文献１に記載された発明及び引用文献２〜４に記載された周知技術から、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
＜引用文献等一覧＞
１.特開２０１３−２５７６５３号公報
２.特開２０１１−４４１１２号公報（周知技術を示す文献）
３.特開２０１６−２０８４９４号公報（周知技術を示す文献）
４.特開２０１２−２２９５６０号公報（周知技術を示す文献）
（２）当審の拒絶の理由
　当審の拒絶の理由（令和３年１月１４日付け拒絶理由通知に係る拒絶の理由）の概要は次のとおりである。
ア　この出願は、特許請求の範囲の請求項１〜１２の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。
　請求項１、１２の「鍵情報」を「ユーザ認証鍵として使用」する点は、発明の詳細な説明に記載されていない。
イ　この出願は、特許請求の範囲の請求項１〜１２の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
（ア）請求項１、１２の「前記鍵情報は、ユーザ認証鍵として使用が１度のみが許可されたワンタイムキーからなり」という記載における、「鍵情報」と「ユーザ認証鍵」との関係が明確でない。
（イ）請求項１、１２に記載されている、「前回の通信接続時に使用していた旧ユーザ認証鍵」の意味するものが明確でない。
第３　引用文献、引用発明等
１　引用文献１について
　原査定の拒絶の理由に引用された引用文献１（特開２０１３−２５７６５３号公報）には、次の事項が記載されている。（下線は、当審が付与した。以下同じ。）
「【技術分野】
【０００１】
　本発明は、カーシェアリングシステムに関する。
【背景技術】
【０００２】
　近年、
車両を複数の利用者で共用するカーシェアリング
「【発明が解決しようとする課題】
【０００６】
　従来のカーシェアリングシステムをはじめとする移動体のシェアシステムでは、利用開始時および利用終了時に、車両側とセンタが通信を行う必要があった。例えば、利用開始時には、車両に乗車しようとしている者が、予約を行っている正規利用者であることを確認する必要があり、利用終了時には、利用時間内に既定の場所に返却されたかを確認する必要がある。そのため、車両とセンタとの間で必ず通信が発生する。
【０００７】
　しかし、車両とセンタとの間で必須とされる通信が、システム構築の妨げとなるケースがある。例えば、ビルの地下駐車場などの電波が入りにくい場所では、センタとの確実な通信を行うことができないため、利用の需要があってもステーションを設置することができない。また、車両が通信装置を搭載することでコストが上昇するという欠点がある。」
「【０００９】
　この問題を解決するためには、車両とセンタとが直接通信を行うことなく、かつ、センタが、車両の状態を制御することができるカーシェアリングシステムを構築する必要がある。
【００１０】
　本発明は上記の問題点を考慮してなされたものであり、車両にサーバとの通信手段を持たせることなく、サーバが車両に対して処理要求を送信することができるカーシェアリングシステムを提供することを目的とする。」
「【００２７】
（第一の実施形態）
＜システム構成＞
　第一の実施形態に係るカーシェアリングシステムについて、システム構成図である図１を参照しながら説明する。第一の実施形態に係る
カーシェアリングシステムは、利用者が所持するユーザ端末１０、管理サーバ２０、車両に搭載された車載端末３０から構成されるシステムである
【００２８】
　ユーザ端末１０、管理サーバ２０、車載端末３０は、いずれもＣＰＵ、主記憶装置、補助記憶装置によってそれぞれ構成することができる。補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、ＣＰＵによって実行されることで、図１に図示した各手段が機能する。なお、図示した機能の全部または一部は、専用に設計された回路を用いて実行されてもよい。」
「【図１】
」
　図１の記載によれば、ユーザ端末１０が入出力部１２を有すること、車載端末３０が制御部３１を有すること、がみてとれる。
「【００２９】
　まず、ユーザ端末１０について説明する。
ユーザ端末１０は、利用者が所持している携帯型コンピュータであり
ユーザ端末１０は携帯電話やスマートフォンなどであってもよい
　ユーザ鍵記憶部１１は、利用者に固有な鍵であるユーザ鍵を記憶する手段である。ユーザ鍵の詳細、および生成方法については後述する。
【００３０】
　
入出力部１２は、利用者に情報を提示し、利用者からの入力を受け付ける手段である
　サーバ通信部１３は、管理サーバ２０と通信を行うための通信手段であり、本発明における車両指定情報送信手段である。本実施形態では、携帯電話網を利用したパケット通信によって車両との通信を行うが、通信を行うことができれば、例えばＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）や無線ＬＡＮなどの携帯電話網以外の手段を用いてもよい。」
「【００３７】
　次に、
車載端末３０
　
制御部３１
　
車両鍵記憶部３２
車両に対応する秘密鍵を記憶する
車両鍵記憶部３２に記憶される秘密鍵は、管理サーバが有する車両鍵記憶部２４にも記憶されている
　
端末通信部３３
「【００３９】
＜
車両貸出時の処理
　次に、ユーザ端末１０、管理サーバ２０、および車載端末３０の車両貸出時における処理フローチャート図を参照しながら、利用者が車両に乗車し、運転を開始するまでの処理について説明する。
　図３は、車両貸出時にユーザ端末および管理サーバが行う処理フローチャートである。利用者が、車両を予約する操作をユーザ端末１０で行うことで、図３のフローチャートが開始される。なお、
ステップＳ１１からＳ１３が、ユーザ端末１０が行う処理であり
ステップＳ２１からＳ２６が、管理サーバ２０が行う処理である
【００４０】
　まず、入出力部１２が、
利用者から予約情報の入力を受け付ける（Ｓ１１）
　次に、制御部１５が、
入力された予約情報を、ユーザ鍵記憶部１１に記憶されているユーザ鍵を用いて暗号化する（Ｓ１２）
暗号化した情報を管理サーバ２０へ送信する（Ｓ１３）
【００４１】
　
ステップＳ２１では、制御部２３が、端末通信部２２を通して、ユーザ端末１０から送信された情報を受信する
　次に、制御部２３が、受信した情報を復号できるユーザ鍵が、ユーザ鍵記憶部２１に記憶されているかをチェックする（Ｓ２２）。本実施形態では、ユーザ端末１０がログイン情報を事前に管理サーバに送信し、どの利用者のユーザ鍵を使用すべきか、という情報を提供する。復号可能なユーザ鍵が無い場合、正規の利用者ではないと判断し、処理は終了する。
【００４２】
　復号可能なユーザ鍵を取得できた場合、
制御部２３は、受信した情報を対応するユーザ鍵で復号し、予約情報を取得する（Ｓ２３）
　なお、予約情報を送信する際は、ユーザ端末が取得した現在時刻を同時に送信し、管理サーバが取得した現在時刻と照合し、両者が一致している場合にのみ動作を継続するようにしてもよい。このようにすることで、ユーザ端末の時刻が正確であることを確認することができる。
【００４３】
　次に、制御部２３は、
取得した予約情報から、該当する車両に対する処理要求（以降、車両制御情報と称する）を生成する（Ｓ２４）
車両制御情報とは、車両を利用可能にするための情報である
車両制御情報は、制御コマンドと有効時間の二つのフィールドからなる
制御コマンドには、車両のドアを開錠するコマンドが定義されており
有効時間には、制御コマンドが有効となる時間が定義されている
【００４４】
　次に、
制御部２３は、生成した車両制御情報を、車両鍵記憶部２４が記憶している車両鍵で暗号化する（Ｓ２５）
ここで使用される車両鍵は、予約対象の車両に対応する鍵である
暗号化した車両制御情報をユーザ端末１０へ送信する（Ｓ２６）
【００４５】
　なお、暗号化した車両制御情報をユーザ端末１０へ送信する際は、管理サーバに送信された予約が正しく成立したことを示す情報（以降、予約確認情報と称する）を生成し、同時にユーザ端末１０へ送信してもよい。予約確認情報は、対応するユーザ鍵によって暗号化され、端末通信部２２を通してユーザ端末１０へ送信される。そして、ユーザ鍵記憶部１１に記憶されたユーザ鍵によって復号され、入出力部１２を通して利用者に提示される。
　
以上の処理が、利用者が車両を利用する時刻までに実行される
「【図６】
」
　図６の記載によれば、車両開錠画面が開錠ボタンを含むことがみてとれる。
「【００４６】
　一方、ユーザ端末１０に記憶された、暗号化された車両制御情報は、利用者が車両を利用する際に車載端末３０へ送信される。
図６は、入出力部１２を通して表示される車両開錠画面の例である
利用者が、車両の近くで開錠ボタンを押すと、車両通信部１４から端末通信部３３へ暗号化された車両制御情報が送信される
　
図７は、車載端末３０が車両貸出時に行う処理フローチャートである。ユーザ端末１０が、暗号化された車両制御情報を送信することで、図７のフローチャートが開始される
【００４７】
　
ステップＳ３１では、端末通信部３３が、ユーザ端末１０から送信された情報を受信する
制御部３１が、車両鍵記憶部３２に記憶されている車両鍵を用いて情報の復号を行う（Ｓ３２）。これにより、車載端末は、管理サーバによって生成された車両制御情報を取得することができる
　次に、
制御部３３が、取得した車両制御情報を実行する
車両制御情報は、定義された有効時間内でのみ実行が可能であり
現在時刻が、定義された有効時間内である場合、ドアを開錠するコマンドが処理され
　なお、【００４７】の「制御部３３」が「制御部３１」の誤記であることは明らかである。
「【００５１】
　また、
ステップＳ３２では、車載端末が有している車両鍵で受信した情報を復号し、車両制御情報を取得したが、復号の結果が想定と異なっていた場合は情報を破棄し、処理を中断してもよい
　以上の記載によれば、引用文献１には、次の発明（以下、「引用発明」という。）が記載されている。
「ユーザ端末、管理サーバ、車両に搭載された車載端末から構成され、車両を複数の利用者で共用するカーシェアリングシステム（【０００２】、【００２７】）であって、
ユーザ端末は、利用者が所持している携帯型コンピュータであり、携帯電話やスマートフォンなどであってもよく（【００２９】）、
車載端末は、制御部、車両鍵記憶部、端末通信部を有し（【００３７】、【図１】）、
車両貸出時には（【００３９】〜【００４８】）、
利用者が車両を利用する時刻までに（【００４５】）、
ユーザ端末は、利用者から受け付けた予約情報を管理サーバへ送信し（【００３９】〜【００４０】）、
管理サーバは、予約情報から、車両のドアを開錠するコマンドが定義される制御コマンドと制御コマンドが有効となる時間が定義される有効時間からなる車両制御情報を生成し、予約対象の車両に対応する秘密鍵である車両鍵で暗号化して、ユーザ端末へ送信し（【００３９】、【００４１】〜【００４４】、【００３７】）、
利用者が車両を利用する際に（【００４６】）、
ユーザ端末の入出力部に表示される車両開錠画面の開錠ボタンをユーザが押すと、ユーザ端末は車両制御情報を車載端末へ送信し（【図１】、【００２９】〜【００３０】、【図６】、【００４６】）、
車載装置では（【００４６】）、
端末通信部が、ユーザ端末から送信された情報を受信し（【００４７】）、
制御部が、車両鍵記憶部に記憶されている車両鍵を用いて情報の復号を行うことで車両制御情報を取得し（【００４７】）、復号の結果が想定と異なっていた場合は情報を破棄して処理を中断し（【００５１】）、
制御部が、現在時刻が、車両制御情報に定義された有効時間内である場合、車両制御情報に定義される車両のドアを開錠するコマンドを処理する（【００４３】、【００４７】、【００３７】）、
カーシェアリングシステム。」
２　引用文献２について
　原査定の拒絶の理由に引用された引用文献２（特開２０１１−４４１１２号公報）には、次の事項が記載されている。
「【技術分野】
【０００１】
　本発明は、複数のユーザが車両を共同で利用するカーシェアリングシステムに関する。」
「【００２６】
　そして、この
カーシェアリングシステムでは、ドア錠を施解錠するためにユーザが携帯端末１ａの操作ボタン１１を所要に操作したとする
携帯端末１ａの制御部１６は、操作ボタン１１の操作を検知すると、キー側ローリングカウンタＲＣｋの値をインクリメントする
キー識別コードＩＤｋ及びキー側ローリングカウンタＲＣｋを含む施解錠信号を生成する
車載装置２０の
通信制御部２４では
互いの識別コードが一致している旨を判断すると、キー側ローリングカウンタＲＣｋの値と、メモリ２４ａに記憶されている車両側ローリングカウンタＲＣｃの値とを比較して、キー側ローリングカウンタＲＣｋの値が車両側ローリングカウンタＲＣｃの値よりも大きい旨を判断すると
　以上の記載によれば、引用文献２には、次の技術事項が記載されている。
「カーシェアリングシステムにおいて、携帯端末からドア錠を施解錠するとき、車載装置では、携帯端末から車載装置に送信される施解錠信号の含むカウンタ値を比較し、その比較結果を基に施解錠の可否を判断すること。」
３　引用文献３について
　原査定の拒絶の理由に引用された引用文献３（特開２０１６−２０８４９４号公報）には、次の事項が記載されている。
「【技術分野】
【０００１】
　本発明は、
車両を管理するシステム及び方法に関し
「【００６０】
　続いて、
ユーザ端末２０がドアのロック／アンロックを車両端末３０に対して要求する
ロック／アンロックの要求には、例えば、予約車両情報に含まれる「車両端末ＩＤ」、ロックの要求かアンロックの要求かを識別する「モード」、予約車両情報に含まれる現在日時を示す「日時」、及び、生成したデジタル署名、等の情報が含まれる
【００６１】
　そして、
車両端末３０が、ユーザ端末２０から受信したロック／アンロックの要求に含まれるデジタル署名の検証を、サーバ１０に対して要求する
【００６２】
　そして、サーバ１０が、車両端末３０から受信したデジタル署名を検証し（ステップＳ４４０）、検証結果を車両端末３０に送信する（ステップＳ４５０）。一実施形態において、
デジタル署名の検証は
特定した車両ＩＤと受信した日時との組合せに対応するユーザＩＤ（即ち、特定した車両ＩＤが識別する自動車を、受信した日時（現在日時）において予約しているユーザのユーザＩＤ）を予約管理テーブル５１ｃを参照して特定し、このユーザＩＤに対応する公開鍵をユーザ管理テーブル５１ｂを参照して特定する。そして、受信した日時と特定した公開鍵とを用いてデジタル署名を検証する
　以上の記載によれば、引用文献３には、次の技術事項が記載されている。
「車両を管理するシステムにおいて、ユーザ端末が車両端末に対してドアのロック／アンロックを要求する際に、要求に含まれるデジタル署名の検証のために、車両端末に対応する車両を予約しているユーザを特定すること。」
４　引用文献４について
　原査定の拒絶の理由に引用された引用文献４（特開２０１２−２２９５６０号公報）には、次の事項が記載されている。
「【技術分野】
【０００１】
　本発明は、既存の電子キーシステムのキー以外の端末を、同システムの１キーとして使用可能とするキー無線認証システムに関する。」
「【００２１】
　
車両１には、例えば電子キーシステム３の拡張機能の１つとして、電子キー２以外の端末（例えば携帯電話１７など）を車両キーとして使用可能とするキー無線認証システム１８が設けられている
【００２２】
　また、
キー無線認証システム１８
キー無線認証システム１８は、携帯電話１７と照合ＥＣＵ５とを、間接的にＩＤ認証させるシステムでもある
　以上の記載によれば、引用文献４には、次の技術事項が記載されている。
「車両の電子キーシステムの拡張機能として、電子キー以外の端末、例えば携帯電話と照合ＥＣＵとを間接的にＩＤ照合させて車両キーとして使用可能とするキー無線認証システム。」
５　引用文献５について
　前置報告に引用された引用文献５（特開２００６−１１２１１８号公報）には、次の事項が記載されている。
「【技術分野】
【０００１】
　本発明は、鍵のシャンク部の山谷形状に一致したときに解錠又は施錠を行う
機械的認証方式のシリンダ錠と
電子的認証方式の電子錠との両方を備えた錠装置
「【００２９】
　前述した実施形態では、予め電子鍵１１に記憶した識別コードと暗証コードとを変更せずに長期的に使用する錠装置として説明している。これでは、これら認証コードを長期的に使用するため、セキリティの面で低い。そこで、
施錠をするたびに、その後の解錠するときに必要な暗証コードを自動的に変更していく
【００３０】
　この例では、タグリーダ３０の代わりに、タグリーダ・ライタ４０を使用する。また、制御部４１は、乱数発生プログラムを記憶したＲＯＭ４２を備えており、また、制御部４１にはＲＡＭ４３が接続されている。ＲＡＭ４３は、生成するごとに識別コードに対応付けして暗証コードを記憶する。なお、図５に示す例では、図３で説明した同じ機構には同符号を付与して詳しい説明を省略する。
【００３１】
　
施錠操作は
電子鍵１１を挿入すると、機械的認証が行われ
識別コードと暗唱コードとを読み取り
電子認証を行う
電子認証が一致した場合には、暗証コードを生成する。生成した暗証コードは、識別コードに対応付けしてＲＡＭ４３に更新して記憶される
さらに、生成した暗証コードは、無線により無線ＩＣタグ１５に送られ、無線ＩＣタグ１５のＥＥＰＲＯＭ１９に更新して記録される
【００３２】
　解錠する場合には、図６（Ａ）に示すように、機械的認証の後に、電子鍵１１を解錠用認証位置まで回転させ、ここでタグリーダ・ライタ４０を作動して電子鍵１１の識別コードと、前回生成した暗証コードとを読み取り、これらをＲＡＭに記憶した識別コードと暗証コードとでそれぞれ比較して電子認証を行う。そして、両者が一致した場合には、ロックピン３２を退避位置に移動し、内筒２５の解錠位置への回転を許容する。なお、解錠位置への回転を許容した後には、タグリーダ・ライタ４０の作動をＯＦＦする。
これによれば、施錠するごとに暗証コードを生成するため、電子鍵１１のコピーを作成するのが難しく、また、鍵製造メーカーからの情報漏れがあっても問題はない
　以上の記載によれば、引用文献５には、次の技術事項が記載されている。
「機械的認証方式のシリンダ錠と、電子的認証方式の電子錠との両方を備えた錠装置において、電子鍵１１を挿入すると、機械的認証と、暗唱コードとによる電子認証を行い、電子認証が一致した場合には、暗証コードを生成して更新することにより、施錠をするたびに、その後の解錠するときに必要な暗証コードを自動的に変更していく装置。」
６　引用文献６について
　前置報告に引用された引用文献６（特開２００５−１５５２３６号公報）には、次の事項が記載されている。
「【技術分野】
【０００１】
　本発明は、共用部と専用部との双方における入退室を管理する鍵開閉管理システムに関する。」
「【００３４】
　居住者は、図２に示す
キーユニット３
【００３５】
　玄関ロビードア１０２の側部には
制御ユニット４ａ
【００３６】
　居住者は外部から帰って来ると、まず
玄関ロビー１０１の制御ユニット４ａ
キーユニット３を挿し込み、セットする
【００３７】
　次に、
制御ユニット４ａは
【００３８】
　続いて、制御ユニット４ａは、応答部４１が
ＩＤデータ３１と鍵開閉データ３２をキーユニット３から読み出す
【００３９】
　次に、制御ユニット４ａは、データ管理部４２に管理されているＩＤデータ３１と鍵開閉データ３２とを検索する。このとき制御ユニット４ａは、まず、読み出したＩＤデータ３１が有効であるかを判断する。判断の結果、ＩＤデータ３１が有効であれば、鍵開閉データ３２と照合する。
ＩＤデータ３１および鍵開閉データ３２がともに有効であれば、制御ユニット４ａは開閉管理手段であるロック機構５に信号を発信し、玄関ロビードア１０２を開けるか、または玄関ロビードア１０２をロックしているかんぬきを外すなどして、居住者の入室を許可する
【００４０】
　また同時に、制御ユニット４ａは、
解錠のつど、または建物管理者の随時の設定、あるいは、装置にあらかじめ設定されたスケジュールに従って
新しい鍵開閉データ３２を生成する
キーユニット３の鍵開閉データ１を新たな鍵開閉データ３２に書き換えるとともに、自身のデータ管理部４２にも記憶させる
　以上の記載によれば、引用文献６には、次の技術事項が記載されている。
「玄関ロビーの制御ユニットにキーユニットを挿し込みセットすると、ＩＤデータと鍵開閉データをキーユニットから読み出し、ＩＤデータおよび鍵開閉データがともに有効であれば、居住者の入室を許可し、解錠のつど、または建物管理者の随時の設定、あるいは、装置にあらかじめ設定されたスケジュールに従って、新しい鍵開閉データを生成し、キーユニットの鍵開閉データを新たな鍵開閉データに書き換えるとともに、自身のデータ管理部にも記憶させる、玄関ロビーの制御ユニット。」
第４　対比・判断
１　本願発明１について
（１）対比
　本願発明１と引用発明とを対比すると、次のことがいえる。
ア　カーシェアリングシステムについて
　利用者が所持している携帯型コンピュータであり、携帯電話やスマートフォンなどであってもよい引用発明の「ユーザ端末」は、本願発明１の「携帯端末」に相当し、カーシェアに係る装置である引用発明の「車載端末」は、本願発明１の「カーシェア装置」に相当する。
　また、これら端末や装置の外部である引用発明の「管理サーバ」は、本願発明１の「外部」に相当し、以上のものから構成される引用発明の「カーシェアリングシステム」は、本願発明１の「カーシェアリングシステム」に相当する。
イ　キー機能部について
　本願明細書には次の記載がある。
「【００２４】
　以下、カーシェアリングシステム及びカーシェアリング方法の一実施形態を図１〜図１３に従って説明する。
　図１に示すように、
車両１は、電子キー２との無線によりＩＤ照合を行って機器３の作動を実行又は許可する電子キーシステム４を備える
「【００３１】
　カーシェア装置３４は、車両１の電子キーシステム４のハード構成から独立しており、車両１に対し後付けされたものとなっている。
カーシェア装置３４は、例えば予約時間内のときのみ有効になる電子キーの位置付けであり、スペアキーと同様の扱いである
車両１の電子キーシステム４（照合ＥＣＵ９）は、カーシェア装置３４のキー機能の有効／無効が切り替えられることにより、車内に電子キーが出現したり消滅したりすると認識する
「【００３７】
　
カーシェア装置３４は、スマート通信ブロック５１を通じてカーシェア装置３４の通信網を介したＩＤ照合（本例はスマート照合）を実行するキー機能部５６を備える
キー機能部５６は、
電子キー２と同様の処理を経るＩＤ照合を通じて操作可能とする。
【００３８】
　カーシェア装置３４は、携帯端末３３で機器３を遠隔操作するときに携帯端末３３と通信を実行するユーザ認証機能部５７を備える。ユーザ認証機能部５７は、コントローラ５０に設けられている。ユーザ認証機能部５７は、携帯端末３３で機器３が操作されるにあたり、外部（本例はサーバ３２）で生成された鍵情報Ｋｄを携帯端末３３経由で取得し、鍵情報Ｋｄの認証が成立しつつ使用が予約時間内であれば、
キー機能部５６を有効にして、車両１の機器３を操作可能とする
　本願明細書の上記記載を参酌すれば、本願発明１の「複数人によりシェアされる車両の機器を、既設の電子キーと同様の無線による処理を経るＩＤ照合を通じて操作可能とするキー機能部」の「操作可能」とは、既設の電子キーが車内に存在する場合に、無線による処理を経るＩＤ照合がなされることで実行又は許可される、機器の操作が可能であることを含むものである。
　上記解釈に基づいて対比をする。
　複数の利用者で共用される引用発明の「車両」は、本願発明１の「複数人によりシェアされる車両」に相当し、引用発明の車両の「ドア」は、本願発明１の「複数人によりシェアされる車両の機器」に相当する。しかしながら、引用発明は、車両の機器が電子キーとの無線による処理を経るＩＤ照合を通じて「操作可能」となるものでないから、これに対応する、当該機器を「操作可能とする」構成を見いだすことはできない。
　以上のことから、引用発明と本願発明１とは、本願発明１が「複数人によりシェアされる車両の機器を、既設の電子キーと同様の無線による処理を経るＩＤ照合を通じて操作可能とするキー機能部」を備えるのに対し、引用発明はかかる構成を備えていない点で相違する。
ウ　ユーザ認証機能部について
　引用発明の、ユーザ端末の入出力部に表示される開錠ボタンをユーザが押すことで、車両のドアを開錠することは、本願発明１の「携帯端末で前記機器を操作する」ことに相当し、当該操作にあたり引用発明の車載端末の端末通信部がユーザ端末経由で取得する、管理サーバで生成され暗号化された車両制御情報は、本願発明１の「外部で生成された鍵情報」に相当する。
　そして、上記操作にあたり引用発明の車載端末の端末通信部がする、「外部で生成された鍵情報」の取得は、本願発明１の「携帯端末で前記機器を操作するにあたり、外部で生成された鍵情報を携帯端末経由で取得」に相当する。
　また、引用発明の車載端末の制御部の処理において、車両鍵を用いてする車両制御情報の復号の結果が想定と異なっていないことは、本願発明１の「前記鍵情報の認証が成立」することに相当し、現在時刻が車両制御情報に定義された有効時間内であることは、本願発明の「使用が予約時間内であ」ることに相当する。
　以上のことから、引用発明の「端末通信部」及び「制御部」と、本願発明１の「ユーザ認証機能部」とは、本願発明１の「ユーザ認証機能部」は「前記キー機能部を有効にして、前記車両の機器を操作可能とする」のに対し、引用発明の「制御部」は「車両制御情報に定義される車両のドアを開錠するコマンドを処理する」点で相違するものの、「携帯端末で前記機器を操作するにあたり、外部で生成された鍵情報を携帯端末経由で取得し、前記鍵情報の認証が成立しつつ使用が予約時間内であれば、」「前記車両の機器」の「操作」のための処理をする「ユーザ認証機能部」について共通する。
エ　鍵情報について
　引用発明の車両制御情報を暗号化する車両鍵は、車載端末の車両鍵記憶部に記憶されている車両に対応する秘密鍵であるから、本願発明１の「前記カーシェア装置が個々に有する固有のカーシェア装置固有鍵」に相当する。
　これによれば、引用発明の暗号化された「車両制御情報」と本願発明１の「鍵情報」とは、本願発明の「鍵情報」は「使用が１度のみが許可されたワンタイムキーからな」るのに対し、引用発明の暗号化された「車両制御情報」は当該構成を備えていない点で相違するものの、「前記鍵情報は、」「前記カーシェア装置が個々に有する固有のカーシェア装置固有鍵によって暗号化されており」について共通する。
オ　ユーザ認証鍵について
　本願発明１は、
「前記携帯端末は、ユーザ認証鍵を用いて前記カーシェア装置と暗号通信を行い、
　前記ユーザ認証機能部は、前記鍵情報が登録済みの携帯端末との通信において、前回の通信接続時に使用していた旧ユーザ認証鍵により認証を行い、当該認証が成立すれば、旧ユーザ認証鍵を新ユーザ認証鍵に更新する」
のに対し、引用発明はかかる構成を備えていない点で相違する。
　したがって、本願発明１と引用発明との間には、次の一致点、相違点があるといえる。
＜一致点＞
　携帯端末で複数人によりシェアされる車両の機器を操作するにあたり、外部で生成された鍵情報を携帯端末経由で取得し、前記鍵情報の認証が成立しつつ使用が予約時間内であれば、前記車両の機器の操作のための処理をするユーザ認証機能部、を備えたカーシェア装置を有し、
　前記鍵情報は、前記カーシェア装置が個々に有する固有のカーシェア装置固有鍵によって暗号化されている
カーシェアリングシステム。
＜相違点＞
（相違点１）
　本願発明１の「カーシェア装置」が「複数人によりシェアされる車両の機器を、既設の電子キーと同様の無線による処理を経るＩＤ照合を通じて操作可能とするキー機能部」を備えるのに対し、引用発明はかかる構成を備えていない点。
（相違点２）
　「カーシェア装置」が備える「ユーザ認証機能部」の「前記車両の機器の操作のための処理」として、本願発明１の「ユーザ認証機能部」は「前記キー機能部を有効にして、前記車両の機器を操作可能とする」のに対し、引用発明の「制御部」は「車両制御情報に定義される車両のドアを開錠するコマンドを処理する」点。
（相違点３）
　本願発明の「鍵情報」は、「使用が１度のみが許可されたワンタイムキーからな」るのに対し、引用発明の暗号化された「車両制御情報」は当該構成を備えていない点。
（相違点４）
　本願発明１は、
「前記携帯端末は、ユーザ認証鍵を用いて前記カーシェア装置と暗号通信を行い、
　前記ユーザ認証機能部は、前記鍵情報が登録済みの携帯端末との通信において、前回の通信接続時に使用していた旧ユーザ認証鍵により認証を行い、当該認証が成立すれば、旧ユーザ認証鍵を新ユーザ認証鍵に更新する」
のに対し、引用発明はかかる構成を備えていない点。
（２）相違点についての判断
　事案に鑑み、上記相違点４について検討する。
　引用発明は、ユーザ認証鍵を用いて携帯端末とカーシェア装置との暗号通信を行うものでなく、鍵情報が登録済みの携帯端末との通信において、前回の通信接続時に使用していた旧ユーザ認証鍵により認証を行い、当該認証が成立すれば、旧ユーザ認証鍵を新ユーザ認証鍵に更新するものでない。
　また、引用文献２〜６にも、ユーザ認証鍵を用いて携帯端末とカーシェア装置との暗号通信を行うこと、及び、鍵情報が登録済みの携帯端末との通信において、前回の通信接続時に使用していた旧ユーザ認証鍵により認証を行い、当該認証が成立すれば、旧ユーザ認証鍵を新ユーザ認証鍵に更新すること、の開示や示唆はなく、係る事項が周知技術であるとはいえない。
　また、本願発明１は、上記相違点４にかかる構成により、本願明細書の【０１３０】に記載の「携帯端末３３で車両１を遠隔操作する通信を行う度にユーザ認証鍵が更新されるので、車両使用に対するセキュリティ性を確保するのに一層有利となる。」という効果を奏するものである。
　したがって、上記相違点１〜３について判断するまでもなく、本願発明１は、当業者であっても引用発明、及び、引用文献２〜６に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
２　本願発明２−１１について
　本願発明２−１１も、１（２）に検討した相違点４に係る本願発明１の構成と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明及び引用文献２〜６に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
３　本願発明１２について
　本願発明１２は、本願発明１に対応する方法の発明であり、１（２）に検討した相違点４に対応する構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明及び引用文献２〜６に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
第５　原査定の拒絶の理由についての判断
　原査定の拒絶の理由は、請求項１〜１４に係る発明について、上記引用文献１に記載された発明、及び、引用文献２〜４に記載された周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないというものである。しかしながら、令和３年３月１７日の手続補正で補正された請求項１〜１２に係る発明は、上記の通り、引用文献１に記載された発明、及び、引用文献２〜４に記載された周知技術に基づいて、当業者が容易に発明をすることができたものでない。したがって、原査定を維持することはできない。
第６　当審の拒絶の理由についての判断
１　特許法第３６条第６項第１号について
　当審では、請求項１、１２の「鍵情報」を「ユーザ認証鍵として使用」する点は、発明の詳細な説明に記載されていないとの拒絶の理由を通知しているが、令和３年３月１７日の手続補正において、
「前記鍵情報は、使用が１度のみが許可されたワンタイムキーからなり、前記カーシェア装置が個々に有する固有のカーシェア装置固有鍵によって暗号化されており、
　前記携帯端末は、ユーザ認証鍵を用いて前記カーシェア装置と暗号通信を行い、」
と補正された結果、請求項１〜１２に係る発明は発明の詳細な説明に記載されたものとなり、この拒絶の理由は解消した。
２　特許法第３６条第６項第２号について
（１）当審では、請求項１、１２の「前記鍵情報は、ユーザ認証鍵として使用が１度のみが許可されたワンタイムキーからなり」という記載における、「鍵情報」と「ユーザ認証鍵」との関係が明確でないとの拒絶の理由を通知しているが、令和３年３月１７日の手続補正において、
「前記鍵情報は、使用が１度のみが許可されたワンタイムキーからなり、前記カーシェア装置が個々に有する固有のカーシェア装置固有鍵によって暗号化されており、
　前記携帯端末は、ユーザ認証鍵を用いて前記カーシェア装置と暗号通信を行い、」
と補正された結果、請求項１〜１２に係る発明は明確となり、この拒絶の理由は解消した。
（２）当審では、請求項１、１２に記載されている、「前回の通信接続時に使用していた旧ユーザ認証鍵」の意味するものが明確でないとの拒絶の理由を通知しているが、令和３年３月１７日の手続補正において、「前記携帯端末は、ユーザ認証鍵を用いて前記カーシェア装置と暗号通信を行い」と特定する補正がされた結果、請求項１〜１２に係る発明は明確となり、この拒絶の理由は解消した。
第７　むすび
　以上のとおり、原査定及び当審の拒絶の理由によって、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。