• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06Q
管理番号 1273405
審判番号 不服2012-1067  
総通号数 162 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2013-06-28 
種別 拒絶査定不服の審決 
審判請求日 2012-01-19 
確定日 2013-05-02 
事件の表示 特願2006- 41712「注文決済システムおよび注文決済機能を有する携帯端末」拒絶査定不服審判事件〔平成19年 8月30日出願公開、特開2007-219959〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は、平成18年2月18日の出願であって、平成22年12月28日付けの拒絶理由通知に応答して、平成23年2月17日付けで手続補正がなされ、再度、平成23年5月24日付けで拒絶理由が通知され、平成23年7月26日付けで手続補正されたが、平成23年11月7日付けで拒絶査定がなされた。これに対して、平成24年1月19日に拒絶査定不服審判が請求されるとともに、同日付けで手続補正がなされたものである。
そして、当審から平成24年7月26日付けで審尋がなされ、平成24年9月21日付けで回答書が提出され、更に、当審から平成24年11月1日付けで拒絶理由が通知され、平成24年12月27日付けで手続補正されたものである。

2.本願発明
本願請求項1に係る発明は、平成24年12月27日付けで手続補正された特許請求の範囲の請求項1に記載された次のとおりのものと認める。(以下、「本願発明」という。なお、下線は、補正箇所を示す。)
「【請求項1】
注文処理アプリケーションプログラムを実行することにより、レストラン等の店舗において取得したメニューデータに基づいて、利用者からの注文に関する注文情報の入力を受ける入力部と、残高金額の情報が記憶される残高メモリと、決済処理アプリケーションプログラムを実行することにより、前記注文処理アプリケーションプログラムの実行によって前記入力部から入力された前記注文情報に基づいて支払金額を算出する支払金額算出部と、非接触のデータ通信を行う非接触インターフェースとを有する携帯端末と、
前記店舗において販売する飲食物とその料金に関する前記メニューデータを含むメニューデータベースと、前記携帯端末からの前記注文情報に基づいて注文を処理する注文処理部と、前記注文情報に関する決済の実行を判断する制御部と、前記注文情報に関する売上金額の情報が記憶される売上高メモリとを有する店舗サーバと、
前記店舗に設置され、前記店舗サーバと接続し、前記携帯端末との間で非接触のデータ通信を行うリーダー/ライタとを備えた注文決済システムであって、
前記携帯端末の前記非接触インターフェースは、前記注文処理アプリケーションプログラムを起動することで、前記メニューデータを前記リーダー/ライタを介して前記店舗サーバから取得するとともに、前記店舗において注文時に、前記メニューデータに基づいて前記入力部から入力されて前記携帯端末内に記憶された前記注文情報を、前記リーダー/ライタを介して前記店舗サーバに送信し、
前記店舗サーバの前記注文処理部は、前記携帯端末から取得した前記注文情報を記憶するとともに、前記注文情報に基づいて注文処理を実行し、
前記携帯端末の前記非接触インターフェースは、前記注文処理の完了後、当該注文に関する支払時に前記決済処理アプリケーションプログラムを起動することで、前記注文処理アプリケーションの実行中に前記メニューデータに基づいて入力され前記携帯端末内に記憶された前記注文情報に基づいて前記支払金額算出部により算出された支払金額を、支払要求とともに前記リーダー/ライタを介して前記店舗サーバに送信し、
前記店舗サーバの前記制御部は、前記携帯端末が前記決済処理アプリケーションプログラムの実行によって算出した前記支払金額および前記支払要求を取得した場合、前記注文処理時に前記携帯端末から取得して記憶した前記注文情報に基づいて金額を算出し、算出した前記金額と、取得した前記支払金額とが合致する場合に前記携帯端末から取得した前記支払金額で決済することを判断し、前記支払金額での決済要求を前記リーダー/ライタを介して前記携帯端末に送信し、
前記リーダー/ライタは、前記店舗サーバから前記決済要求を取得して前記携帯端末と相互認証を行い、前記相互認証が成立した場合に前記決済要求を前記携帯端末に送信し、
前記携帯端末の前記非接触インターフェースは、前記決済処理アプリケーションプログラムの実行によって、前記相互認証の成立後に前記決済要求を取得した場合に実施される、前記残高メモリの残高金額から前記支払金額を差し引く決済処理の完了を示す決済完了の情報を、前記リーダー/ライタを介して前記店舗サーバに送信し、
前記前記店舗サーバの前記売上高メモリは、前記携帯端末から前記決済完了の情報を取得して、前記売上高メモリの売上高金額に支払金額を加算する
ことを特徴とする注文決済システム。」

