【事件の表示】
　特願２０１３−５００８２０「通信装置」拒絶査定不服審判事件〔平成２３年　９月２９日国際公開、ＷＯ２０１１／１１８６７０、平成２５年　６月１７日国内公表、特表２０１３−５２４５６７、請求項の数（５）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１  手続の経緯
　本願は、２０１１年３月１６日（パリ条約による優先権主張日本国特許庁受理２０１０年３月２５日、英国）を国際出願日とする出願であって、平成２６年１２月８日付けで拒絶理由が通知され、平成２７年３月９日付けで手続補正されたが、同年１０月８日付けで拒絶査定がされ、これに対し、平成２８年１月１３日に拒絶査定不服審判が請求され、同時に手続補正がされたものである。
第２　平成２８年１月１３日付けの手続補正（以下、「本件補正」という。）の適否
１．補正の内容
　平成２７年３月９日付け手続補正による特許請求の範囲は以下のとおりである。
（補正前）
「【請求項１】
　モバイル機器であって、
　ＵＩＣＣに接続するためのＵＩＣＣインタフェースと、
　前記ＵＩＣＣインタフェースを介して前記ＵＩＣＣと通信するように動作可能であるＵＩＣＣモジュールと、
　前記モバイル機器によって実行される複数のアプリケーションを格納するメモリと、
　ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供するＵＩモジュールと、
　を有し、
　前記ＵＩＣＣモジュールは、ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記ＵＩＣＣ上で利用可能なＵＩＣＣアプリケーションのＵＩＣＣアプリケーションメタデータを前記ＵＩＣＣから取得するように構成され、かつ、前記ＵＩＣＣアプリケーションメタデータを前記メモリに格納するように構成され、
　前記ＵＩモジュールは、前記ＵＩＣＣアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるＵＩＣＣアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり、
　前記ＵＩＣＣモジュールは、ＵＩＣＣアプリケーションを選択するユーザ入力に応答して、前記選択されたＵＩＣＣアプリケーションを起動するコマンドを前記ＵＩＣＣに送信するように動作可能である、
　モバイル機器。
　　【請求項２】
　前記ＵＩＣＣアプリケーションメタデータは、ＵＩＣＣアプリケーションを起動するのに必要な複数の条件を含み、前記ＵＩＣＣモジュールは、ＵＩＣＣアプリケーションのユーザ選択に応答して、前記選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信する前に、前記選択されたＵＩＣＣアプリケーションに関連する条件をチェックするように動作可能である、請求項１に記載のモバイル機器。
　　【請求項３】
　前記条件は、必要なネットワークサービスを定め、前記ＵＩＣＣモジュールは、前記必要なネットワークサービスが利用可能であることをチェックするように動作可能であり、かつ、前記必要なネットワークサービスが利用可能な場合、前記選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信するように動作可能である、請求項２に記載のモバイル機器。
　　【請求項４】
　前記条件は、ユーザ認証が必要であることを定め、前記ＵＩＣＣモジュールは、ユーザ認証を実行するように動作可能であり、かつ、ユーザ認証が成功した場合、前記選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信するように動作可能である、請求項２または３に記載のモバイル機器。
　　【請求項５】
　前記ＵＩＣＣモジュールは、ユーザに、ユーザの名前とパスワードの少なくとも一方を入力するように促すことによって、そして入力されたユーザの名前とパスワードの少なくとも一方を、前記ＵＩＣＣアプリケーションメタデータに用意されているユーザの名前とパスワードの少なくとも一方と比較することによって、認証を実行するように動作可能である、請求項４に記載のモバイル機器。
　　【請求項６】
　前記コマンドは、起動される前記ＵＩＣＣアプリケーションを識別するエンベロープコマンドである、請求項１から５のいずれかに記載のモバイル機器。
　　【請求項７】
　前記ＵＩモジュールは、前記モバイル機器上および前記ＵＩＣＣ上で利用可能な複数のアプリケーションの組合せを表示するユーザインタフェースを生成するように動作可能である、請求項１から６のいずれかに記載のモバイル機器。
　　【請求項８】
　前記ＵＩＣＣアプリケーションメタデータは、カテゴリデータを含み、前記ＵＩモジュールは、同じカテゴリのＵＩＣＣアプリケーションとモバイル機器アプリケーションとを前記ユーザインタフェース上でまとめるように動作可能である、請求項７に記載のモバイル機器。
　　【請求項９】
　前記ＵＩＣＣアプリケーションメタデータは、エレメントファイル内の前記ＵＩＣＣ上に格納され、前記ＵＩＣＣモジュールは、前記エレメントファイルから前記メタデータを読み出すように動作可能である、請求項１から８のいずれかに記載のモバイル機器。
　　【請求項１０】
　前記ＵＩＣＣアプリケーションメタデータは、前記ＵＩＣＣのために設けられたＵＩＣＣサービスメニューシステムを実行するプロセッサに与えられる、請求項１から９のいずれかに記載のモバイル機器。
　　【請求項１１】
　ＵＩＣＣであって、
　モバイル機器に接続するためのインタフェースと、
　複数のＵＩＣＣアプリケーションおよび該ＵＩＣＣアプリケーションに関するＵＩＣＣアプリケーションメタデータを格納するメモリと、
　前記モバイル機器と通信するように動作可能である制御モジュールと、
　を有し、
　前記制御モジュールは、ユーザのＵＩＣＣとの相互作用の前にまたはそれとは無関係に、前記モバイル機器に前記ＵＩＣＣアプリケーションメタデータを与えるように動作可能であり、かつ、ＵＩＣＣアプリケーションを起動するコマンドを前記モバイル機器から受信するのに応答して、該ＵＩＣＣアプリケーションを起動するように動作可能である、
　ＵＩＣＣ。
　　【請求項１２】
　前記ＵＩＣＣアプリケーションメタデータは、前記モバイル機器によって使用されるＵＩＣＣアプリケーションを起動するのに必要な複数の条件を含み、前記モバイル機器は、選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信する前に、前記必要な条件が満たされたことをチェックする、請求項１１に記載のＵＩＣＣ。
　　【請求項１３】
　前記条件は、必要なネットワークサービスを定める、請求項１２に記載のＵＩＣＣ。
　　【請求項１４】
　前記条件は、ユーザ認証が必要であることを定める、請求項１２または１３に記載のＵＩＣＣ。
　　【請求項１５】
　前記ＵＩＣＣアプリケーションは、ユーザ名とパスワードの少なくとも一方を含む、請
求項１４に記載のＵＩＣＣ。
　　【請求項１６】
　前記コマンドはエンベロープコマンドである、請求項１１から１５のいずれかに記載のＵＩＣＣ。
　　【請求項１７】
　前記ＵＩＣＣアプリケーションメタデータは、各ＵＩＣＣアプリケーションに関連するカテゴリを識別するカテゴリデータを含む、請求項１１から１６のいずれかに記載のＵＩＣＣ。
　　【請求項１８】
　前記ＵＩＣＣアプリケーションメタデータは、エレメントファイル内に格納され、ＵＳＡＴモジュールは、前記エレメントファイルからのメタデータを前記モバイル機器に与えるように動作可能である、請求項１１から１７のいずれかに記載のＵＩＣＣ。
　　【請求項１９】
　前記ＵＳＡＴモジュールは、前記ＵＩＣＣアプリケーションメタデータを、前記ＵＳＡＴモジュールによって与えられたＵＩＣＣサービスメニューシステムを有する前記モバイル機器に与えるように動作可能である、請求項１１から１８のいずれかに記載のＵＩＣＣ。
　　【請求項２０】
　前記ＵＳＡＴモジュールは、前記ＵＩＣＣアプリケーションメタデータが更新された場合、前記モバイル機器を、リセットを行うように作動させるように動作可能である、請求項１１から１９のいずれかに記載のＵＩＣＣ。
　　【請求項２１】
　ＵＩＣＣを含むモバイル機器内で行われる方法であって、
　前記モバイル機器によって実行される複数のアプリケーションをメモリに保持することと、
　ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを備えることと、
　ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、ＵＩＣＣ上で利用可能な複数のＵＩＣＣアプリケーションのＵＩＣＣアプリケーションメタデータを取得し、前記ＵＩＣＣアプリケーションメタデータを前記メモリに格納することと、
　前記取得されたＵＩＣＣアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成することと、
　ＵＩＣＣアプリケーションを選択するユーザ入力に応答して、前記選択されたＵＩＣＣアプリケーションを起動するコマンドを前記ＵＩＣＣに送信することと、
　を有する、ＵＩＣＣを含むモバイル機器内で行われる方法。
　　【請求項２２】
　ＵＩＣＣによって行われる方法であって、
　モバイル機器に接続することと、
　複数のＵＩＣＣアプリケーションおよび該ＵＩＣＣアプリケーションに関するＵＩＣＣアプリケーションメタデータを前記ＵＩＣＣのメモリ内に保持することと、
　ユーザのＵＩＣＣとの相互作用の前にまたはそれとは無関係に、前記モバイル機器に前記ＵＩＣＣアプリケーションメタデータを与えることと、
　ＵＩＣＣアプリケーションを起動するコマンドを前記モバイル機器から受信するのに応答して、該ＵＩＣＣアプリケーションを起動することと、
　を有する、ＵＩＣＣによって行われる方法。
　　【請求項２３】
　通信システムであって、請求項１から１０のいずれかに記載のモバイル機器と、請求項１１から２０のいずれかに記載のＵＩＣＣと、複数のＵＩＣＣアプリケーションを前記ＵＩＣＣにダウンロードするように動作可能であるオペレータネットワークと、を有する通信システム。
　　【請求項２４】
　プログラム可能なモバイル機器を、請求項１から１０のいずれかに記載のモバイル機器として構成可能にする、コンピュータで実行可能な複数の命令を含む、コンピュータで実行可能なプログラム。
　　【請求項２５】
　プログラム可能なＵＩＣＣを、請求項１１から２０のいずれかに記載のＵＩＣＣとして構成可能にする、コンピュータで実行可能な複数の命令を含む、コンピュータで実行可能なプログラム。」
　また、平成２８年１月１３日付け手続補正による特許請求の範囲は以下のとおりである。
（補正後）
「【請求項１】
　モバイル機器であって、
　ＵＩＣＣに接続するためのＵＩＣＣインタフェースと、
　前記ＵＩＣＣインタフェースを介して前記ＵＩＣＣと通信するように動作可能であるＵＩＣＣモジュールと、
　前記モバイル機器によって実行される複数のアプリケーションを格納するメモリと、
　ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供するＵＩモジュールと、
　を有し、
　前記ＵＩＣＣモジュールは、ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記ＵＩＣＣ上で利用可能なＵＩＣＣアプリケーションのＵＩＣＣアプリケーションメタデータを前記ＵＩＣＣから取得するように構成され、かつ、前記ＵＩＣＣアプリケーションメタデータを前記メモリに格納するように構成され、
　前記ＵＩモジュールは、前記ＵＩＣＣアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるＵＩＣＣアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり、
　前記ＵＩＣＣモジュールは、ＵＩＣＣアプリケーションを選択するユーザ入力に応答して、前記選択されたＵＩＣＣアプリケーションを起動するコマンドを前記ＵＩＣＣに送信するように動作可能であり、
　前記ＵＩＣＣアプリケーションメタデータは、ＵＩＣＣアプリケーションを起動するのに必要な複数の条件を含み、前記ＵＩＣＣモジュールは、ＵＩＣＣアプリケーションのユーザ選択に応答して、前記選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信する前に、前記選択されたＵＩＣＣアプリケーションに関連する条件をチェックするように動作可能であり、
　前記条件は、必要なネットワークサービスを定め、前記ＵＩＣＣモジュールは、前記必要なネットワークサービスが利用可能であることをチェックするように動作可能であり、かつ、前記必要なネットワークサービスが利用可能な場合、前記選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信するように動作可能である、
　モバイル機器。
　　【請求項２】
　前記条件は、ユーザ認証が必要であることを定め、前記ＵＩＣＣモジュールは、ユーザ認証を実行するように動作可能であり、かつ、ユーザ認証が成功した場合、前記選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信するように動作可能である、請求項１記載のモバイル機器。
　　【請求項３】
　前記ＵＩＣＣモジュールは、ユーザに、ユーザの名前とパスワードの少なくとも一方を入力するように促すことによって、そして入力されたユーザの名前とパスワードの少なくとも一方を、前記ＵＩＣＣアプリケーションメタデータに用意されているユーザの名前とパスワードの少なくとも一方と比較することによって、認証を実行するように動作可能である、請求項２に記載のモバイル機器。
　　【請求項４】
　ＵＩＣＣであって、
　モバイル機器に接続するためのインタフェースと、
　複数のＵＩＣＣアプリケーションおよび該ＵＩＣＣアプリケーションに関するＵＩＣＣ
アプリケーションメタデータを格納するメモリと、
　前記モバイル機器と通信するように動作可能である制御モジュールと、
　を有し、
　前記制御モジュールは、ユーザのＵＩＣＣとの相互作用の前にまたはそれとは無関係に、前記モバイル機器に前記ＵＩＣＣアプリケーションメタデータを与えるように動作可能であり、かつ、ＵＩＣＣアプリケーションを起動するコマンドを前記モバイル機器から受信するのに応答して、該ＵＩＣＣアプリケーションを起動するように動作可能であり、
　前記ＵＩＣＣアプリケーションメタデータは、前記モバイル機器によって使用されるＵＩＣＣアプリケーションを起動するのに必要な複数の条件を含み、前記モバイル機器は、選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信する前に、前記必要な条件が満たされたことをチェックし、
　前記条件は、必要なネットワークサービスを定める、
　ＵＩＣＣ。
　　【請求項５】
　通信システムであって、請求項１から３のいずれかに記載のモバイル機器と、請求項４記載のＵＩＣＣと、複数のＵＩＣＣアプリケーションを前記ＵＩＣＣにダウンロードするように動作可能であるオペレータネットワークと、を有する通信システム。」
　すなわち、本件補正は、請求項１、２、６〜１０、１４〜２２、２４、２５を削除し、請求項３、１４を独立形式で記載して他の従属項を繰り上げたものである。
２．補正の適否
　本件補正は、請求項１、２、６〜１０、１４〜２２、２４、２５を削除し、請求項３、１４を独立形式で記載して他の従属項を繰り上げたものであるから、特許法第１７条の２第５項第１号に掲げる請求項の削除を目的とするものに該当する。
　また、特許法第１７条の２第３項、第４項に違反するところはない。
第３　本願発明について
１．本願発明
　本願の請求項１〜５に係る発明は、平成２８年１月１３日付けの手続補正で補正された特許請求の範囲の請求項１〜５に記載された事項により特定されるものと認められるところ、本願の請求項１に係る発明（以下、「本願発明」という。）は、上記「第２　平成２８年１月１３日付けの手続補正（以下、「本件補正」という。）の適否」の項の「１．補正の内容」の項の「補正後」の「請求項１」のとおりのものと認める。
２．原査定の理由の概要
「拒絶理由の概要」
１．この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
２．この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
　　　　　記　　　（引用文献等については引用文献等一覧参照）
（理由１について）
・請求項１、１１、２１、２２
　引用文献１、２
備考：
　引用文献１には、モバイル機器において、ＵＩＣＣカードがアプリケーションタイトル等に基づいて生成した、ＵＩＣＣアプリケーションのメニューアイテムリストを表示し、ユーザによりＵＩＣＣアプリケーションが選択されると、当該ＵＩＣＣアプリケーションを起動するコマンドをＵＩＣＣカードに送信することが記載されている（特に、段落0010−0059、FIG.1-4）。
　また、引用文献２には、モバイル機器において、ＵＳＩＭアプリケーション選択画面を生成することが記載されている（特に、第１８頁第１８−２０行）。
・請求項２−５、１２−１５
　引用文献１−４
備考：
　引用文献３には、アプリケーションの起動の可否をネットワークに応じて判定することが記載されている（特に、段落０２２５−０２５１）。
　引用文献４には、ユーザはパスワードを入力することにより対応するアプリケーションを実行することが記載されている（特に、段落００１７）。
・請求項６、１６
　引用文献１−４
備考：
　引用文献１には、ＵＩＣＣカードが、アプリケーションを識別するエンベロープコマンドを受信することが記載されている（特に、段落0020）。
・請求項９、１０、２４
　引用文献１−４
備考：
　引用文献１に記載されたＵＩＣＣカードにおいて、アプリケーションタイトル等をどのように格納しておくかは単なる設計事項である。
　また、例えば、引用文献２（特に、第９頁第１５行−第１０頁第１２行）などに記載のように、ＵＩＣＣのファイル構造としてエレメントファイルは周知である。
・請求項１７−１９
　引用文献１−５
備考：
　引用文献５には、ＵＩＣＣアプリケーションの種類を識別することが記載されている（特に、段落0018）。
・請求項２０、２５
　引用文献１−６
備考：
　引用文献６には、カードメモリ１５のアプリケーションを更新した場合に、通信装置１を再起動することが記載されている（特に、段落００４２、００５８、００５９、図７）。
・請求項２３
　引用文献１−７
備考：
　引用文献７には、ネットワークを介して、電話端末からＳＩＭカードにアプリケーションをダウンロードするシステムが記載されている（特に、段落００３１）。
（理由２について）
（中略）
　　　　　　　　　　引　用　文　献　等　一　覧
１.欧州特許出願公開第１９６２４８２号明細書
２.国際公開第２００９／０５１３７７号
３.特開２００７−１１６５０９号公報
４.特表２００５−５１２４２５号公報
５.国際公開第２００８／０４４５９７号
６.特開２００４−３１８８７１号公報
７.特開２００１−２９１０３９号公報
「原査定の概要」
・理由１（特許法第２９条第２項）について
・請求項　１、１１、２１、２２
・引用文献等　１、２
　出願人は意見書において、請求項１に係る発明と、平成２６年１２月８日付け拒絶理由通知書に記載した引用文献１−７とを対比し、
　「本願発明は、その特許請求の範囲の請求項１に記載されている通り、その特徴ある構成として『モバイル機器であって、ＵＩＣＣに接続するためのＵＩＣＣインタフェースと、前記ＵＩＣＣインタフェースを介して前記ＵＩＣＣと通信するように動作可能であるＵＩＣＣモジュールと、前記モバイル機器によって実行される複数のアプリケーションを格納するメモリと、ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供するＵＩモジュールと、を有し、前記ＵＩＣＣモジュールは、ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記ＵＩＣＣ上で利用可能なＵＩＣＣアプリケーションのＵＩＣＣアプリケーションメタデータを前記ＵＩＣＣから取得するように構成され、かつ、前記ＵＩＣＣアプリケーションメタデータを前記メモリに格納するように構成され、前記ＵＩモジュールは、前記ＵＩＣＣアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるＵＩＣＣアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり、前記ＵＩＣＣモジュールは、ＵＩＣＣアプリケーションを選択するユーザ入力に応答して、前記選択されたＵＩＣＣアプリケーションを起動するコマンドを前記ＵＩＣＣに送信するように動作可能である』ものです。」「しかし、引用文献１〜７には、前記した本願発明の特徴ある構成要件については何ら記載されておらず、本願発明と同じ顕著な効果を達成することが期待されるものではございません。」
と主張している。
　しかしながら、引用文献１には、モバイル機器において、ＵＩＣＣカードがアプリケーションタイトル等に基づいて生成した、ＵＩＣＣアプリケーションのメニューアイテムリストを表示し、ユーザによりＵＩＣＣアプリケーションが選択されると、当該ＵＩＣＣアプリケーションを起動するコマンドをＵＩＣＣカードに送信することが記載されている（特に、段落0010−0059、FIG.1-4）。
　また、引用文献２には、モバイル機器において、ＵＳＩＭアプリケーション選択画面を生成することが記載されているから（特に、第１８頁第１８−２０行）、引用文献１に記載されたモバイル機器に、引用文献２に記載された技術を適用し、本願の請求項１に係る発明のように構成することは当業者が容易になし得たことである。
　請求項１１、２１、２２も同様である。
・請求項　２−６、９、１０、１２−２０、２３−２５
・引用文献等　１−７
　平成２６年１２月８日付け拒絶理由通知書の備考欄に示した通りである。
　よって、請求項１−６、９−２５に係る発明は、引用文献１−７に基づいて、当業者であれば容易になし得たものであるから、依然として、特許法第２９条第２項の規定により特許を受けることができない。
・理由２（特許法第３６条第６項第２号）について
（中略）
　　　　　　　　　　　　　　＜引用文献等一覧＞
１.欧州特許出願公開第１９６２４８２号明細書
２.国際公開第２００９／０５１３７７号
３.特開２００７−１１６５０９号公報
４.特表２００５−５１２４２５号公報
５.国際公開第２００８／０４４５９７号
６.特開２００４−３１８８７１号公報
７.特開２００１−２９１０３９号公報
　当審注：平成２８年１月１３日付けの手続補正で補正された特許請求の範囲の請求項１は、原査定の拒絶理由に記載中の請求項１〜２５のうちの請求項３に対応する。
３．刊行物の記載事項
Ａ　原査定の拒絶の理由に引用された欧州特許出願公開第１９６２４８２号明細書（以下、「刊行物１」という。）には、図面とともに以下の事項が記載されている。
イ．「[0001] The invention relates to a method and a device to simplify menu access in order to facilitate the end-user menus browsing. More particularly, the invention relates to a method and a device for providing a friendlier and easy to use way for accessing and displaying menus choices on end-users mobile device. 
[0002] Such menu allows final mobile terminal end-users to access services provided by mobile network operators like horoscope, news... 」（２頁１欄）
訳文（イ．）「[0001]本発明は、末端使用者がメニュー閲覧することを容易にできるよう、メニューアクセスを簡素化した方法と装置に関連している。更に詳細に説明すれば、本発明は末端使用者の携帯端末でメニューを選択する表示が分かりやすく、そしてアクセスを行う事が簡単になる方法と装置を提供することに関連している。
[0002]このようなメニューは最終携帯端末の末端使用者をモバイルネットワークオペレータが提供する、例えば星占いやニュースなどのサービスにアクセスすることを許可する。」
ロ．「[0015] According to some aspects of an embodiment of the invention, there is indeed provided a method that is implemented on a personal token such as a smart card. The application can be stored locally and reside on the personal token, also referenced as an UICC card, SIM, USIM, Mega SIM, any other smart card or an integrated chip, on the mobile device. In another embodiment, the said application can be stored on a remote server as well. 
[0016] As mentioned earlier and disclosed in figures 1 and 3 illustrating the known prior art, the functionality used for such services menu management, called setup menu, is a specific process done one time at boot stage, i.e. when the mobile device associated to the personal token is switched ON or after a software reset. The goal of this setup menu is to display to the mobile terminal end-user, usually on the screen of the handset, all the titles of applications stored in the personal token. 
[0017] The personal token builds a menu items list based on, for every service, its application title, application position and identifier.」（１頁２欄） 
訳文（ロ．）「[0015]本発明の実施例の態様に従うと、スマートカードのような個人トークンに実装されるという方法が実際に提供される。アプリケーションは特定の場所に保存され、携帯装置上で参照されているUICCカード、SIM、USIM、Mega SIM、任意のスマートカードあるいは集積化されたチップの個人トークンに常駐することが可能である。他の実施例では、前記アプリケーションはリモートサーバに保存されることが可能である。
[0016] 図１および３で先に述べられ開示された既知の先行技術は、このようなサービスメニュー管理のために使われた機能であり、「セットアップメニュー」と呼ばれ、それはブートステージのある時点、すなわち、個人トークンに関連する携帯装置がスイッチオンになる時またはソフトウェアがリセットされた後に行われる特別な工程である。このセットアップメニューの目的は携帯端末の末端使用者に個人トークンに保存された全てのアプリケーションのタイトルを、通常はハンドセットのスクリーン上で、表示することである。
[0017]個人トークンは、各サービスに対してそのアプリケーションのタイトル、アプリケーションの位置と識別子に基づいてメニューアイテムを構築する。」
ハ．「[0041] Concerning the preferred embodiment of the disclosed invention, as shown in figure 4, and after a classical initialisation phase 1000, provided that the call control service is activated and allocated in the personal token:
As soon as the mobile terminal end-user dials a short number made of at least one digit plus a validation key (plus hang up button in a preferred embodiment) 50, the mobile terminal 20 will send an envelop call control 2100 to the personal token in order to activate the detection of activation of the embodiment of the disclosed invention. 
[0042] The personal token then checks the relevancy of the said short number and makes sure it's the one chosen for services menu display 2010. 
[0043] This is done as an example by a dedicated application stored in the personal token, using dedicated files stored into the personal token memory or even in the mobile terminal memory. 
[0044] The said awaited key sequence can also be stored using a variable or an object of the said application. 
[0045] This predefined value made of an awaited key sequence can be updated OTA (Over The Air) by the mobile network operator or changed by the mobile terminal end-user using a dedicated function of the said application or even using a dedicated service of the personal token or of the mobile terminal. 
[0046] In case the entered value is the correct one, being equal to the awaited key sequence, the personal token bars the call 2200 and sends a services menu list 2300, this list being built with the items menu containing identifier of items and services titles (Text string of items) like the ones defined during set up menu 2310. 
[0047] The mobile terminal then displays this services menu list on its screen 2400 so that the mobile terminal end-user can access the said services menu. 
[0048] It's important to notice that from an end-user point of view during all the preceding steps on the disclosed method, the default sreen is displayed on the mobile device and the end-user will then directly seen the services menu without any other displays between those two. 
[0049] When the end-user selects an item in this services menu 3100, selecting an application 3010 the personal token's Operating system activates the dedicated application the same way it's done by envelop menu selection 3010.」
訳文（ハ．）「[0041]開示された発明の好ましい実施例については、図4に示される通りであり、古典的な初期化段階1000の後、呼制御サービスは起動し、個人トークンに割り当てられる。
携帯端末の末端使用者が少なくとも一つの桁に加えて、有効化キー（好ましい実施例の終話ボタンを含む）50で作られた短縮番号をダイヤルするやいなや、携帯端末20はエンベロプ呼制御2100を、開示発明の実施例の起動の検出を起動するために個人トークンに送信するだろう。
[0042]個人トークンは短縮番号の関係性を確認して、それがサービスメニュー表示2010に対して１つが選ばれたことを確かめる。
[0043]これは個人トークンメモリー内あるいは携帯端末メモリー内においても保存された専用ファイルを使用して、個人トークンに保存された専用アプリケーションによるという例のように行われる。
[0044]待ち受けキーシーケンスは、変数もしくは前記アプリケーションのオブジェクトを使う事によっても保存することができる。
[0045]このあらかじめ定義された値は待ち受けキーシーケンスで作られ、そして携帯ネットワークオペレータによってOTA（Over The Air）を更新すること、または携帯端末の末端使用者が前記アプリケーションの専用機能を使用してあるいは個人トークンもしくは携帯端末の専用サービスを使用して変更できる。
[0046]入力した値が正確なものだった場合、待ち受けキーシーケンスと等しくなり、個人トークンは、呼2200を閉じてサービスメニューリスト2300を送信し、このリストはセットアップメニュー2310時に定義されたもののように、アイテムの識別子とサービスタイトル（アイテムのテキスト列）を含んだアイテムのメニューと共に構築される。
[0047]携帯端末はそれよりこのサービスメニューリストをそのスクリーン2400に表示し、携帯端末の末端使用者は前記サービスメニューにアクセスすることが可能になる。
[0048]開示された方法では、全ての先行ステップ中で末端使用者の視点から通知することが大切である。デフォルトスクリーンは携帯端末に表示され、そして末端使用者はこれら二つ以外の他の表示がなくメニューサービスを直接見る事になるだろう。
[0049]末端使用者が、このサービスメニュー3100の一つのアイテムを選択した時、個人トークンのオペレーションシステムはアプリケーション3010を選択し、エンベロープメニュー選択3010と同じように専用アプリケーションを起動する。」
　上記刊行物１の記載及び図面並びにこの分野における技術常識を考慮すると、上記イ．の[0001]における「本発明は、末端使用者がメニュー閲覧することを容易にできるよう、メニューアクセスを簡素化した方法と装置に関連している。更に詳細に説明すれば、本発明は末端使用者の携帯端末でメニューを選択する表示が分かりやすく、そしてアクセスを行う事が簡単になる方法と装置を提供することに関連している。」との記載、上記ロ．の[0015]における「本発明の実施例の態様に従うと、スマートカードのような個人トークンに実装されるという方法が実際に提供される。アプリケーションは特定の場所に保存され、携帯装置上で参照されているUICCカード、SIM、USIM、Mega SIM、任意のスマートカードあるいは集積化されたチップの個人トークンに常駐することが可能である。」との記載、及び図４によれば、刊行物１の携帯端末は、ＵＩＣＣカードを備えているから、ＵＩＣＣに接続するためのＵＩＣＣインタフェースと、ＵＩＣＣインタフェースを介してＵＩＣＣと通信する手段とを有していることは明らかである。
　また、刊行物１の携帯端末は、携帯端末によって実行される複数のアプリケーションを保存するメモリと、末端使用者がアプリケーションにアクセスするのを可能にするユーザインタフェースを提供する手段を有することは技術常識に照らして明らかである。
　また、上記ロ．の[0016]における「図１および３で先に述べられ開示された既知の先行技術は、このようなサービスメニュー管理のために使われた機能性であり、「セットアップメニュー」と呼ばれ、それはブートステージのある時点、すなわち、個人トークンに関連する携帯装置がスイッチオンになる時またはソフトウェアがリセットされた後に行われる特別な工程である。このセットアップメニューの目的は携帯端末の末端使用者に個人トークンに保存された全てのアプリケーションのタイトルを、通常はハンドセットのスクリーン上で、表示することである。」との記載、同ロ．の[0017]における「個人トークンは、各サービスに対してそのアプリケーションのタイトル、アプリケーションの位置と識別子に基づいてメニューアイテムを構築する。」との記載によれば、刊行物１の携帯端末は、ＵＩＣＣに保存された全てのアプリケーションのタイトルをハンドセットのスクリーン上で表示するから、前述のＵＩＣＣと通信する手段が、末端使用者がスイッチオンにする時またはソフトウェアがリセットされた時に、アプリケーションのタイトル、アプリケーションの位置と識別子からなるメニューアイテムをＵＩＣＣから取得するということができる。
　また、上記ハ．の[0046]における「入力した値が正確なものだった場合、待ち受けキーシーケンスと等しくなり、個人トークンは、呼2200を閉じてサービスメニューリスト2300を送信し、このリストはセットアップメニュー2310時に定義されたもののように、アイテムの識別子とサービスタイトル（アイテムのテキスト列）を含んだアイテムのメニューと共に構築される。」との記載、同ハの[0047]における「携帯端末はそれよりこのサービスメニューリストをそのスクリーン2400に表示し、携帯端末の末端使用者は前記サービスメニューにアクセスすることが可能になる。」との記載、及び図４によれば、刊行物１の携帯端末において、前述のユーザインタフェースを提供する手段は、サービスメニューリストを受信して、末端使用者が、起動される専用アプリケーションを、サービスメニューリストを介して選択することができるユーザインタフェースを構築するということができる。
　また、上記ハ．の[0049]における「末端使用者が、このサービスメニュー3100の一つのアイテムを選択した時、個人トークンのオペレーションシステムはアプリケーション3010を選択し、エンベロプメニュー選択3010と同じように専用アプリケーションを起動する。」との記載、及び図４によれば、刊行物１の携帯端末は、ＵＩＣＣに常駐する専用アプリケーションを起動するから、前述のＵＩＣＣと通信する手段が、専用アプリケーションを選択する末端使用者入力に応答して、選択された専用アプリケーションを起動するということができる。
　したがって、上記刊行物１には、以下の発明（以下、「引用発明１」という。）が記載されているものと認められる。
　「携帯端末であって、
　ＵＩＣＣに接続するためのＵＩＣＣインタフェースと、
　前記ＵＩＣＣインタフェースを介して前記ＵＩＣＣと通信する手段と、
　前記携帯端末によって実行される複数のアプリケーションを保存するメモリと、
　末端使用者がアプリケーションにアクセスするのを可能にするユーザインタフェースを提供する手段と、
　を有し、
　前記ＵＩＣＣと通信する手段は、前記末端使用者がスイッチオンにする時またはソフトウェアがリセットされた時に、アプリケーションのタイトル、アプリケーションの位置と識別子からなるメニューアイテムを前記ＵＩＣＣから取得し、
　前記ユーザインタフェースを提供する手段は、サービスメニューリストを受信して、前記末端使用者が、起動される専用アプリケーションを、該サービスメニューリストを介して選択することができるユーザインタフェースを構築し、
　前記ＵＩＣＣと通信する手段は、専用アプリケーションを選択する末端使用者入力に応答して、前記選択された専用アプリケーションを起動する、
　携帯端末。」
Ｂ　原査定の拒絶の理由に引用された国際公開第２００９／０５１３７７号（以下、「刊行物１」という。）には、図面とともに以下の事項が記載されている。
イ．「 [Technical Field] 
　The present invention relates to method and apparatus for controlling UICC application file, more specifically to an UICC file structure that can selectively use a plurality of phone numbers by using one UICC and a method for controlling an application dedicated file in a mobile station using the same.」（１頁５〜９行）
訳文（イ．）「 [技術分野]
　本発明はＵＩＣＣアプリケーションファイルの制御方法及びその装置に関するもので、より詳細には一つのＵＩＣＣカードを用いて複数の電話番号を選択的に使用できるＵＩＣＣファイル構造及びこれを用いた移動端末機におけるアプリケーション専用ファイルの制御方法に関する。」
ロ．「FIG. 7 is a flowchart showing how an application dedicated file is selected in a mobile station in accordance with an embodiment of the present invention
　Referring to FIG. 7, if a mobile station is booted (S710), the ME 110 accesses a UICC to analyze a record included in an EFDIR (S720).
The ME 110 checks whether the EFDIR has a plurality of USIM application dedication files through the analyzing of the record (S730).
　As the result of checking it, if the EFDIR has the plurality of USIM application dedication files, the ME 110 generates a predetermined USIM application selecting screen and outputs the generated screen to a display (S740). Here, it is considered as  one of good examples that the USIM application selecting screen includes MSISDN allotted per USIM application dedicated file.
　Thereafter, the ME 110 activates a USIM application dedicated file corresponding to the MSISDN selected by a user (S750).」（１８頁１２行〜１９頁４行）
訳文（ロ．）「図７は、本発明の一実施形態による移動端末機におけるアプリケーション専用ファイルの選択方法を説明するためのフローチャートである。
　図７を参照すると、ステップＳ７１０で、移動端末機を起動し、ステップＳ７２０で、ＭＥ１１０は、ＵＩＣＣに接続してＥＦＤＩＲファイルに含まれたレコードを分析する。
　ステップＳ７３０で、ＭＥ１１０は、上記レコード分析からＥＦＤＩＲに複数のＵＳＩＭアプリケーション専用ファイルが存在するか否かを判断する。
　判断結果、複数のＵＳＩＭ  ＡＤＦ（ＵＳＩＭアプリケーション専用ファイル）が存在する場合、ステップＳ７４０で、ＭＥ１１０は、所定のＵＳＩＭアプリケーション選択画面を生成して表示部に出力する。ＵＳＩＭアプリケーション選択画面は、ＵＳＩＭアプリケーション専用ファイル別に割り当てられたＭＳＩＳＤＮ情報を含むことが好ましい。
　ステップＳ７５０で、ＭＥ１１０は、ユーザにより選択されたＭＳＩＳＤＮに対応するＵＳＩＭ  ＡＤＦ（ＵＳＩＭアプリケーション専用ファイル）を活性化させる。」
　上記刊行物２の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ．の記載、及び図７によれば、刊行物２の移動端末機は、ＵＳＩＭアプリケーション選択画面を生成していることが読み取れる。
　したがって、上記刊行物２には、以下の発明（以下、「引用発明２」という。）が記載されているものと認められる。
　「ＵＳＩＭアプリケーション選択画面を生成する移動端末機。」
Ｃ　原査定の拒絶の理由に引用された特開２００７−１１６５０９号公報（以下、「刊行物３」という。）には、図面とともに以下の事項が記載されている。
イ．「【技術分野】
【０００１】
　本発明は、無線通信ネットワークシステムにおけるネットワークのセキュリティ情報の出力に関し、特に複数の無線通信ネットワークのセキュリティ情報を出力する通信端末、プログラム、通信システム及びセキュリティ情報出力方法に関する。」（６頁）
ロ．「【０２２５】
（第８の実施の形態）
　次に、本発明の第８の実施の形態について図面を参照して詳細に説明する。
【０２２６】
（第８の実施の形態の構成）
　図２５は、本発明の第８の実施の形態による通信端末１０の構成を示したブロック図である。第８の実施の形態による通信端末１０は、アプリケーション起動インタフェース部２８０、アプリケーション起動管理部２６０、アプリケーション起動管理記憶部２９０及びアプリケーション郡２７０を備える点で、前述の第７の実施の形態による通信端末１０と異なる。
【０２２７】
　アプリケーション起動インタフェース部２８０は、アプリケーション郡２７０のアプリケーションを起動する際のインタフェースであって、アプリケーション起動管理部２６０に対してあるアプリケーションを起動することを要求する機能を有する。
【０２２８】
　アプリケーション起動管理部２６０は、アプリケーション起動インタフェース部２８０から要求されたアプリケーションを起動しても良いか否かを判断して、起動してもよい場合は該アプリケーションを起動し、起動してはいけない場合は該アプリケーションを起動しない機能を有する。
【０２２９】
　また、アプリケーション起動管理部２６０は、接続先種別判定部２２０から通知された情報に基づいて、アプリケーション起動管理記憶部２９０に格納されている情報と比較して、該アプリケーションを起動しても良いか否かの判断をする機能を有する。
【０２３０】
　アプリケーション起動管理記憶部２９０は、アプリケーション郡２７０の各アプリケーションに対して接続先種別記憶部２１０に記憶されているカテゴリー毎に格納している。
【０２３１】
　図２６は、アプリケーション起動管理記憶部２９０に格納されているアプリケーション毎に対応する接続先に対する起動の可否を判定するための基準表の１例であるアプリケーション起動可否判定基準表２９１を示している。
【０２３２】
　図２６を参照すると、例えば、表中の１の値はアプリケーションを起動しても良いことを意味し、０の値はアプリケーションを起動できないことを意味している。この表により、例えば、アプリケーション０１は、いずれの接続先に接続されている場合でも起動できることを意味していることがわかる。また、例えば、アプリケーション０２は、オフィスに接続しているときは起動できるが、それ以外の場所では起動できないことがわかる。
【０２３３】
　アプリケーション郡２７０は、通信端末１０が備えるアプリケーションを含んでおり、アプリケーション起動管理部２６０からの要求にしたがって起動される。
【０２３４】
（第８の実施の形態の動作）
　次に、本実施の形態による通信端末１０の動作について、前述の実施の形態と異なる部分を中心に詳細に説明する。
【０２３５】
　図２７は、本実施の形態の通信端末１０の動作を示すフローチャートである。尚、本実施例に示す処理は通信端末１０を構成するコンピュータのＣＰＵ３０１が補助記憶部３０７のプログラム４００を主記憶部３０２に移して実行することが実現される。
【０２３６】
　図２７及び第７の実施の形態の動作を示す図２４を参照すると、本実施の形態の通信端末１０において、ネットワークへの接続から、接続したネットワークのカテゴリーを接続先種別判定部２２０で判定するところまでの処理（ステップＳ２４０１〜ステップＳ２４０５）は前述の第７の実施の形態の動作（ステップＳ２４０１〜ステップＳ２４０５）と同様である。
【０２３７】
　次いで、接続先種別判定部２２０は、取得したカテゴリーを保持しておく（ステップＳ２７０６）。
【０２３８】
　次いで、接続先種別判定部２２０が、アプリケーション起動インタフェース部２８０を介してあるアプリケーションを起動するよう試みることによって、アプリケーション起動インタフェース部２８０が、アプリケーション起動管理部２６０へ該アプリケーションを起動する要求を行う（ステップＳ２７０７）。
【０２３９】
　次いで、アプリケーションを起動する旨要求されたアプリケーション起動管理部２６０は、現在接続を指定されたネットワークでの該アプリケーションの起動の可否を判定する（ステップＳ２７０８）。
【０２４０】
　具体的には、アプリケーション起動管理部２６０が、該アプリケーション名と、接続先種別判定部２２０から取得したカテゴリーのそれぞれとに基づいて、該アプリケーションの起動の可否をアプリケーション起動管理記憶部２９０のアプリケーション起動可否判定基準表２９１（図２６参照）から判断する。例えば、起動しようとしているアプリケーション（アプリケーション０１）においてカテゴリーが「オフィス」であったとすると、表中では値が１となっているために起動することが許可される。
【０２４１】
　なお、アプリケーション起動管理部２６０は、アプリケーション起動管理記憶部２９０のアプリケーション起動可否判定基準表２９１に対応するカテゴリーが存在しない場合は、デフォルトの処理として、起動を許可する、許可しないなど、いずれかの処理を行うように予め設定されることが好ましい。
【０２４２】
　次いで、アプリケーション起動管理部２６０は、起動が許可された場合のみ実際にアプリケーション郡２７０の該アプリケーションを起動する（ステップＳ２７０９）。
【０２４３】
　以降の動作（ステップＳ２７１０〜ステップＳ２７１１）については、第７の実施の形態と同様の動作（ステップＳ２４０７〜ステップＳ２４０８）を行う。
【０２４４】
　本実施の形態では、接続先種別記憶部２１０及び接続先種別判定部２２０を備え、カテゴリーの分類を判定してアプリケーションの起動権利を確認するような構成であるが、接続先種別記憶部２１０及び接続先種別判定部２２０を備えず、アプリケーション起動管理部２６０は安全基準判定部１７０から直接ネットワークの信頼性及び通信路の安全性などに関する情報を通知され、それらに対するアプリケーションの起動条件をアプリケーション起動管理記憶部２９０にて格納しておくことで、ネットワークの信頼性及び通信路の安全性を示す情報に基づいて、アプリケーションの起動の可否を判断する構成でもかまわない。
【０２４５】
　このように、本実施の形態は、判定されたカテゴリー及びアプリケーション起動可否判定基準表に基づいて、セキュリティ上脆弱性の危険性があるアプリケーションの機能の実行を制限することや、アプリケーションの機能の一部又は全部の実行に制限をかけることや、警告を提示することなどを行う。また、アプリケーションの機能の実行の制限を行う旨を出力表示部１９０から出力してもよい。
【０２４６】
  また、本実施の形態でのアプリケーション郡２７０の代わりにデバイス装置とする構成も可能である。この場合、例えば、カテゴリーに対応してデバイスの起動の可否を判定するデバイス起動可否判定情報を有することによって、接続しているネットワークごとに例えばカメラ機能を制限したり、音声出力を制限したり、電話機能を制限したりといった構成、処理が可能である。