3.引用例
1)引用例1
これに対して、当審の拒絶の理由に引用された、本願の出願日前である平成15年1月24日に頒布された「特開2003-22483号公報」(以下、「引用例1」という。)には、図面とともに次の事項が記載されている。
(1)「【0023】図2に、図1の携帯端末100の概略構成を示す。この携帯端末100は、制御部5およびこれに接続された各部により構成される。制御部5は、図示しないCPU、EEPROM、Flash ROM、SRAM、等で構成される。本実施の形態では、制御部5はさらにカードインタフェースモジュール51を有する。制御部5には、デジタル信号処理部3、表示部6、操作部7、外部I/F部8、非接触ICカード部10等が接続されている。
【0024】デジタル信号処理部3は、主として、デジタル音声信号のエンコード、および、デジタル音声信号へのデコードを行う部位であり、DSP(Digital Signal Processor)を中心とした畳み込み符号化、スロットインターリーブ、遅延検波、畳み込み復号化、等の専用回路で構成される。このデジタル信号処理部3には、音声入力部1、音声出力部2、RF入出力部4が接続されている。音声入力部1は、マイク15からのアナログ音声信号をデジタル信号に変換するための部位であり、マイクアンプ、フィルタ、A/D変換器、等で構成される。音声出力部2は、デジタル信号処理部3から受信したデジタル音声信号に基づいてスピーカ16を駆動するための部位であり、D/A変換器、フィルタ、スピーカーアンプ、等の各部により構成される。RF入出力部4は、高周波送受信を行う部位であり、直交変調器、ゲインアンプ、パワーアンプ、ダイバーシティー、ミキサー、lF復調器、等の各部により構成される。
【0025】操作部7は、ユーザから携帯端末100に対して情報を入力するための部位であり、キーボード、JOGダイヤル、JOYスティック、等で構成される。表示部6は、携帯端末100からユーザに対して可視情報を提供するための部位であり、LCDドライバ、LCD表示デバイス、等の各部で構成される。この操作部7および表示部6はユーザインタフェース手段を構成する。
【0026】外部I/F部8は、外部とのインタフェース(I/F)をとるための部位であり、通信インターフェース回路、16ピンコネクタ、等で構成される。電源回路9は、バッテリ電源を基に各ブロックに必要な電源を発生、供給する部位であり、バッテリへの充電回路、過電流過電圧保護回路、等で構成される。
【0027】非接触ICカード部10が、携帯端末100に非接触ICカード機能を付与する部位であり、専用のCPU21、メモリ(MEM)22、読み取り/書き込み部(R/W)23を有し、これらは通常IC化されている。この非接触ICカード部10は、制御部5のカードインタフェースモジュール51とデータのやりとりを行う他、アンテナ11を介して、店舗端末300等に備えられた外部のリーダ/ライタ部(R/W)とのワイヤレス通信を行う機能を有する。アンテナ11は極力携帯端末の表面近くに実装される。店舗端末300は、後述するように、さらにホストコンピュータに対して通信媒体を介して接続されてもよい。
【0028】図3は、図1に示したメニューサーバ200の概略のハードウェア構成を示すブロック図である。CPU210は、OS(Operating System)および各種アプリケーションプログラムを実行し、サーバ各部の制御を行う。ROM211は、CPU210が実行するプログラムや演算用のパラメータのうちの固定的なデータを格納する。RAM212は、CPU210の作業領域やデータの一時記憶領域を提供する。ROM211およびRAM212は、バス230を介してCPU210に接続される。キーボードなどの入力装置214、CRT,液晶ディスプレイなどの表示装置212、ハードディスク装置,MO,CD-ROM等の外部記憶装置に格納された商品メニューデータベース216は、インタフェース213を介してバス230に接続されている。また、バス230は通信部220を介して通信網150に接続される。商品メニューデータベース216には、ユーザに提供すべき最新メニューや注文フォームなどのウェブ文書データが、店舗(や支店)を基に検索可能に格納されている。また、ROM211または外部記憶装置216には、ウェブサーバとして機能するためのコンピュータプログラムや、後述する計算処理等を行うためのCGIプログラム等が予め用意されている。店舗端末300の構成については後述する。
【0029】図4および図5により、本発明の第1の実施の形態の処理の流れを説明する。その過程で、図7から図17の携帯端末100または店舗端末の表示画面例を参照する。この第1の実施の形態は、携帯端末100がサーバ200にアクセスしオンラインで商品メニューを閲覧して購入商品を決定し、その計算処理をサーバ側(または携帯端末側)で行い、最終的に携帯端末100が店舗端末300に対して送信することができる注文書データをサーバから携帯端末のICカード部10内に格納するものである。
【0030】図4の最初のステップS1において、ユーザは「商品メニューリクエスト」を選択する。これは、図7に示すような携帯端末の初期メニュー110から店舗の商品メニューをサーバ(図1のメニューサーバ200)に対して要求するメニュー項目である。通信網150(図1)を介してサーバとの間の通信が開始される(S2)。サーバから携帯端末へは図8に示すような店舗メニュー111が送信され、携帯端末画面に表示される。ここでは、所望の種類のファーストフード店を選べるようになっている。図8の各店舗が単にファーストフード店の系列を示している場合には、さらに図9の支店メニュー画面111aに示すように、その系列の具体的な所在地の支店を選択できるようにしてもよい。また、単に系列のどの支店でも購入を受け付ける場合には、支店メニュー画面111aは必要ではない。
【0031】このような画面からユーザが所望の店舗(またはその支店)を選択すると(S3)、図10に示すようなアクションアイテムが携帯端末画面に表示される(S5)。ここでユーザが「商品メニュー表示(注文フォーム)」を選択すると、サーバに商品メニューの要求がなされる(S6)。これに応じてサーバは、図11に示すような、当該店舗の商品メニューを兼ねた注文フォーム113を携帯端末へ送信する(S7)。携帯端末はこれを表示する(S8)。
【0032】図11の注文フォーム113に対して、図12に示すように、ユーザが商品メニューの中から所望の商品についてその注文個数を入力すると(S9)、それらの商品の小計、消費税および合計の代金が計算されて表示される。この計算は、サーバのCGIプログラム等、または携帯端末内部のJava(登録商標)プログラム等のプログラムにより実行することができる。OKボタンの押下等のユーザ操作により入力が完了すると(S10)、図5の処理へ移行し、注文が確定した状態となる(S21)。そこで、サーバから注文書データとして当該注文のバリューが送信され(S31)、携帯端末はこれを受けてICカード部内のメモリに格納する(S22)。ここで「バリュー」とはICカード内に格納すべき価値のある情報である。この情報には購入する商品の識別情報、金額情報の他、必要に応じて店舗(および支店)の識別情報なども含まれる。このバリュー情報の形式は、後に店舗端末に送信されたときに店舗端末側で必要な情報が認識されるならば任意の形式でよい。このステップS22の後でサーバとの通信は終了しオフライン状態となる(S32)。この通信の終了はユーザの指示によって行うか、自動的に行うかはいずれであってもよい。
【0033】ユーザはオフライン状態で、注文を確認することができる(S23)。本例では、図7の初期メニュー画面110においてユーザが「購入リスト」を指示することにより、携帯端末に図13のような購入リスト画面115が表示される。図7の例では購入リストを店舗毎に異ならせてあるが、異なる店舗について共通としてもよい。この購入リスト画面115はICカード部内に格納された複数の注文バリュー(注文書データ)をリスト表示するものである。この際、ICカード部メモリ内の情報を表示するためのビューアプログラムが起動される。この例では、過去にダウンロードした注文書データのダウンロードの日時および合計代金ならびにその買い物が済みか否かの識別情報が表示されている。メモリ容量の観点から、「買い物済み」の過去の履歴情報は古いものから自動的に消去したり、ユーザの指示に応じて消去したりすることができる。「買い物済み」の項目は、過去の履歴として保存してあるものであり、本発明に必須の情報ではない。図4に示すように、「買い物未」の購入リスト項目について、ユーザがその項目を指定することにより、図15に示すような確認画面117が携帯端末に表示され、ユーザがこの画面上で購入、修正、取消の指示を行うことができる(S24)。確認画面117の表示時に、ビューアは、前記注文バリューの形式によっては、その形式をユーザが認識できる形式に変換する。
【0034】ユーザの指示が「修正」の場合には、サーバとの通信が再開され(S33)、図示しない修正画面による注文修正(S25)を経て、ステップS22の注文バリューの再ダウンロードに戻る。この際、ICカード部内では先の注文バリューに修正後の注文バリューが上書きされる。
【0035】ユーザの指示が「取消」の場合にもサーバとの通信が再開され(S34)、その旨がサーバに通知され、かつ、ICカード部内の当該バリューを消去(または無効化)する等により注文がキャンセルされる(S27)。その後、通信が終了する(S35)。なお、「取消」の場合であっても、サーバ側に通知する必要がない場合にはステップS34の通信再開は必要ない。
【0036】ユーザの指示が「購入する」(OK)の場合には、その後、携帯端末を店舗端末にかざすことにより(S26)、店舗端末との通信が開始される(S11)。まず、携帯端末のICカード部と店舗端末のICカード機能との間で相互のカード認証処理が行われる(S12,S13)。認証OKであれば、携帯端末からICカード部に保存されている注文バリュー情報を店舗端末へ送信する(S14)。店舗端末はバリュー情報から注文内容を検出する(S15)。この注文内容は、好ましくは店員が確認できるように、例えば図16に示すように店舗端末の表示画面310として表示される。また、この内容に基づいて、当該客に手渡すべき商品が用意される。これと共に、店舗端末は、その注文の代金について、ICカード部との間で決済処理を行う(S16,S17)。これに関連して、図6により店舗端末300と携帯端末100の間の通信によるデータの授受について説明する。店舗端末300は、携帯端末100のICカード部10のリーダ/ライタ部23とワイヤレスでデータの授受を行うリーダ/ライタ部302、決済処理等を行うデータ処理部304および外部のプリペイドマネー決済機構350との間で通信を行う通信部306を備える。店舗端末300は、携帯端末100から注文バリュー情報を受けると、その代金分の電子マネーバリューを要求し、携帯端末100のICカード部10から電子マネーバリューのダウンロードを行う。これにより、携帯端末100のICカード部10の電子マネー残高はその分だけ減じられる。また、プリペイド電子マネー決済機構350には当該決済のログ情報が店舗端末300から通知され、当該代金分の金額が店舗からプリペイド電子マネー決済機構350に請求される。」
(2)「【0039】次に、図18および図19により、本発明の第2の実施の形態について説明する。本実施の形態のシステム構成は第1の実施の形態と同じであるが、処理内容が異なる。この第1の実施の形態では、携帯端末100がサーバ200に対してオンラインで商品メニューを閲覧して購入商品を決定するようにしたが、本実施の形態では、商品メニューを要求した後にサーバとの通信を終了して、以後、オフラインでユーザに購入商品を選択させ、注文のバリューを作成するものである。そのために、本実施の形態では、その処理を行うための専用プログラムが携帯端末の出荷時にインストールされ、または、事後的にダウンロード等によりインストールされているものとする。
【0040】図18の最初のステップS41からS47までは、第1の実施の形態のステップS1からS7(図4)と同じである。すなわち、携帯端末の操作(S41)によってサーバとの通信が開始され(S42)、店舗の選択、通知が行われた後(S43、S44)、表示されたアクションアイテムの中から商品メニューリクエストが選択されたときに、サーバに対して商品メニューの要求がなされる(S45,S46)。これに対してサーバから商品メニューを兼ねた注文フォームが携帯端末へ送信される(S47)。サーバはこの注文フォームを記憶しておく。この段階で、第1の実施の形態と異なり、携帯端末とサーバとの間の通信が終了する(S48)。以後の処理はサーバに頼らずに携帯端末がオフラインで実行する。
【0041】ユーザは、注文フォーム(S49)に表れた商品メニューの中から所望の商品についてその注文個数を入力すると(S50)、内蔵の上記専用プログラムの処理により、それらの商品の小計、消費税および合計の代金が計算されて表示される。このユーザ操作により入力が完了すると(S51)、図19の処理へ移行し、注文が確定した状態となる(S71)。ここで、携帯端末は、前記専用プログラムの処理により、当該注文のバリューを作成し、ICカード部内のメモリに格納する(S72)。このバリューの内容は第1の実施の形態の場合と同様である。
【0042】その後、第1の実施の形態と同様、ユーザは「購入リスト」を表示して注文を確認することができる(S73)。また、「買い物未」の購入リスト項目については、その項目を指定することにより、ユーザがこの画面上で購入、修正、取消の指示を行うことができる(S74)。
【0043】ユーザの指示が「修正」の場合には、修正画面による注文修正(S78)を経て、ステップS72の注文バリューの作成に戻る。この際、ICカード部内では先の注文バリューに修正後の注文バリューが上書きされる。
【0044】ユーザの指示が「取消」の場合には、ICカード部内の当該バリューを消去(または無効化)する等により注文がキャンセルされる(S77)。
【0045】ユーザの指示が「購入する」(OK)の場合には、その後、携帯端末を店舗端末にかざすことにより(S75)、店舗端末との通信が開始される(S61)。この後の携帯端末と店舗端末の処理ステップS62からS70は、第1の実施の形態における対応ステップS12からS20と同じであるので、説明を省略する。」(下線は、当審による。)