【０２４７】
　また、本発明の第８の実施の形態は、上述した本発明の第１の実施の形態から第７実施の形態のいずれにも組み合わせることが可能であり、さらに第１の実施の形態から第７の実施の形態までの任意の実施の形態を組み合わせた発明にも組み合わせることが可能である。
【０２４８】
　なお、本発明の第８の実施の形態において、アプリケーション起動管理部２６０の代わりにアプリケーションからのファイルシステムへの書き込み及び読み込みに制限をかける機能を備えてもよい。この場合、判定されたカテゴリーに関連付けて予め設定された、アプリケーションにおけるファイルシステムへの読み込み又は書き込みの可否を判定する読み書き可否判定情報を通信端末１０が保持することによって、接続しているネットワークに対応してアプリケーションのファイルシステムへの書き込み及び読み込みを制限することが可能になる。
【０２４９】
（第８の実施の形態の効果）
　次に、本発明を実施するための第８の実施の形態の効果について説明する。
【０２５０】
　本実施の形態では、アプリケーション起動管理記憶部２９０に格納されているアプリケーション毎に対応する接続先に対する起動の可否を判定するための基準表であるアプリケーション起動可否判定基準表２９１をアプリケーション起動管理記憶部２９０が保持することによって、接続しているネットワークの種別及びネットワークの信頼性、通信路の安全性に応じて通信端末１０が備えるアプリケーションの実行可否を判断する機能を設けた。このため、あるネットワークに接続している場合のみ、あるアプリケーションを実行可能とし、また、あるネットワークに接続しているときはあるアプリケーションを実行不能にすることが可能となる。
【０２５１】
　また、アプリケーションの代わりにデバイスの制御を行うように構成することによって、ある特定のネットワークに接続しているときのみカメラや音声出力デバイスを利用することができる効果が得られる。」（３０〜３２頁）
　上記刊行物３の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ．の【０２３９】、【０２４０】の記載、及び図２５〜２７によれば、刊行物３の通信端末は、アプリケーションの起動の可否をネットワークに応じて判定していることが読み取れる。
　したがって、上記刊行物３には、以下の発明（以下、「引用発明３」という。）が記載されているものと認められる。
　「アプリケーションの起動の可否を判定するためのネットワークに関する条件をアプリケーション起動管理記憶部に保持しておき、アプリケーションを起動する要求があった場合、前記条件に基づいてアプリケーションが実行可能と判定されるとアプリケーションを起動する通信端末。」
Ｄ　原査定の拒絶の理由に引用された特表２００５−５１２４２５号公報（以下、「刊行物４」という。）には、図面とともに以下の事項が記載されている。
イ．「【技術分野】
【０００１】
　本発明は、一般には、モバイル機器、およびこの種の機器に用いられるユーザー・モジュールに対するデータの格納およびアクセス技術に関するものである。通信機能（例えば、通信ネットワークを介した音声および/またはデータ伝送）およびアプリケーション・プログラム（例えば、アポイントメント・スケジューラー、またはテキスト・エディター）を備えるモバイル機器が本発明にとって１つの好ましい領域である。この種のモバイル機器は、取り分け高性能携帯電話またはＰＤＡ（携帯情報端末）として構成されている。」（４頁）
ロ．「【００１７】
　アプリケーション・プログラムが無断で実行されるのを更に防止するため、パスワードおよび/または、例えば、音声または指紋分析のような生体認証によって前記構成データの読出しを保護することが好ましい。この場合、ユーザー・モジュールは単に構成データをリリースするだけであるため、ユーザーは、パスワードおよび/または生体認証データを通して身元を証明する充分な証拠を提示することにより、対応するアプリケーション・プログラムまたはプログラム機能を実行することができる。」（６頁）
　上記刊行物４の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ．の【００１７】の記載によれば、刊行物４のモバイル機器は、ユーザが、パスワードを入力することにより対応するアプリケーションを実行している。
　したがって、上記刊行物４には、以下の発明（以下、「引用発明４」という。）が記載されているものと認められる。
　「ユーザが、パスワードを入力することにより対応するアプリケーションを実行するモバイル機器。」
Ｅ　原査定の拒絶の理由に引用された国際公開第２００８／０４４５９７号（以下、「刊行物５」という。）には、図面とともに以下の事項が記載されている。
イ．「技術分野
[0001]　この出願は、 2006年 10月 4曰に出願された EPC特許出願 06121764. 2を基礎とする優先権を主張し、その開示のすべてをここに取り込む。
[0002]　本発明は、端末と、少なくとも 1つの高速プロトコル（HSP)をサポートする UICCとの間で使用される通信プロトコルの検出および活動化を高速化する方法に関する。
[0003]　本発明はまた、少なくとも 1つの高速プロトコル（HSP)をサポートする UICCに関連する端末に関する。」（１頁）
ロ．「[0018]　したがって、 HSPインターフェースが検出されると、通信コンテキストおよびニーズ（ すなわち、端末内および UICC内に存在するアプリケーションの種類、交換される必要のあるデータ量など）に応じて、端末は検出された HSPを活動化するか否かを決定することができる。」（３頁）
　上記刊行物５の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ．の[0018]の記載によれば、刊行物５のUICCに関連する端末は、UICCアプリケーションの種類を識別している。
　したがって、上記刊行物５には、以下の発明（以下、「引用発明５」という。）が記載されているものと認められる。
　「UICCアプリケーションの種類を識別するUICCに関連する端末。」
Ｆ　原査定の拒絶の理由に引用された特開２００４−３１８８７１号公報（以下、「刊行物６」という。）には、図面とともに以下の事項が記載されている。
イ．「【技術分野】
【０００１】
　この発明は、通信装置、この電子装置とこれをネットワークを介して遠隔管理する管理装置とによって構成された遠隔管理システム、上記電子装置におけるソフトウェア更新方法、上記電子装置を制御するコンピュータに必要な機能（この発明に係わる機能）を実現させるためのプログラム、およびそのプログラムを記録した記録媒体に関する。」（５頁）
ロ．「【００４２】
　カードメモリコントローラ１４は、カードメモリ１５に対する各種データの読み書きを制御するものである。
　カードメモリ１５は、ＳＤメモリ等の記録媒体であり、ＯＳイメージを記憶するＯＳイメージメモリ，アプリ（アプリケーションプログラム）を記憶するアプリメモリや、各種データを記憶するデータメモリとして使用する不揮発性メモリ（第２の不揮発性記憶手段）である。なお、この実施例では、アプリおよびＯＳイメージ（ＯＳファイル）をファームウェアとするが、それらのいずれか、あるいは他のデータをファームウェアとしても構わない。
　なお、フラッシュＲＯＭ１３やカードメモリ１５の代わりに、ハードディスク装置等の大容量記憶装置（大容量記憶手段）を用いることもできる。あるいは、不揮発性記憶手段としてフラッシュＲＯＭ１３や大容量記憶装置等の記憶装置を１個のみ使用し、そこにフラッシュＲＯＭ１３として使用する記憶領域とカードメモリ１５として使用する記憶領域を確保するようにしてもよい。」（１２頁）
ハ．「【００５８】
　その後、ステップＳ３５でダウンロードした書き換え用のファームウェアに基づいてカードメモリ１５内のファームウェアの書き換えを実施する。
　すなわち、ダウンロードした書き換え用のファームウェアがアプリであれば、カードメモリ１５内のアプリをダウンロードしたアプリに書き換える。ダウンロードした書き換え用のファームウェアがＯＳとアプリであれば、カードメモリ１５内のＯＳとアプリをダウンロードしたＯＳとアプリに書き換える。
【００５９】
　ファームウェアの書き換えが終了すると、ステップＳ３６でその書き換えが成功したか失敗したかをチェックし、失敗すればステップＳ３９へ移行する。
　ファームウェアの書き換えが成功した場合には、ステップＳ３７でフラッシュＲＯＭ１３内のファーム書き換え中フラグを“０”にリセットすると共に、ファーム書き換え完了フラグを“１”にセットした後、ステップＳ３９でこの通信装置１を再起動させ、図６のＢへ移行して、再びステップＳ１１以降の各処理を行う。」（１５頁）
　上記刊行物６の記載及び図面並びにこの分野における技術常識を考慮すると、上記ハ．の【００５８】、【００５９】の記載、及び図７によれば、刊行物６の通信装置は、カードメモリのアプリケーションを更新した場合に、通信装置を再起動している。
　したがって、上記刊行物６には、以下の発明（以下、「引用発明６」という。）が記載されているものと認められる。
　「カードメモリのアプリケーションを更新した場合に、通信装置を再起動する通信装置。」
Ｇ　原査定の拒絶の理由に引用された特開２００１−２９１０３９号公報（以下、「刊行物７」という。）には、図面とともに以下の事項が記載されている。
イ．「【０００１】
【発明が属する技術分野】本発明は、電子決済通話システムに関し、特に、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ  Ｍｏｄｕｌｅ）カードによる電子財布機能を用いることにより固定電話や携帯電話から電話を掛けるシステムに関する。」（２頁２欄）
ロ．「【００３１】ｅ−ｗａｌｌｅｔコールシステム４０ではその要求を受けて、ダウンロード要求したＳＩＭカードが実在するかどうかの照会をＥＣ決済機構６０に対して実行する（ステップＢ２）。ＳＩＭカードが実在する場合には、「ｅ−ｗａｌｌｅｔコールサービス・アプリケーションの送信」（ステップＢ３）と「電子マネー減算表（課金表）の送信」（ステップＢ４）を行い、交換システム３０、交換ネットワーク１００を経由して、電話端末２０、２１からＳＩＭカード１０に「ｅ−ｗａｌｌｅｔコールサービス・アプリケーション」のダウンロードが完了する（ステップＢ５）。」（４頁５欄）
　上記刊行物７の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ．の【００３１】の記載によれば、刊行物７のシステムは、ネットワークを介して、電話端末からＳＩＭカードにアプリケーションをダウンロードしている。
　したがって、上記刊行物７には、以下の発明（以下、「引用発明７」という。）が記載されているものと認められる。
　「ネットワークを介して、電話端末からＳＩＭカードにアプリケーションをダウンロードするシステム。」
４．　対比
　本願発明と引用発明１とを対比する。 
ａ．引用発明１の「前記ＵＩＣＣインタフェースを介して前記ＵＩＣＣと通信する手段」と、本願発明の「前記ＵＩＣＣインタフェースを介して前記ＵＩＣＣと通信するように動作可能であるＵＩＣＣモジュール」とは、後述する相違点を除いて、「前記ＵＩＣＣインタフェースを介して前記ＵＩＣＣと通信する手段」という点で一致する。
ｂ．引用発明１の「末端使用者がアプリケーションにアクセスするのを可能にするユーザインタフェースを提供する手段」と、本願発明の「ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供するＵＩモジュール」とは、後述する相違点を除いて、「ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供する手段」という点で一致する。
ｃ．引用発明１の「末端使用者がスイッチオンにする時またはソフトウェアがリセットされた時に、アプリケーションのタイトル、アプリケーションの位置と識別子からなるメニューアイテムを前記ＵＩＣＣから取得し」と、本願発明の「ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記ＵＩＣＣ上で利用可能なＵＩＣＣアプリケーションのＵＩＣＣアプリケーションメタデータを前記ＵＩＣＣから取得するように構成され」とは、後述する相違点を除いて、「ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、ＵＩＣＣアプリケーションに関するデータを前記ＵＩＣＣから取得するように構成され」という点で一致する。
ｄ．引用発明１の「サービスメニューリストを受信して、末端使用者が、起動される専用アプリケーションを、該サービスメニューリストを介して選択することができるユーザインタフェースを構築し」と、本願発明の「前記ＵＩＣＣアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるＵＩＣＣアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり」とは、後述する相違点を除いて、「ユーザが、ユーザインタフェースであって、起動されるＵＩＣＣアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり」という点で一致する。
ｅ．引用発明１の「専用アプリケーションを選択する末端使用者入力に応答して、前記選択された専用アプリケーションを起動する」と、本願発明の「ＵＩＣＣアプリケーションを選択するユーザ入力に応答して、前記選択されたＵＩＣＣアプリケーションを起動するコマンドを前記ＵＩＣＣに送信するように動作可能であり」とは、後述する相違点を除いて、「ＵＩＣＣアプリケーションを選択するユーザ入力に応答して、前記選択されたＵＩＣＣアプリケーションを起動する」という点で一致する。
ｆ．引用発明１の「携帯端末」は、「モバイル機器」ということができる。
 　したがって、本願発明と引用発明１は、以下の点で一致ないし相違している。 