これらの記載事項によると、引用例1には、
「端末に対して情報を入力する操作部7と、電子マネー残高が記憶され、外部のリーダ/ライタ部302とワイヤレス通信を行うICカード部10と、商品の小計、消費税および合計の代金を計算するプログラムを有する携帯端末100と、
商品メニューデータベース216を有するメニューサーバ200と
携帯端末100から注文情報を受け取り、決済処理を行うデータ処理部304を有する店舗端末300と
携帯端末100へ、サーバ200から、商品メニューを兼ねた注文フォームが、通信網を介して送信され、
携帯端末100は、プログラムによって、商品メニューの中から商品について注文個数を入力すると、それらの商品の小計が計算され表示され、ユーザ操作により入力が完了し、注文バリュー情報をICカード部内のメモリに格納し、
購入の場合、携帯端末100を店舗端末300にかざすことによって、店舗端末300との通信が開始され、
携帯端末のICカード部と店舗端末のICカード機能で相互のカード認証処理を行い、
認証OKであれば、携帯端末100は、注文バリュー情報を店舗端末300へ送信し、店舗端末300は、注文書バリュー情報から注文内容を確認し、
店舗端末300は、携帯端末100に対して代金分の電子マネーバリューを要求し、携帯端末100のICカード部10から電子マネーバリューのダウンロードを行い、ICカード10の電子マネー残高は減じられ、
店舗端末300から代金分がプリペイド電子マネー決済機構350に請求される
商品販売決済システム。」
の発明(以下、「引用例1記載の発明」という。)が記載されているものと認められる。

2)引用例2
当審の拒絶の理由に引用された、本願の出願日前である平成16年11月11日に頒布された「特開2004-318650号公報」(以下、「引用例2」という。)には、図面とともに次の事項が記載されている。
(1)「【0120】
図14は、本発明の第2の実施の形態における携帯端末を用いた決済システムの構成を示すシステム構成図である。
【0121】
この決済システムは、飲食店内で顧客として購買活動(注文活動)を行う携帯端末のユーザに対する利便性を向上したものであって、EC決済を可能とするとともに、注文を示す内容のオーダー情報を送信する上記携帯端末たる携帯電話1A,2A,1B,2B,3Bと、飲食店の配膳係を務める店員によって携帯される店員用携帯電話50と、飲食店に配設されたPOS端末40及び厨房端末60と、飲食店のAテーブルに取り付けられ、飲食店のメニューを示す内容のメニュー情報を送信するとともに上記オーダー情報を受信するA送受信機71と、Bテーブルに取り付けられ、飲食店のメニューを示す内容のメニュー情報を送信するとともに上記オーダー情報を受信するB送受信機72とから構成される。
【0122】
ここで、本実施の形態では、携帯電話1Aと携帯電話2Aのユーザである顧客が1つのグループとしてAテーブルに向かって着席し、携帯電話1Bと携帯電話2Bと携帯電話3Bのユーザである顧客が1つのグループとしてBテーブルに向かって着席した場合を例に挙げて説明する。また、携帯電話1A,2A,1B,2B,3Bはそれぞれ同一の機能及び構成を有するとともに、A送受信機71及びB送受信機72はそれぞれ同一の機能及び構成を有するため、本実施の形態では、主に携帯電話1A,2A及びA送受信機71について説明する。
【0123】
図15は、POS端末40と厨房端末60と店員用携帯電話50とA送受信機71と携帯電話1A,2Aとの間で情報が送受信される様子を示す状態図である。
【0124】
POS端末40は、例えばIrDAの規格に準じた通信を行うための通信ポート41を備えると共に、インターネット901を介して決済会社991(決済会社内の端末)と接続しており、携帯電話1Aから後述する決済情報210aを通信ポート41で取得すると、その決済情報210aに基づいて決済会社991に対して決済処理を行わせる。」
(2)「【0132】
携帯電話1A,2Aは、A送受信機71から上述のメニュー情報206aを取得して、そのメニュー情報206aに示されるメニューを表示すると共に、ユーザの操作に応じて、そのメニューの中から商品が選定されると、その商品を注文することを示す内容のオーダー情報212aをA送受信機71に送信する。また、携帯電話1A,2Aは、上述のように注文した商品を記憶しており、その記憶している注文履歴を表示する。さらに、携帯電話1A,2Aは、A送受信機71から配膳完了情報50aを取得したときには、その配膳完了情報50aに基づいて、注文した商品が配膳されたことを記憶するとともに、メンバーオーダー情報71aを取得したときには、そのメンバーオーダー情報71aに示される商品が他のメンバーの携帯電話2A,1Aから注文されたことを、注文履歴として記憶する。
【0133】
そして、このような携帯電話1A,2Aを携帯するユーザは、オーダー情報212aを送信させるような携帯電話1A,2Aに対する操作を、注文しようとする商品のそれぞれに対して繰り返し行った後、POS端末40に近づいて携帯電話1A,2AをそのPOS端末40の通信ポート41に差し向けて携帯電話1A,2Aを操作する。その結果、携帯電話1A,2Aは、注文履歴を基に、EC決済を行わせるための決済情報210aを作成してこれをPOS端末40に送信する。これにより、決済処理が行われる。」
(3)「【0135】
図17は、携帯電話1Aの内部構成を示す構成図である。
携帯電話1Aは、近距離データ通信を行う送受信部201と、店舗内の所定のテーブルに割り当てられたテーブル識別情報を記憶するためのテーブルID記憶部205と、注文する商品の合計金額の上限額を設定する上限設定部207と、メニュー情報206aを記憶するためのメニュー情報記憶部206と、既に注文された商品に関する内容、つまり上述の注文履歴を示す伝票情報208aを記憶するための伝票情報記憶部208と、EC決済を行うにあたって必要な内容を含む個人情報209aを記憶するための個人情報記憶部209と、決済情報210aを作成する決済情報作成部210と、ユーザを認証する認証部211と、オーダー情報212aを作成するオーダー情報作成部212と、上記各部を制御する注文制御部202と、注文制御部202による制御に応じて図形や文字を表示する表示部203と、ダイヤルボタンなどを具備してそのボタン操作に応じた操作信号を注文制御部202に出力する操作部204とを備えている。
【0136】
ここで送受信部201は、IrDAの規格に準じた赤外線通信を行う。
【0137】
携帯電話1Aが顧客に携帯されて飲食店内に持ち込まれたときには、携帯電話1Aの注文制御部202は送受信部201を介して、例えばPOS端末40の通信ポート41からテーブル識別番号を取得する。ここで、携帯電話1Aのユーザと携帯電話2Aのユーザとがメンバーとなって、飲食店に入ってAテーブルに向かって着席する場合には、POS端末40の通信ポート41は、Aテーブルに割り当てられたテーブル識別情報を、両携帯電話1A,2Aに送信する。そして、両携帯電話1A,2Aの注文制御部202は、そのテーブル識別情報を送受信部201を介して取得して、これをそれぞれのテーブルID記憶部205に保存する。
【0138】
携帯電話1Aの注文制御部202は、送受信部201を介してA送受信機71からメニュー情報206aを取得すると、これをメニュー情報記憶部206に保存する。」
(4)「【0144】
注文制御部202は、伝票情報記憶部208に登録されている上述のような伝票情報208aと、上限設定部207に設定されている上限額とを読み出す。そして注文制御部202は、その伝票情報208aの値段欄F2に格納されている各値段のそれぞれに対して、個数欄F3に格納されている個数を掛け合わせてこれらを積算し、さらにその積算結果に対して、上述のようにメニューの中から選定された商品の値段を積算して、その積算額が上限額以下であるか否かを判別する。
【0145】
例えば、ユーザが上限額を「7500円」として上限設定部207に設定し、いずれの商品も注文していないときに、メニューの中から図18に示す商品「冷酒」が選定された場合には、伝票情報208aの値段欄F2には値段が格納されておらず、選定された商品「冷酒」の値段は「500円」と特定されるので、注文制御部202は、その商品「冷酒」を購入しても積算額は上限額以下であると判別する。一方、図19に示すように、3杯の商品「生ビール」、5個の「冷奴」、及び1つの「刺身盛り合わせ」をユーザが既に注文し、その結果が伝票情報208aに登録されているときに、メニューの中から商品「冷酒」が選定された場合には、注文制御部202は、伝票情報208aの値段欄F2に格納されている各値段「350円」、「180円」、「900円」に、個数欄F3に格納されている個数「3」、「5」、「1」をそれぞれ掛け合わせてこれらを積算し、さらにその積算結果に商品「冷酒」の値段「500円」を積算し、その積算額が上限額「7500円」を上回る「7550円」となるので、その商品「冷酒」が注文された場合には、積算額が上限額を超えてしまうと判別する。」
(5)「【0172】
このように、本実施の形態では、決済前に携帯電話1Aの表示部203に、注文商品の値段の積算額(合計金額)が表示されるため、ユーザは注文しながら逐次それらの合計金額を容易に把握することができ、ユーザに対する利便性を向上することができる。また、伝票も表示部203に表示されるため、ユーザは注文商品を確認しながら購買活動(注文活動)を行うことができ、さらに、配膳されたか否かを示す配膳情報も表示されるため、ユーザに対する利便性をさらに向上することができる。」
(6)「【0190】
次に、注文制御部202は、EC決済するように指示する内容の操作信号が操作部204から出力されたか否かを判別し(ステップS330)、その操作信号が出力されたと判別したときには(ステップS330のY)、さらに、操作部204から入力されたパスワードが個人情報209aに含まれるパスワードと一致するか否かを認証部211に判定させる(ステップS332)。そして一致すると判定されたときには(ステップS332のY)、注文制御部202は、伝票情報208a及び個人情報209aに基づいて決済情報210aを決済情報作成部210に作成させて、これを送受信部201からPOS端末40に送信させることで、POS端末40に接続された決済会社991に対して決済処理を実行させる(ステップS334)。
【0191】
また、ステップS330でEC決済を促すように指示する操作信号が出力されないと判別したときには(ステップS330のN)、注文制御部202は、ステップS304からの動作を繰り返し実行し、ステップS332でパスワードが一致しないと判定されたときには(ステップS332のN)、注文制御部202は、決済情報作成部210による決済情報210aの作成を禁止してステップS304からの動作を繰り返し実行する。」
(以下、「引用例2の記載事項」という。下線は、当審による。)