＜一致点＞ 
　「モバイル機器であって、
　ＵＩＣＣに接続するためのＵＩＣＣインタフェースと、
　前記ＵＩＣＣインタフェースを介して前記ＵＩＣＣと通信する手段と、
　前記モバイル機器によって実行される複数のアプリケーションを格納するメモリと、
　ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供する手段と、
　を有し、
　前記ＵＩＣＣと通信する手段は、ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、ＵＩＣＣアプリケーションに関するデータを前記ＵＩＣＣから取得するように構成され、
　前記ユーザインタフェース提供する手段は、ユーザが、ユーザインタフェースであって、起動されるＵＩＣＣアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり、
　前記ＵＩＣＣと通信する手段は、ＵＩＣＣアプリケーションを選択するユーザ入力に応答して、前記選択されたＵＩＣＣアプリケーションを起動する、
　モバイル機器。」
＜相違点１＞
　一致点の「ＵＩＣＣと通信する手段」に関し、
　本願発明は、「動作可能であるＵＩＣＣモジュール」であるのに対し、引用発明１は、「動作可能であるＵＩＣＣモジュール」であるかどうか明らかでない点。
　加えて、
　一致点の「ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、ＵＩＣＣアプリケーションに関するデータを前記ＵＩＣＣから取得するように構成され」に関し、
　本願発明の「ＵＩＣＣモジュール」は、「ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記ＵＩＣＣ上で利用可能なＵＩＣＣアプリケーションのＵＩＣＣアプリケーションメタデータを前記ＵＩＣＣから取得するように構成され、かつ、前記ＵＩＣＣアプリケーションメタデータを前記メモリに格納するように構成され」るのに対し、引用発明１の「ＵＩＣＣと通信する手段」は、「末端使用者がスイッチオンにする時またはソフトウェアがリセットされた時に、アプリケーションのタイトル、アプリケーションの位置と識別子からなるメニューアイテムを前記ＵＩＣＣから取得す」る点。
　加えて、
　本願発明の「ＵＩＣＣモジュール」は、「ＵＩＣＣアプリケーションを選択するユーザ入力に応答して、前記選択されたＵＩＣＣアプリケーションを起動するコマンドを前記ＵＩＣＣに送信するように動作可能である」のに対し、引用発明１の「ＵＩＣＣと通信する手段」は、「専用アプリケーションを選択する末端使用者入力に応答して、前記選択された専用アプリケーションを起動する」点。
＜相違点２＞
　一致点の「ユーザインタフェースを提供する手段」に関し、
　本願発明は、「ＵＩモジュール」であるのに対し、引用発明１は、「ＵＩモジュール」であるかどうか明らかでない点。
　加えて、
　本願発明の「ＵＩモジュール」は、「前記ＵＩＣＣアプリケーションメタデータを使用して」いるのに対し、引用発明１の「ユーザインタフェースを提供する手段」は、その様な特定がない点。
＜相違点３＞
　本願発明は、「前記ＵＩＣＣアプリケーションメタデータは、ＵＩＣＣアプリケーションを起動するのに必要な複数の条件を含み、前記ＵＩＣＣモジュールは、ＵＩＣＣアプリケーションのユーザ選択に応答して、前記選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信する前に、前記選択されたＵＩＣＣアプリケーションに関連する条件をチェックするように動作可能であり、前記条件は、必要なネットワークサービスを定め、前記ＵＩＣＣモジュールは、前記必要なネットワークサービスが利用可能であることをチェックするように動作可能であり、かつ、前記必要なネットワークサービスが利用可能な場合、前記選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信するように動作可能である」のに対し、引用発明１は、その様な特定がない点。
５．　判断
　そこで、まず、上記相違点３について検討する。
　上記「３．刊行物の記載事項」の項Ｃのとおり、「アプリケーションの起動の可否を判定するためのネットワークに関する条件をアプリケーション起動管理記憶部に保持しておき、アプリケーションを起動する要求があった場合、前記条件に基づいてアプリケーションが実行可能と判定されるとアプリケーションを起動する通信端末。」との引用発明３が記載されている。しかしながら、引用発明１の「専用アプリケーションを選択する末端使用者入力に応答して、前記選択された専用アプリケーションを起動する」に、引用発明３を採用したとしても、ネットワークサービスに関する条件を「ＵＩＣＣアプリケーションメタデータ」に含めてＵＩＣＣに予め記憶しておき、携帯端末における起動時又はリセット時の段階で、ＵＩＣＣに記憶された「ＵＩＣＣアプリケーションメタデータ」を読み出して携帯端末の記憶手段にする構成を導き出すことができない。
　また、上記「３．刊行物の記載事項」の項Ｂ、Ｄ〜Ｇに記載したように引用発明２、４〜７にも、相違点３に係る発明の「前記ＵＩＣＣアプリケーションメタデータは、ＵＩＣＣアプリケーションを起動するのに必要な複数の条件を含み、前記ＵＩＣＣモジュールは、ＵＩＣＣアプリケーションのユーザ選択に応答して、前記選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信する前に、前記選択されたＵＩＣＣアプリケーションに関連する条件をチェックするように動作可能であり、前記条件は、必要なネットワークサービスを定め、前記ＵＩＣＣモジュールは、前記必要なネットワークサービスが利用可能であることをチェックするように動作可能であり、かつ、前記必要なネットワークサービスが利用可能な場合、前記選択されたＵＩＣＣアプリケーションを起動する前記コマンドを送信するように動作可能である」に相当する事項は記載も示唆もされていないから、これら刊行物の記載によっても本願発明を導き出すことはできない。
　よって、本願発明は、上記相違点１、２について検討するまでもなく、引用発明１〜７に基いて、当業者が容易に発明をすることができたとはいえない。
（４）小括
　したがって、本願発明は、引用発明１〜７に基いて、当業者が容易に発明をすることができたとはいえない。
　請求項２、３について
　請求項２、３は、本願発明をさらに限定したものであるから、上記（３）と同じ理由により、引用発明１〜７に基づいて当業者が容易に発明をすることができたとはいえない。
　請求項４について
　請求項４は、本願発明と同様の技術的特徴を有するものであるから、上記（３）と同じ理由により、引用発明１〜７に基づいて当業者が容易に発明をすることができたとはいえない。
　請求項５について
　請求項５は、本願発明をさらに限定したものであるから、上記（３）と同じ理由により、引用発明１〜７に基づいて当業者が容易に発明をすることができたとはいえない。
６．むすび
　以上のとおり、本願の請求項１〜５に係る発明は、当業者が引用発明１〜７に基づいて容易に発明をすることができたものではないから、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。