3)引用例3
当審の拒絶の理由に引用された、本願の出願日前である平成14年6月21日に頒布された「特開2002-176671号公報」(以下、「引用例3」という。)には、図面とともに次の事項が記載されている。
(1)「【0038】操作入力部4から購買者が購買金額を入力し、この購買金額が商品情報や個人特定情報とともに、携帯電話機1から通話管理コンピュータ16へ送信されてもよい。通話管理コンピュータ16は、入力された購買金額とデータベースに基づいて導出された購買金額との照合を行う。両者が一致したときのみ、決済が行われる。これにより、購買者が錯誤によって意図せぬ高額商品を購入してしまうことが防止される。」
(以下、「引用例3の記載事項」という。)

4.対比
引用例1記載の発明の「携帯端末100」は、メニューオーダーを行う端末であるから、本願発明の「携帯端末」に相当する。
引用例1記載の発明の「端末に対して情報を入力する操作部7」は、メニューに対して入力を行うものであり、メニューはサーバ200から取得したものであるから、本願発明の「取得したメニューデータに基づいて、利用者からの注文に関する注文情報の入力を受ける入力部」に相当する。
引用例1記載の発明の「電子マネー残高が記憶され、外部のリーダ/ライタ部302とワイヤレス通信を行うICカード部10」は、本願発明の「残高金額の情報が記憶される残高メモリ」と「非接触のデータ通信を行う非接触インターフェース」に相当する機能を兼ね備えている。
引用例1記載の発明の「商品の小計、消費税および合計の代金を計算するプログラム」は、本願発明の「注文処理アプリケーションプログラムの実行によって前記入力部から入力された前記注文情報に基づいて支払金額を算出する支払金額算出部」と同様の機能を有している。
引用例1記載の発明の「商品メニューデータベース216」は、その機能からみて、本願発明の「店舗において販売する飲食物とその料金に関する前記メニューデータを含むメニューデータベース」に相当する。
引用例1記載の発明の「携帯端末100から注文情報を受け取り、決済処理を行うデータ処理部304」は、本願発明の「記携帯端末からの前記注文情報に基づいて注文を処理する注文処理部」と「前記注文情報に関する決済の実行を判断する制御部」に相当する機能を有している。
引用例1記載の発明の「店舗端末300」は、携帯端末100から電子マネーバリューをダウンロードしていることからみて、本願発明の「注文情報に関する売上金額の情報が記憶される売上高メモリ」に相当する構成を有していることは明らかである。
引用例1記載の発明の「メニューサーバ200」及び「店舗端末300」は、本願発明の「店舗サーバ」と同等の機能を有する。
引用例1記載の発明の「リーダ/ライタ部302」は、店舗端末300に備えられていて、携帯端末100と通信しているから、本願発明の「店舗に設置され、前記店舗サーバと接続し、前記携帯端末との間で非接触のデータ通信を行うリーダー/ライタ」に相当する。
引用例1記載の発明の「携帯端末100へ、サーバ200から、商品メニューを兼ね注文フォームが、通信網を介して送信され、」は、本願発明の「前記メニューデータを前記店舗サーバから取得する」に相当する。
引用例1記載の発明の「購入の場合、携帯端末100を店舗端末300にかざすことによって、店舗端末300との通信が開始され、」「携帯端末100は、注文バリュー情報を店舗端末300へ送信し」は、本願発明の「前記携帯端末の前記非接触インターフェースは、」「前記店舗において注文時に、前記メニューデータに基づいて前記入力部から入力されて前記携帯端末内に記憶された前記注文情報を、前記リーダー/ライタを介して前記店舗サーバに送信し、」に相当する。
引用例1記載の発明の「店舗端末300は、注文書バリュー情報から注文内容を確認し、」は、本願発明の「前記店舗サーバの前記注文処理部は、前記携帯端末から取得した前記注文情報を記憶するとともに、前記注文情報に基づいて注文処理を実行し、」に相当する。
引用例1記載の発明の「店舗端末300は、携帯端末のICカード部10から電子マネーバリューのダウンロードを行い、」で、電子マネーバリューは代金を表しているから、当該構成は、本願発明の「前記携帯端末の前記非接触インターフェースは、」「前記注文処理アプリケーションの実行中に前記メニューデータに基づいて入力され前記携帯端末内に記憶された前記注文情報に基づいて前記支払金額算出部により算出された支払金額を、支払要求とともに前記リーダー/ライタを介して前記店舗サーバに送信し、」に相当する。
引用例1記載の発明の「携帯端末のICカード部と店舗端末のICカード機能で相互のカード認証処理を行い、」は、本願発明の「前記リーダー/ライタは、前記店舗サーバから前記決済要求を取得して前記携帯端末と相互認証を行い、」に相当する。
引用例1記載の発明の「認証OKであれば、」「店舗端末300は、携帯端末100に対して代金分の電子マネーバリューを要求し、携帯端末100のICカード部10から電子マネーバリューのダウンロードを行い、ICカード10の電子マネー残高は減じられ、」で、店舗端末300は電子マネーバリューを要求すること、電子マネーバリューのダウンロードすることは、ICカード10のリーダ/ライタ部23とリーダ/ライタ部304の間で行われ、電子マネーバリューのダウンロードで、ICカード部10の残高は減じられ、結果的に、「電子マネーバリュー」は、「前記残高メモリの残高金額から前記支払金額を差し引く決済処理の完了を示す決済完了の情報」の機能も達成していると認められるから、本願発明の「前記相互認証が成立した場合に前記決済要求を前記携帯端末に送信し、」「前記携帯端末の前記非接触インターフェースは、」「前記相互認証の成立後に前記決済要求を取得した場合に実施される、前記残高メモリの残高金額から前記支払金額を差し引く決済処理の完了を示す決済完了の情報を、前記リーダー/ライタを介して前記店舗サーバに送信し、」に相当する。
引用例1記載の発明の「商品販売決済システム」は、本願発明の「注文決済システム」に相当する。

してみると、両発明の一致点、相違点は以下のとおりである。

[一致点]
「注文処理アプリケーションプログラムを実行することにより、取得したメニューデータに基づいて、利用者からの注文に関する注文情報の入力を受ける入力部と、残高金額の情報が記憶される残高メモリと、前記注文処理アプリケーションプログラムの実行によって前記入力部から入力された前記注文情報に基づいて支払金額を算出する支払金額算出部と、非接触のデータ通信を行う非接触インターフェースとを有する携帯端末と、
前記店舗において販売する飲食物とその料金に関する前記メニューデータを含むメニューデータベースと、前記携帯端末からの前記注文情報に基づいて注文を処理する注文処理部と、前記注文情報に関する決済の実行を判断する制御部と、前記注文情報に関する売上金額の情報が記憶される売上高メモリとを有する店舗サーバと、
前記店舗に設置され、前記店舗サーバと接続し、前記携帯端末との間で非接触のデータ通信を行うリーダー/ライタとを備えた注文決済システムであって、
前記メニューデータを前記店舗サーバから取得し、
前記携帯端末の前記非接触インターフェースは、前記店舗において注文時に、前記メニューデータに基づいて前記入力部から入力されて前記携帯端末内に記憶された前記注文情報を、前記リーダー/ライタを介して前記店舗サーバに送信し、
前記店舗サーバの前記注文処理部は、前記携帯端末から取得した前記注文情報を記憶するとともに、前記注文情報に基づいて注文処理を実行し、
前記携帯端末の前記非接触インターフェースは、注文処理アプリケーションの実行中に前記メニューデータに基づいて入力され前記携帯端末内に記憶された前記注文情報に基づいて前記支払金額算出部により算出された支払金額を、支払要求とともに前記リーダー/ライタを介して前記店舗サーバに送信し、
前記店舗サーバは、前記支払金額での決済要求を前記リーダー/ライタを介して前記携帯端末に送信し、
前記リーダー/ライタは、前記店舗サーバから前記決済要求を取得して前記携帯端末と相互認証を行い、前記相互認証が成立した場合に前記決済要求を前記携帯端末に送信し、
前記携帯端末の前記非接触インターフェースは、前記相互認証の成立後に前記決済要求を取得した場合に実施される、前記残高メモリの残高金額から前記支払金額を差し引く決済処理の完了を示す決済完了の情報を、前記リーダー/ライタを介して前記店舗サーバに送信する
注文決済システム。」

[相違点]
(a)本願発明の「メニューデータ」は、「注文処理アプリケーションプログラムを実行することで、」「レストラン等の店舗において、」取得され、「携帯端末のインタフェースが」「メニューデータを前記リーダー/ライタを介して前記店舗サーバから取得」しているのに対して、引用例1記載の発明は、注文フォームを「通信網」を介して取得している点。
(b)本願発明は、「前記注文処理の完了後、」「支払金額を、支払要求とともに前記リーダー/ライタを介して前記店舗サーバに送信」しているのに対して、引用例1記載の発明は、注文書バリューによって、注文処理と同時に支払金額を店舗端末300に対して送信している点。
(c)本願発明は、「支払要求を取得した場合、前記注文処理時に前記携帯端末から取得して記憶した前記注文情報に基づいて金額を算出し、算出した前記金額と、取得した前記支払金額とが合致する場合に前記携帯端末から取得した前記支払金額で決済することを判断」しているのに対して、引用例1記載の発明は、このような構成を有していない点。
(d)本願発明が、「前記前記店舗サーバの前記売上高メモリは、前記携帯端末から前記決済完了の情報を取得して、前記売上高メモリの売上高金額に支払金額を加算する」のに対して、引用例1記載の発明は、このような構成の明示がない点。
(e)本願発明が、「決済処理アプリケーションプログラム」を有していているのに対して、引用例1記載の発明では、このようなプログラムを有しているのかどうか明示されていない点。

5. 当審の判断
相違点について
(a)「メニューデータ」は、「レストラン等の店舗において、」取得され、「携帯端末のインタフェースが」「メニューデータを前記リーダー/ライタを介して前記店舗サーバから取得」することは、引用例2の記載事項から明らかなように、本願出願前公知であり、引用例1記載の発明を、レストラン等の店舗に適用するために、引用例2の記載事項を適用し、相違点(a)の構成とすることは当業者が容易になし得ることである。なお、引用例2の記載事項において、携帯電話も、「注文処理アプリケーションプログラム」に相当する機能を有していることは明らかである。
(b)飲食店において、「前記注文処理の完了後、」「支払金額を、支払要求とともに前記リーダー/ライタを介して前記店舗サーバに送信」する構成は、引用例2の記載事項から明らかなように、出願前公知である。引用例1のようなファーストフード店では、品物が代金引き換えであり、注文と精算が同時であるが、飲食店やレストランでは、注文の後にまとめて精算することが一般的である。引用例1記載の発明を、レストラン等に対応させるため、引用例2の記載事項を適用し、相違点(b)の構成とすることは、当業者が容易になし得ることである。
(c)引用例1記載の発明の場合、注文バリューに記載された金額は、注文の段階で突き合わせが終わった状態の金額であるが、金額の突き合わせを決済段階で行うために、引用例3の記載事項を適用し、相違点(c)の構成とすることは当業者が容易になし得ることである。
(d)売上高を記憶して、支払い金額を加算することは、特開2004-206657号公報の段落番号0046、特開2002-24531号公報の段落番号0084に見られるように周知事項であり、店舗端末300において売上高を管理するために、当該周知事項を適用し、相違点(d)の構成とすることは当業者が容易になし得ることである。
(e)引用例1記載の発明においても、決済処理が行われているから、「決済処理プログラム」と同等の処理機能を有していることは明らかであり、本願発明が、「決済処理プログラム」を有していることで格別な処理を実現しているとも認められないから、相違点(e)は、単なる設計事項に過ぎない。

そして、これらの相違点を総合的に勘案しても、本願発明の効果も引用例1記載の発明、引用例2の記載事項、引用例3の記載事項及び周知事項から当業者が予測できる範囲のものであり、格別顕著なものということはできない。
以上のとおりであるから、相違点(a)?(e)にかかる発明の構成は、引用例1記載の発明、引用例2の記載事項、引用例3の記載事項及び周知事項から当業者が容易に想到することができたものである。

6.むすび
本願発明は引用例1記載の発明、引用例2の記載事項、引用例3の記載事項および周知事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
したがって、本願は、その他の請求項について検討するまでもなく、拒絶すべきものである。
よって、結論のとおり審決する。
 
審理終結日 2013-02-27 
結審通知日 2013-03-05 
審決日 2013-03-18 
出願番号 特願2006-41712(P2006-41712)
審決分類 P 1 8・ 121- WZ (G06Q)
最終処分 不成立  
前審関与審査官 田内 幸治塩田 徳彦  
特許庁審判長 清田 健一
特許庁審判官 石川 正二
須田 勝巳
発明の名称 注文決済システムおよび注文決済機能を有する携帯端末  
代理人 木村 信行  
代理人 内野 則彰  
代理人 久原 健太郎  

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