• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04M
管理番号 1319135
審判番号 不服2016-536  
総通号数 202 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-10-28 
種別 拒絶査定不服の審決 
審判請求日 2016-01-13 
確定日 2016-09-27 
事件の表示 特願2013-500820「通信装置」拒絶査定不服審判事件〔平成23年 9月29日国際公開、WO2011/118670、平成25年 6月17日国内公表、特表2013-524567、請求項の数(5)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、2011年3月16日(パリ条約による優先権主張日本国特許庁受理2010年3月25日、英国)を国際出願日とする出願であって、平成26年12月8日付けで拒絶理由が通知され、平成27年3月9日付けで手続補正されたが、同年10月8日付けで拒絶査定がされ、これに対し、平成28年1月13日に拒絶査定不服審判が請求され、同時に手続補正がされたものである。

第2 平成28年1月13日付けの手続補正(以下、「本件補正」という。)の適否
1.補正の内容
平成27年3月9日付け手続補正による特許請求の範囲は以下のとおりである。

(補正前)
「【請求項1】
モバイル機器であって、
UICCに接続するためのUICCインタフェースと、
前記UICCインタフェースを介して前記UICCと通信するように動作可能であるUICCモジュールと、
前記モバイル機器によって実行される複数のアプリケーションを格納するメモリと、
ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供するUIモジュールと、
を有し、
前記UICCモジュールは、ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記UICC上で利用可能なUICCアプリケーションのUICCアプリケーションメタデータを前記UICCから取得するように構成され、かつ、前記UICCアプリケーションメタデータを前記メモリに格納するように構成され、
前記UIモジュールは、前記UICCアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるUICCアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり、
前記UICCモジュールは、UICCアプリケーションを選択するユーザ入力に応答して、前記選択されたUICCアプリケーションを起動するコマンドを前記UICCに送信するように動作可能である、
モバイル機器。
【請求項2】
前記UICCアプリケーションメタデータは、UICCアプリケーションを起動するのに必要な複数の条件を含み、前記UICCモジュールは、UICCアプリケーションのユーザ選択に応答して、前記選択されたUICCアプリケーションを起動する前記コマンドを送信する前に、前記選択されたUICCアプリケーションに関連する条件をチェックするように動作可能である、請求項1に記載のモバイル機器。
【請求項3】
前記条件は、必要なネットワークサービスを定め、前記UICCモジュールは、前記必要なネットワークサービスが利用可能であることをチェックするように動作可能であり、かつ、前記必要なネットワークサービスが利用可能な場合、前記選択されたUICCアプリケーションを起動する前記コマンドを送信するように動作可能である、請求項2に記載のモバイル機器。
【請求項4】
前記条件は、ユーザ認証が必要であることを定め、前記UICCモジュールは、ユーザ認証を実行するように動作可能であり、かつ、ユーザ認証が成功した場合、前記選択されたUICCアプリケーションを起動する前記コマンドを送信するように動作可能である、請求項2または3に記載のモバイル機器。
【請求項5】
前記UICCモジュールは、ユーザに、ユーザの名前とパスワードの少なくとも一方を入力するように促すことによって、そして入力されたユーザの名前とパスワードの少なくとも一方を、前記UICCアプリケーションメタデータに用意されているユーザの名前とパスワードの少なくとも一方と比較することによって、認証を実行するように動作可能である、請求項4に記載のモバイル機器。
【請求項6】
前記コマンドは、起動される前記UICCアプリケーションを識別するエンベロープコマンドである、請求項1から5のいずれかに記載のモバイル機器。
【請求項7】
前記UIモジュールは、前記モバイル機器上および前記UICC上で利用可能な複数のアプリケーションの組合せを表示するユーザインタフェースを生成するように動作可能である、請求項1から6のいずれかに記載のモバイル機器。
【請求項8】
前記UICCアプリケーションメタデータは、カテゴリデータを含み、前記UIモジュールは、同じカテゴリのUICCアプリケーションとモバイル機器アプリケーションとを前記ユーザインタフェース上でまとめるように動作可能である、請求項7に記載のモバイル機器。
【請求項9】
前記UICCアプリケーションメタデータは、エレメントファイル内の前記UICC上に格納され、前記UICCモジュールは、前記エレメントファイルから前記メタデータを読み出すように動作可能である、請求項1から8のいずれかに記載のモバイル機器。
【請求項10】
前記UICCアプリケーションメタデータは、前記UICCのために設けられたUICCサービスメニューシステムを実行するプロセッサに与えられる、請求項1から9のいずれかに記載のモバイル機器。
【請求項11】
UICCであって、
モバイル機器に接続するためのインタフェースと、
複数のUICCアプリケーションおよび該UICCアプリケーションに関するUICCアプリケーションメタデータを格納するメモリと、
前記モバイル機器と通信するように動作可能である制御モジュールと、
を有し、
前記制御モジュールは、ユーザのUICCとの相互作用の前にまたはそれとは無関係に、前記モバイル機器に前記UICCアプリケーションメタデータを与えるように動作可能であり、かつ、UICCアプリケーションを起動するコマンドを前記モバイル機器から受信するのに応答して、該UICCアプリケーションを起動するように動作可能である、
UICC。
【請求項12】
前記UICCアプリケーションメタデータは、前記モバイル機器によって使用されるUICCアプリケーションを起動するのに必要な複数の条件を含み、前記モバイル機器は、選択されたUICCアプリケーションを起動する前記コマンドを送信する前に、前記必要な条件が満たされたことをチェックする、請求項11に記載のUICC。
【請求項13】
前記条件は、必要なネットワークサービスを定める、請求項12に記載のUICC。
【請求項14】
前記条件は、ユーザ認証が必要であることを定める、請求項12または13に記載のUICC。
【請求項15】
前記UICCアプリケーションは、ユーザ名とパスワードの少なくとも一方を含む、請
求項14に記載のUICC。
【請求項16】
前記コマンドはエンベロープコマンドである、請求項11から15のいずれかに記載のUICC。
【請求項17】
前記UICCアプリケーションメタデータは、各UICCアプリケーションに関連するカテゴリを識別するカテゴリデータを含む、請求項11から16のいずれかに記載のUICC。
【請求項18】
前記UICCアプリケーションメタデータは、エレメントファイル内に格納され、USATモジュールは、前記エレメントファイルからのメタデータを前記モバイル機器に与えるように動作可能である、請求項11から17のいずれかに記載のUICC。
【請求項19】
前記USATモジュールは、前記UICCアプリケーションメタデータを、前記USATモジュールによって与えられたUICCサービスメニューシステムを有する前記モバイル機器に与えるように動作可能である、請求項11から18のいずれかに記載のUICC。
【請求項20】
前記USATモジュールは、前記UICCアプリケーションメタデータが更新された場合、前記モバイル機器を、リセットを行うように作動させるように動作可能である、請求項11から19のいずれかに記載のUICC。
【請求項21】
UICCを含むモバイル機器内で行われる方法であって、
前記モバイル機器によって実行される複数のアプリケーションをメモリに保持することと、
ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを備えることと、
ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、UICC上で利用可能な複数のUICCアプリケーションのUICCアプリケーションメタデータを取得し、前記UICCアプリケーションメタデータを前記メモリに格納することと、
前記取得されたUICCアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成することと、
UICCアプリケーションを選択するユーザ入力に応答して、前記選択されたUICCアプリケーションを起動するコマンドを前記UICCに送信することと、
を有する、UICCを含むモバイル機器内で行われる方法。
【請求項22】
UICCによって行われる方法であって、
モバイル機器に接続することと、
複数のUICCアプリケーションおよび該UICCアプリケーションに関するUICCアプリケーションメタデータを前記UICCのメモリ内に保持することと、
ユーザのUICCとの相互作用の前にまたはそれとは無関係に、前記モバイル機器に前記UICCアプリケーションメタデータを与えることと、
UICCアプリケーションを起動するコマンドを前記モバイル機器から受信するのに応答して、該UICCアプリケーションを起動することと、
を有する、UICCによって行われる方法。
【請求項23】
通信システムであって、請求項1から10のいずれかに記載のモバイル機器と、請求項11から20のいずれかに記載のUICCと、複数のUICCアプリケーションを前記UICCにダウンロードするように動作可能であるオペレータネットワークと、を有する通信システム。
【請求項24】
プログラム可能なモバイル機器を、請求項1から10のいずれかに記載のモバイル機器として構成可能にする、コンピュータで実行可能な複数の命令を含む、コンピュータで実行可能なプログラム。
【請求項25】
プログラム可能なUICCを、請求項11から20のいずれかに記載のUICCとして構成可能にする、コンピュータで実行可能な複数の命令を含む、コンピュータで実行可能なプログラム。」

また、平成28年1月13日付け手続補正による特許請求の範囲は以下のとおりである。

(補正後)
「【請求項1】
モバイル機器であって、
UICCに接続するためのUICCインタフェースと、
前記UICCインタフェースを介して前記UICCと通信するように動作可能であるUICCモジュールと、
前記モバイル機器によって実行される複数のアプリケーションを格納するメモリと、
ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供するUIモジュールと、
を有し、
前記UICCモジュールは、ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記UICC上で利用可能なUICCアプリケーションのUICCアプリケーションメタデータを前記UICCから取得するように構成され、かつ、前記UICCアプリケーションメタデータを前記メモリに格納するように構成され、
前記UIモジュールは、前記UICCアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるUICCアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり、
前記UICCモジュールは、UICCアプリケーションを選択するユーザ入力に応答して、前記選択されたUICCアプリケーションを起動するコマンドを前記UICCに送信するように動作可能であり、
前記UICCアプリケーションメタデータは、UICCアプリケーションを起動するのに必要な複数の条件を含み、前記UICCモジュールは、UICCアプリケーションのユーザ選択に応答して、前記選択されたUICCアプリケーションを起動する前記コマンドを送信する前に、前記選択されたUICCアプリケーションに関連する条件をチェックするように動作可能であり、
前記条件は、必要なネットワークサービスを定め、前記UICCモジュールは、前記必要なネットワークサービスが利用可能であることをチェックするように動作可能であり、かつ、前記必要なネットワークサービスが利用可能な場合、前記選択されたUICCアプリケーションを起動する前記コマンドを送信するように動作可能である、
モバイル機器。
【請求項2】
前記条件は、ユーザ認証が必要であることを定め、前記UICCモジュールは、ユーザ認証を実行するように動作可能であり、かつ、ユーザ認証が成功した場合、前記選択されたUICCアプリケーションを起動する前記コマンドを送信するように動作可能である、請求項1記載のモバイル機器。
【請求項3】
前記UICCモジュールは、ユーザに、ユーザの名前とパスワードの少なくとも一方を入力するように促すことによって、そして入力されたユーザの名前とパスワードの少なくとも一方を、前記UICCアプリケーションメタデータに用意されているユーザの名前とパスワードの少なくとも一方と比較することによって、認証を実行するように動作可能である、請求項2に記載のモバイル機器。
【請求項4】
UICCであって、
モバイル機器に接続するためのインタフェースと、
複数のUICCアプリケーションおよび該UICCアプリケーションに関するUICC
アプリケーションメタデータを格納するメモリと、
前記モバイル機器と通信するように動作可能である制御モジュールと、
を有し、
前記制御モジュールは、ユーザのUICCとの相互作用の前にまたはそれとは無関係に、前記モバイル機器に前記UICCアプリケーションメタデータを与えるように動作可能であり、かつ、UICCアプリケーションを起動するコマンドを前記モバイル機器から受信するのに応答して、該UICCアプリケーションを起動するように動作可能であり、
前記UICCアプリケーションメタデータは、前記モバイル機器によって使用されるUICCアプリケーションを起動するのに必要な複数の条件を含み、前記モバイル機器は、選択されたUICCアプリケーションを起動する前記コマンドを送信する前に、前記必要な条件が満たされたことをチェックし、
前記条件は、必要なネットワークサービスを定める、
UICC。
【請求項5】
通信システムであって、請求項1から3のいずれかに記載のモバイル機器と、請求項4記載のUICCと、複数のUICCアプリケーションを前記UICCにダウンロードするように動作可能であるオペレータネットワークと、を有する通信システム。」

すなわち、本件補正は、請求項1、2、6?10、14?22、24、25を削除し、請求項3、14を独立形式で記載して他の従属項を繰り上げたものである。

2.補正の適否
本件補正は、請求項1、2、6?10、14?22、24、25を削除し、請求項3、14を独立形式で記載して他の従属項を繰り上げたものであるから、特許法第17条の2第5項第1号に掲げる請求項の削除を目的とするものに該当する。
また、特許法第17条の2第3項、第4項に違反するところはない。

第3 本願発明について
1.本願発明
本願の請求項1?5に係る発明は、平成28年1月13日付けの手続補正で補正された特許請求の範囲の請求項1?5に記載された事項により特定されるものと認められるところ、本願の請求項1に係る発明(以下、「本願発明」という。)は、上記「第2 平成28年1月13日付けの手続補正(以下、「本件補正」という。)の適否」の項の「1.補正の内容」の項の「補正後」の「請求項1」のとおりのものと認める。

2.原査定の理由の概要
「拒絶理由の概要」
1.この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

2.この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第2号に規定する要件を満たしていない。

記 (引用文献等については引用文献等一覧参照)
(理由1について)
・請求項1、11、21、22
引用文献1、2
備考:
引用文献1には、モバイル機器において、UICCカードがアプリケーションタイトル等に基づいて生成した、UICCアプリケーションのメニューアイテムリストを表示し、ユーザによりUICCアプリケーションが選択されると、当該UICCアプリケーションを起動するコマンドをUICCカードに送信することが記載されている(特に、段落0010-0059、FIG.1-4)。
また、引用文献2には、モバイル機器において、USIMアプリケーション選択画面を生成することが記載されている(特に、第18頁第18-20行)。

・請求項2-5、12-15
引用文献1-4
備考:
引用文献3には、アプリケーションの起動の可否をネットワークに応じて判定することが記載されている(特に、段落0225-0251)。
引用文献4には、ユーザはパスワードを入力することにより対応するアプリケーションを実行することが記載されている(特に、段落0017)。

・請求項6、16
引用文献1-4
備考:
引用文献1には、UICCカードが、アプリケーションを識別するエンベロープコマンドを受信することが記載されている(特に、段落0020)。

・請求項9、10、24
引用文献1-4
備考:
引用文献1に記載されたUICCカードにおいて、アプリケーションタイトル等をどのように格納しておくかは単なる設計事項である。
また、例えば、引用文献2(特に、第9頁第15行-第10頁第12行)などに記載のように、UICCのファイル構造としてエレメントファイルは周知である。

・請求項17-19
引用文献1-5
備考:
引用文献5には、UICCアプリケーションの種類を識別することが記載されている(特に、段落0018)。

・請求項20、25
引用文献1-6
備考:
引用文献6には、カードメモリ15のアプリケーションを更新した場合に、通信装置1を再起動することが記載されている(特に、段落0042、0058、0059、図7)。

・請求項23
引用文献1-7
備考:
引用文献7には、ネットワークを介して、電話端末からSIMカードにアプリケーションをダウンロードするシステムが記載されている(特に、段落0031)。

(理由2について)
(中略)

引 用 文 献 等 一 覧
1.欧州特許出願公開第1962482号明細書
2.国際公開第2009/051377号
3.特開2007-116509号公報
4.特表2005-512425号公報
5.国際公開第2008/044597号
6.特開2004-318871号公報
7.特開2001-291039号公報

「原査定の概要」
・理由1(特許法第29条第2項)について

・請求項 1、11、21、22
・引用文献等 1、2
出願人は意見書において、請求項1に係る発明と、平成26年12月8日付け拒絶理由通知書に記載した引用文献1-7とを対比し、
「本願発明は、その特許請求の範囲の請求項1に記載されている通り、その特徴ある構成として『モバイル機器であって、UICCに接続するためのUICCインタフェースと、前記UICCインタフェースを介して前記UICCと通信するように動作可能であるUICCモジュールと、前記モバイル機器によって実行される複数のアプリケーションを格納するメモリと、ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供するUIモジュールと、を有し、前記UICCモジュールは、ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記UICC上で利用可能なUICCアプリケーションのUICCアプリケーションメタデータを前記UICCから取得するように構成され、かつ、前記UICCアプリケーションメタデータを前記メモリに格納するように構成され、前記UIモジュールは、前記UICCアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるUICCアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり、前記UICCモジュールは、UICCアプリケーションを選択するユーザ入力に応答して、前記選択されたUICCアプリケーションを起動するコマンドを前記UICCに送信するように動作可能である』ものです。」「しかし、引用文献1?7には、前記した本願発明の特徴ある構成要件については何ら記載されておらず、本願発明と同じ顕著な効果を達成することが期待されるものではございません。」
と主張している。

しかしながら、引用文献1には、モバイル機器において、UICCカードがアプリケーションタイトル等に基づいて生成した、UICCアプリケーションのメニューアイテムリストを表示し、ユーザによりUICCアプリケーションが選択されると、当該UICCアプリケーションを起動するコマンドをUICCカードに送信することが記載されている(特に、段落0010-0059、FIG.1-4)。
また、引用文献2には、モバイル機器において、USIMアプリケーション選択画面を生成することが記載されているから(特に、第18頁第18-20行)、引用文献1に記載されたモバイル機器に、引用文献2に記載された技術を適用し、本願の請求項1に係る発明のように構成することは当業者が容易になし得たことである。
請求項11、21、22も同様である。

・請求項 2-6、9、10、12-20、23-25
・引用文献等 1-7
平成26年12月8日付け拒絶理由通知書の備考欄に示した通りである。

よって、請求項1-6、9-25に係る発明は、引用文献1-7に基づいて、当業者であれば容易になし得たものであるから、依然として、特許法第29条第2項の規定により特許を受けることができない。

・理由2(特許法第36条第6項第2号)について
(中略)

<引用文献等一覧>
1.欧州特許出願公開第1962482号明細書
2.国際公開第2009/051377号
3.特開2007-116509号公報
4.特表2005-512425号公報
5.国際公開第2008/044597号
6.特開2004-318871号公報
7.特開2001-291039号公報

当審注:平成28年1月13日付けの手続補正で補正された特許請求の範囲の請求項1は、原査定の拒絶理由に記載中の請求項1?25のうちの請求項3に対応する。

3.刊行物の記載事項
A 原査定の拒絶の理由に引用された欧州特許出願公開第1962482号明細書(以下、「刊行物1」という。)には、図面とともに以下の事項が記載されている。

イ.「[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... 」(2頁1欄)

訳文(イ.)「[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.」(1頁2欄)

訳文(ロ.)「[0015]本発明の実施例の態様に従うと、スマートカードのような個人トークンに実装されるという方法が実際に提供される。アプリケーションは特定の場所に保存され、携帯装置上で参照されているUICCカード、SIM、USIM、Mega SIM、任意のスマートカードあるいは集積化されたチップの個人トークンに常駐することが可能である。他の実施例では、前記アプリケーションはリモートサーバに保存されることが可能である。
[0016] 図1および3で先に述べられ開示された既知の先行技術は、このようなサービスメニュー管理のために使われた機能であり、「セットアップメニュー」と呼ばれ、それはブートステージのある時点、すなわち、個人トークンに関連する携帯装置がスイッチオンになる時またはソフトウェアがリセットされた後に行われる特別な工程である。このセットアップメニューの目的は携帯端末の末端使用者に個人トークンに保存された全てのアプリケーションのタイトルを、通常はハンドセットのスクリーン上で、表示することである。
[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に対して1つが選ばれたことを確かめる。
[0043]これは個人トークンメモリー内あるいは携帯端末メモリー内においても保存された専用ファイルを使用して、個人トークンに保存された専用アプリケーションによるという例のように行われる。
[0044]待ち受けキーシーケンスは、変数もしくは前記アプリケーションのオブジェクトを使う事によっても保存することができる。
[0045]このあらかじめ定義された値は待ち受けキーシーケンスで作られ、そして携帯ネットワークオペレータによってOTA(Over The Air)を更新すること、または携帯端末の末端使用者が前記アプリケーションの専用機能を使用してあるいは個人トークンもしくは携帯端末の専用サービスを使用して変更できる。
[0046]入力した値が正確なものだった場合、待ち受けキーシーケンスと等しくなり、個人トークンは、呼2200を閉じてサービスメニューリスト2300を送信し、このリストはセットアップメニュー2310時に定義されたもののように、アイテムの識別子とサービスタイトル(アイテムのテキスト列)を含んだアイテムのメニューと共に構築される。
[0047]携帯端末はそれよりこのサービスメニューリストをそのスクリーン2400に表示し、携帯端末の末端使用者は前記サービスメニューにアクセスすることが可能になる。
[0048]開示された方法では、全ての先行ステップ中で末端使用者の視点から通知することが大切である。デフォルトスクリーンは携帯端末に表示され、そして末端使用者はこれら二つ以外の他の表示がなくメニューサービスを直接見る事になるだろう。
[0049]末端使用者が、このサービスメニュー3100の一つのアイテムを選択した時、個人トークンのオペレーションシステムはアプリケーション3010を選択し、エンベロープメニュー選択3010と同じように専用アプリケーションを起動する。」

上記刊行物1の記載及び図面並びにこの分野における技術常識を考慮すると、上記イ.の[0001]における「本発明は、末端使用者がメニュー閲覧することを容易にできるよう、メニューアクセスを簡素化した方法と装置に関連している。更に詳細に説明すれば、本発明は末端使用者の携帯端末でメニューを選択する表示が分かりやすく、そしてアクセスを行う事が簡単になる方法と装置を提供することに関連している。」との記載、上記ロ.の[0015]における「本発明の実施例の態様に従うと、スマートカードのような個人トークンに実装されるという方法が実際に提供される。アプリケーションは特定の場所に保存され、携帯装置上で参照されているUICCカード、SIM、USIM、Mega SIM、任意のスマートカードあるいは集積化されたチップの個人トークンに常駐することが可能である。」との記載、及び図4によれば、刊行物1の携帯端末は、UICCカードを備えているから、UICCに接続するためのUICCインタフェースと、UICCインタフェースを介してUICCと通信する手段とを有していることは明らかである。
また、刊行物1の携帯端末は、携帯端末によって実行される複数のアプリケーションを保存するメモリと、末端使用者がアプリケーションにアクセスするのを可能にするユーザインタフェースを提供する手段を有することは技術常識に照らして明らかである。
また、上記ロ.の[0016]における「図1および3で先に述べられ開示された既知の先行技術は、このようなサービスメニュー管理のために使われた機能性であり、「セットアップメニュー」と呼ばれ、それはブートステージのある時点、すなわち、個人トークンに関連する携帯装置がスイッチオンになる時またはソフトウェアがリセットされた後に行われる特別な工程である。このセットアップメニューの目的は携帯端末の末端使用者に個人トークンに保存された全てのアプリケーションのタイトルを、通常はハンドセットのスクリーン上で、表示することである。」との記載、同ロ.の[0017]における「個人トークンは、各サービスに対してそのアプリケーションのタイトル、アプリケーションの位置と識別子に基づいてメニューアイテムを構築する。」との記載によれば、刊行物1の携帯端末は、UICCに保存された全てのアプリケーションのタイトルをハンドセットのスクリーン上で表示するから、前述のUICCと通信する手段が、末端使用者がスイッチオンにする時またはソフトウェアがリセットされた時に、アプリケーションのタイトル、アプリケーションの位置と識別子からなるメニューアイテムをUICCから取得するということができる。
また、上記ハ.の[0046]における「入力した値が正確なものだった場合、待ち受けキーシーケンスと等しくなり、個人トークンは、呼2200を閉じてサービスメニューリスト2300を送信し、このリストはセットアップメニュー2310時に定義されたもののように、アイテムの識別子とサービスタイトル(アイテムのテキスト列)を含んだアイテムのメニューと共に構築される。」との記載、同ハの[0047]における「携帯端末はそれよりこのサービスメニューリストをそのスクリーン2400に表示し、携帯端末の末端使用者は前記サービスメニューにアクセスすることが可能になる。」との記載、及び図4によれば、刊行物1の携帯端末において、前述のユーザインタフェースを提供する手段は、サービスメニューリストを受信して、末端使用者が、起動される専用アプリケーションを、サービスメニューリストを介して選択することができるユーザインタフェースを構築するということができる。
また、上記ハ.の[0049]における「末端使用者が、このサービスメニュー3100の一つのアイテムを選択した時、個人トークンのオペレーションシステムはアプリケーション3010を選択し、エンベロプメニュー選択3010と同じように専用アプリケーションを起動する。」との記載、及び図4によれば、刊行物1の携帯端末は、UICCに常駐する専用アプリケーションを起動するから、前述のUICCと通信する手段が、専用アプリケーションを選択する末端使用者入力に応答して、選択された専用アプリケーションを起動するということができる。

したがって、上記刊行物1には、以下の発明(以下、「引用発明1」という。)が記載されているものと認められる。

「携帯端末であって、
UICCに接続するためのUICCインタフェースと、
前記UICCインタフェースを介して前記UICCと通信する手段と、
前記携帯端末によって実行される複数のアプリケーションを保存するメモリと、
末端使用者がアプリケーションにアクセスするのを可能にするユーザインタフェースを提供する手段と、
を有し、
前記UICCと通信する手段は、前記末端使用者がスイッチオンにする時またはソフトウェアがリセットされた時に、アプリケーションのタイトル、アプリケーションの位置と識別子からなるメニューアイテムを前記UICCから取得し、
前記ユーザインタフェースを提供する手段は、サービスメニューリストを受信して、前記末端使用者が、起動される専用アプリケーションを、該サービスメニューリストを介して選択することができるユーザインタフェースを構築し、
前記UICCと通信する手段は、専用アプリケーションを選択する末端使用者入力に応答して、前記選択された専用アプリケーションを起動する、
携帯端末。」

B 原査定の拒絶の理由に引用された国際公開第2009/051377号(以下、「刊行物1」という。)には、図面とともに以下の事項が記載されている。

イ.「 [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.」(1頁5?9行)

訳文(イ.)「 [技術分野]
本発明はUICCアプリケーションファイルの制御方法及びその装置に関するもので、より詳細には一つのUICCカードを用いて複数の電話番号を選択的に使用できるUICCファイル構造及びこれを用いた移動端末機におけるアプリケーション専用ファイルの制御方法に関する。」

ロ.「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).」(18頁12行?19頁4行)

訳文(ロ.)「図7は、本発明の一実施形態による移動端末機におけるアプリケーション専用ファイルの選択方法を説明するためのフローチャートである。
図7を参照すると、ステップS710で、移動端末機を起動し、ステップS720で、ME110は、UICCに接続してEFDIRファイルに含まれたレコードを分析する。
ステップS730で、ME110は、上記レコード分析からEFDIRに複数のUSIMアプリケーション専用ファイルが存在するか否かを判断する。
判断結果、複数のUSIM ADF(USIMアプリケーション専用ファイル)が存在する場合、ステップS740で、ME110は、所定のUSIMアプリケーション選択画面を生成して表示部に出力する。USIMアプリケーション選択画面は、USIMアプリケーション専用ファイル別に割り当てられたMSISDN情報を含むことが好ましい。
ステップS750で、ME110は、ユーザにより選択されたMSISDNに対応するUSIM ADF(USIMアプリケーション専用ファイル)を活性化させる。」

上記刊行物2の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ.の記載、及び図7によれば、刊行物2の移動端末機は、USIMアプリケーション選択画面を生成していることが読み取れる。

したがって、上記刊行物2には、以下の発明(以下、「引用発明2」という。)が記載されているものと認められる。

「USIMアプリケーション選択画面を生成する移動端末機。」

C 原査定の拒絶の理由に引用された特開2007-116509号公報(以下、「刊行物3」という。)には、図面とともに以下の事項が記載されている。

イ.「【技術分野】
【0001】
本発明は、無線通信ネットワークシステムにおけるネットワークのセキュリティ情報の出力に関し、特に複数の無線通信ネットワークのセキュリティ情報を出力する通信端末、プログラム、通信システム及びセキュリティ情報出力方法に関する。」(6頁)

ロ.「【0225】
(第8の実施の形態)
次に、本発明の第8の実施の形態について図面を参照して詳細に説明する。
【0226】
(第8の実施の形態の構成)
図25は、本発明の第8の実施の形態による通信端末10の構成を示したブロック図である。第8の実施の形態による通信端末10は、アプリケーション起動インタフェース部280、アプリケーション起動管理部260、アプリケーション起動管理記憶部290及びアプリケーション郡270を備える点で、前述の第7の実施の形態による通信端末10と異なる。
【0227】
アプリケーション起動インタフェース部280は、アプリケーション郡270のアプリケーションを起動する際のインタフェースであって、アプリケーション起動管理部260に対してあるアプリケーションを起動することを要求する機能を有する。
【0228】
アプリケーション起動管理部260は、アプリケーション起動インタフェース部280から要求されたアプリケーションを起動しても良いか否かを判断して、起動してもよい場合は該アプリケーションを起動し、起動してはいけない場合は該アプリケーションを起動しない機能を有する。
【0229】
また、アプリケーション起動管理部260は、接続先種別判定部220から通知された情報に基づいて、アプリケーション起動管理記憶部290に格納されている情報と比較して、該アプリケーションを起動しても良いか否かの判断をする機能を有する。
【0230】
アプリケーション起動管理記憶部290は、アプリケーション郡270の各アプリケーションに対して接続先種別記憶部210に記憶されているカテゴリー毎に格納している。
【0231】
図26は、アプリケーション起動管理記憶部290に格納されているアプリケーション毎に対応する接続先に対する起動の可否を判定するための基準表の1例であるアプリケーション起動可否判定基準表291を示している。
【0232】
図26を参照すると、例えば、表中の1の値はアプリケーションを起動しても良いことを意味し、0の値はアプリケーションを起動できないことを意味している。この表により、例えば、アプリケーション01は、いずれの接続先に接続されている場合でも起動できることを意味していることがわかる。また、例えば、アプリケーション02は、オフィスに接続しているときは起動できるが、それ以外の場所では起動できないことがわかる。
【0233】
アプリケーション郡270は、通信端末10が備えるアプリケーションを含んでおり、アプリケーション起動管理部260からの要求にしたがって起動される。
【0234】
(第8の実施の形態の動作)
次に、本実施の形態による通信端末10の動作について、前述の実施の形態と異なる部分を中心に詳細に説明する。
【0235】
図27は、本実施の形態の通信端末10の動作を示すフローチャートである。尚、本実施例に示す処理は通信端末10を構成するコンピュータのCPU301が補助記憶部307のプログラム400を主記憶部302に移して実行することが実現される。
【0236】
図27及び第7の実施の形態の動作を示す図24を参照すると、本実施の形態の通信端末10において、ネットワークへの接続から、接続したネットワークのカテゴリーを接続先種別判定部220で判定するところまでの処理(ステップS2401?ステップS2405)は前述の第7の実施の形態の動作(ステップS2401?ステップS2405)と同様である。
【0237】
次いで、接続先種別判定部220は、取得したカテゴリーを保持しておく(ステップS2706)。
【0238】
次いで、接続先種別判定部220が、アプリケーション起動インタフェース部280を介してあるアプリケーションを起動するよう試みることによって、アプリケーション起動インタフェース部280が、アプリケーション起動管理部260へ該アプリケーションを起動する要求を行う(ステップS2707)。
【0239】
次いで、アプリケーションを起動する旨要求されたアプリケーション起動管理部260は、現在接続を指定されたネットワークでの該アプリケーションの起動の可否を判定する(ステップS2708)。
【0240】
具体的には、アプリケーション起動管理部260が、該アプリケーション名と、接続先種別判定部220から取得したカテゴリーのそれぞれとに基づいて、該アプリケーションの起動の可否をアプリケーション起動管理記憶部290のアプリケーション起動可否判定基準表291(図26参照)から判断する。例えば、起動しようとしているアプリケーション(アプリケーション01)においてカテゴリーが「オフィス」であったとすると、表中では値が1となっているために起動することが許可される。
【0241】
なお、アプリケーション起動管理部260は、アプリケーション起動管理記憶部290のアプリケーション起動可否判定基準表291に対応するカテゴリーが存在しない場合は、デフォルトの処理として、起動を許可する、許可しないなど、いずれかの処理を行うように予め設定されることが好ましい。
【0242】
次いで、アプリケーション起動管理部260は、起動が許可された場合のみ実際にアプリケーション郡270の該アプリケーションを起動する(ステップS2709)。
【0243】
以降の動作(ステップS2710?ステップS2711)については、第7の実施の形態と同様の動作(ステップS2407?ステップS2408)を行う。
【0244】
本実施の形態では、接続先種別記憶部210及び接続先種別判定部220を備え、カテゴリーの分類を判定してアプリケーションの起動権利を確認するような構成であるが、接続先種別記憶部210及び接続先種別判定部220を備えず、アプリケーション起動管理部260は安全基準判定部170から直接ネットワークの信頼性及び通信路の安全性などに関する情報を通知され、それらに対するアプリケーションの起動条件をアプリケーション起動管理記憶部290にて格納しておくことで、ネットワークの信頼性及び通信路の安全性を示す情報に基づいて、アプリケーションの起動の可否を判断する構成でもかまわない。
【0245】
このように、本実施の形態は、判定されたカテゴリー及びアプリケーション起動可否判定基準表に基づいて、セキュリティ上脆弱性の危険性があるアプリケーションの機能の実行を制限することや、アプリケーションの機能の一部又は全部の実行に制限をかけることや、警告を提示することなどを行う。また、アプリケーションの機能の実行の制限を行う旨を出力表示部190から出力してもよい。
【0246】
また、本実施の形態でのアプリケーション郡270の代わりにデバイス装置とする構成も可能である。この場合、例えば、カテゴリーに対応してデバイスの起動の可否を判定するデバイス起動可否判定情報を有することによって、接続しているネットワークごとに例えばカメラ機能を制限したり、音声出力を制限したり、電話機能を制限したりといった構成、処理が可能である。
【0247】
また、本発明の第8の実施の形態は、上述した本発明の第1の実施の形態から第7実施の形態のいずれにも組み合わせることが可能であり、さらに第1の実施の形態から第7の実施の形態までの任意の実施の形態を組み合わせた発明にも組み合わせることが可能である。
【0248】
なお、本発明の第8の実施の形態において、アプリケーション起動管理部260の代わりにアプリケーションからのファイルシステムへの書き込み及び読み込みに制限をかける機能を備えてもよい。この場合、判定されたカテゴリーに関連付けて予め設定された、アプリケーションにおけるファイルシステムへの読み込み又は書き込みの可否を判定する読み書き可否判定情報を通信端末10が保持することによって、接続しているネットワークに対応してアプリケーションのファイルシステムへの書き込み及び読み込みを制限することが可能になる。
【0249】
(第8の実施の形態の効果)
次に、本発明を実施するための第8の実施の形態の効果について説明する。
【0250】
本実施の形態では、アプリケーション起動管理記憶部290に格納されているアプリケーション毎に対応する接続先に対する起動の可否を判定するための基準表であるアプリケーション起動可否判定基準表291をアプリケーション起動管理記憶部290が保持することによって、接続しているネットワークの種別及びネットワークの信頼性、通信路の安全性に応じて通信端末10が備えるアプリケーションの実行可否を判断する機能を設けた。このため、あるネットワークに接続している場合のみ、あるアプリケーションを実行可能とし、また、あるネットワークに接続しているときはあるアプリケーションを実行不能にすることが可能となる。
【0251】
また、アプリケーションの代わりにデバイスの制御を行うように構成することによって、ある特定のネットワークに接続しているときのみカメラや音声出力デバイスを利用することができる効果が得られる。」(30?32頁)

上記刊行物3の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ.の【0239】、【0240】の記載、及び図25?27によれば、刊行物3の通信端末は、アプリケーションの起動の可否をネットワークに応じて判定していることが読み取れる。

したがって、上記刊行物3には、以下の発明(以下、「引用発明3」という。)が記載されているものと認められる。

「アプリケーションの起動の可否を判定するためのネットワークに関する条件をアプリケーション起動管理記憶部に保持しておき、アプリケーションを起動する要求があった場合、前記条件に基づいてアプリケーションが実行可能と判定されるとアプリケーションを起動する通信端末。」

D 原査定の拒絶の理由に引用された特表2005-512425号公報(以下、「刊行物4」という。)には、図面とともに以下の事項が記載されている。

イ.「【技術分野】
【0001】
本発明は、一般には、モバイル機器、およびこの種の機器に用いられるユーザー・モジュールに対するデータの格納およびアクセス技術に関するものである。通信機能(例えば、通信ネットワークを介した音声および/またはデータ伝送)およびアプリケーション・プログラム(例えば、アポイントメント・スケジューラー、またはテキスト・エディター)を備えるモバイル機器が本発明にとって1つの好ましい領域である。この種のモバイル機器は、取り分け高性能携帯電話またはPDA(携帯情報端末)として構成されている。」(4頁)

ロ.「【0017】
アプリケーション・プログラムが無断で実行されるのを更に防止するため、パスワードおよび/または、例えば、音声または指紋分析のような生体認証によって前記構成データの読出しを保護することが好ましい。この場合、ユーザー・モジュールは単に構成データをリリースするだけであるため、ユーザーは、パスワードおよび/または生体認証データを通して身元を証明する充分な証拠を提示することにより、対応するアプリケーション・プログラムまたはプログラム機能を実行することができる。」(6頁)

上記刊行物4の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ.の【0017】の記載によれば、刊行物4のモバイル機器は、ユーザが、パスワードを入力することにより対応するアプリケーションを実行している。

したがって、上記刊行物4には、以下の発明(以下、「引用発明4」という。)が記載されているものと認められる。

「ユーザが、パスワードを入力することにより対応するアプリケーションを実行するモバイル機器。」

E 原査定の拒絶の理由に引用された国際公開第2008/044597号(以下、「刊行物5」という。)には、図面とともに以下の事項が記載されている。

イ.「技術分野
[0001] この出願は、 2006年 10月 4曰に出願された EPC特許出願 06121764. 2を基礎とする優先権を主張し、その開示のすべてをここに取り込む。
[0002] 本発明は、端末と、少なくとも 1つの高速プロトコル(HSP)をサポートする UICCとの間で使用される通信プロトコルの検出および活動化を高速化する方法に関する。
[0003] 本発明はまた、少なくとも 1つの高速プロトコル(HSP)をサポートする UICCに関連する端末に関する。」(1頁)

ロ.「[0018] したがって、 HSPインターフェースが検出されると、通信コンテキストおよびニーズ( すなわち、端末内および UICC内に存在するアプリケーションの種類、交換される必要のあるデータ量など)に応じて、端末は検出された HSPを活動化するか否かを決定することができる。」(3頁)

上記刊行物5の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ.の[0018]の記載によれば、刊行物5のUICCに関連する端末は、UICCアプリケーションの種類を識別している。

したがって、上記刊行物5には、以下の発明(以下、「引用発明5」という。)が記載されているものと認められる。

「UICCアプリケーションの種類を識別するUICCに関連する端末。」

F 原査定の拒絶の理由に引用された特開2004-318871号公報(以下、「刊行物6」という。)には、図面とともに以下の事項が記載されている。

イ.「【技術分野】
【0001】
この発明は、通信装置、この電子装置とこれをネットワークを介して遠隔管理する管理装置とによって構成された遠隔管理システム、上記電子装置におけるソフトウェア更新方法、上記電子装置を制御するコンピュータに必要な機能(この発明に係わる機能)を実現させるためのプログラム、およびそのプログラムを記録した記録媒体に関する。」(5頁)

ロ.「【0042】
カードメモリコントローラ14は、カードメモリ15に対する各種データの読み書きを制御するものである。
カードメモリ15は、SDメモリ等の記録媒体であり、OSイメージを記憶するOSイメージメモリ,アプリ(アプリケーションプログラム)を記憶するアプリメモリや、各種データを記憶するデータメモリとして使用する不揮発性メモリ(第2の不揮発性記憶手段)である。なお、この実施例では、アプリおよびOSイメージ(OSファイル)をファームウェアとするが、それらのいずれか、あるいは他のデータをファームウェアとしても構わない。
なお、フラッシュROM13やカードメモリ15の代わりに、ハードディスク装置等の大容量記憶装置(大容量記憶手段)を用いることもできる。あるいは、不揮発性記憶手段としてフラッシュROM13や大容量記憶装置等の記憶装置を1個のみ使用し、そこにフラッシュROM13として使用する記憶領域とカードメモリ15として使用する記憶領域を確保するようにしてもよい。」(12頁)

ハ.「【0058】
その後、ステップS35でダウンロードした書き換え用のファームウェアに基づいてカードメモリ15内のファームウェアの書き換えを実施する。
すなわち、ダウンロードした書き換え用のファームウェアがアプリであれば、カードメモリ15内のアプリをダウンロードしたアプリに書き換える。ダウンロードした書き換え用のファームウェアがOSとアプリであれば、カードメモリ15内のOSとアプリをダウンロードしたOSとアプリに書き換える。
【0059】
ファームウェアの書き換えが終了すると、ステップS36でその書き換えが成功したか失敗したかをチェックし、失敗すればステップS39へ移行する。
ファームウェアの書き換えが成功した場合には、ステップS37でフラッシュROM13内のファーム書き換え中フラグを“0”にリセットすると共に、ファーム書き換え完了フラグを“1”にセットした後、ステップS39でこの通信装置1を再起動させ、図6のBへ移行して、再びステップS11以降の各処理を行う。」(15頁)

上記刊行物6の記載及び図面並びにこの分野における技術常識を考慮すると、上記ハ.の【0058】、【0059】の記載、及び図7によれば、刊行物6の通信装置は、カードメモリのアプリケーションを更新した場合に、通信装置を再起動している。

したがって、上記刊行物6には、以下の発明(以下、「引用発明6」という。)が記載されているものと認められる。

「カードメモリのアプリケーションを更新した場合に、通信装置を再起動する通信装置。」

G 原査定の拒絶の理由に引用された特開2001-291039号公報(以下、「刊行物7」という。)には、図面とともに以下の事項が記載されている。

イ.「【0001】
【発明が属する技術分野】本発明は、電子決済通話システムに関し、特に、SIM(Subscriber Identity Module)カードによる電子財布機能を用いることにより固定電話や携帯電話から電話を掛けるシステムに関する。」(2頁2欄)

ロ.「【0031】e-walletコールシステム40ではその要求を受けて、ダウンロード要求したSIMカードが実在するかどうかの照会をEC決済機構60に対して実行する(ステップB2)。SIMカードが実在する場合には、「e-walletコールサービス・アプリケーションの送信」(ステップB3)と「電子マネー減算表(課金表)の送信」(ステップB4)を行い、交換システム30、交換ネットワーク100を経由して、電話端末20、21からSIMカード10に「e-walletコールサービス・アプリケーション」のダウンロードが完了する(ステップB5)。」(4頁5欄)

上記刊行物7の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ.の【0031】の記載によれば、刊行物7のシステムは、ネットワークを介して、電話端末からSIMカードにアプリケーションをダウンロードしている。

したがって、上記刊行物7には、以下の発明(以下、「引用発明7」という。)が記載されているものと認められる。

「ネットワークを介して、電話端末からSIMカードにアプリケーションをダウンロードするシステム。」

4. 対比
本願発明と引用発明1とを対比する。
a.引用発明1の「前記UICCインタフェースを介して前記UICCと通信する手段」と、本願発明の「前記UICCインタフェースを介して前記UICCと通信するように動作可能であるUICCモジュール」とは、後述する相違点を除いて、「前記UICCインタフェースを介して前記UICCと通信する手段」という点で一致する。
b.引用発明1の「末端使用者がアプリケーションにアクセスするのを可能にするユーザインタフェースを提供する手段」と、本願発明の「ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供するUIモジュール」とは、後述する相違点を除いて、「ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供する手段」という点で一致する。
c.引用発明1の「末端使用者がスイッチオンにする時またはソフトウェアがリセットされた時に、アプリケーションのタイトル、アプリケーションの位置と識別子からなるメニューアイテムを前記UICCから取得し」と、本願発明の「ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記UICC上で利用可能なUICCアプリケーションのUICCアプリケーションメタデータを前記UICCから取得するように構成され」とは、後述する相違点を除いて、「ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、UICCアプリケーションに関するデータを前記UICCから取得するように構成され」という点で一致する。
d.引用発明1の「サービスメニューリストを受信して、末端使用者が、起動される専用アプリケーションを、該サービスメニューリストを介して選択することができるユーザインタフェースを構築し」と、本願発明の「前記UICCアプリケーションメタデータを使用して、ユーザが、ユーザインタフェースであって、起動されるUICCアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり」とは、後述する相違点を除いて、「ユーザが、ユーザインタフェースであって、起動されるUICCアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり」という点で一致する。
e.引用発明1の「専用アプリケーションを選択する末端使用者入力に応答して、前記選択された専用アプリケーションを起動する」と、本願発明の「UICCアプリケーションを選択するユーザ入力に応答して、前記選択されたUICCアプリケーションを起動するコマンドを前記UICCに送信するように動作可能であり」とは、後述する相違点を除いて、「UICCアプリケーションを選択するユーザ入力に応答して、前記選択されたUICCアプリケーションを起動する」という点で一致する。
f.引用発明1の「携帯端末」は、「モバイル機器」ということができる。

したがって、本願発明と引用発明1は、以下の点で一致ないし相違している。

<一致点>
「モバイル機器であって、
UICCに接続するためのUICCインタフェースと、
前記UICCインタフェースを介して前記UICCと通信する手段と、
前記モバイル機器によって実行される複数のアプリケーションを格納するメモリと、
ユーザがアプリケーションにアクセスするのを可能にするユーザインタフェースを提供する手段と、
を有し、
前記UICCと通信する手段は、ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、UICCアプリケーションに関するデータを前記UICCから取得するように構成され、
前記ユーザインタフェース提供する手段は、ユーザが、ユーザインタフェースであって、起動されるUICCアプリケーションを、該ユーザインタフェースを介して選択することができるユーザインタフェースを生成するように動作可能であり、
前記UICCと通信する手段は、UICCアプリケーションを選択するユーザ入力に応答して、前記選択されたUICCアプリケーションを起動する、
モバイル機器。」

<相違点1>
一致点の「UICCと通信する手段」に関し、
本願発明は、「動作可能であるUICCモジュール」であるのに対し、引用発明1は、「動作可能であるUICCモジュール」であるかどうか明らかでない点。
加えて、
一致点の「ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、UICCアプリケーションに関するデータを前記UICCから取得するように構成され」に関し、
本願発明の「UICCモジュール」は、「ユーザの前記ユーザインタフェースとの相互作用の前にまたはそれとは無関係に、前記UICC上で利用可能なUICCアプリケーションのUICCアプリケーションメタデータを前記UICCから取得するように構成され、かつ、前記UICCアプリケーションメタデータを前記メモリに格納するように構成され」るのに対し、引用発明1の「UICCと通信する手段」は、「末端使用者がスイッチオンにする時またはソフトウェアがリセットされた時に、アプリケーションのタイトル、アプリケーションの位置と識別子からなるメニューアイテムを前記UICCから取得す」る点。
加えて、
本願発明の「UICCモジュール」は、「UICCアプリケーションを選択するユーザ入力に応答して、前記選択されたUICCアプリケーションを起動するコマンドを前記UICCに送信するように動作可能である」のに対し、引用発明1の「UICCと通信する手段」は、「専用アプリケーションを選択する末端使用者入力に応答して、前記選択された専用アプリケーションを起動する」点。

<相違点2>
一致点の「ユーザインタフェースを提供する手段」に関し、
本願発明は、「UIモジュール」であるのに対し、引用発明1は、「UIモジュール」であるかどうか明らかでない点。
加えて、
本願発明の「UIモジュール」は、「前記UICCアプリケーションメタデータを使用して」いるのに対し、引用発明1の「ユーザインタフェースを提供する手段」は、その様な特定がない点。

<相違点3>
本願発明は、「前記UICCアプリケーションメタデータは、UICCアプリケーションを起動するのに必要な複数の条件を含み、前記UICCモジュールは、UICCアプリケーションのユーザ選択に応答して、前記選択されたUICCアプリケーションを起動する前記コマンドを送信する前に、前記選択されたUICCアプリケーションに関連する条件をチェックするように動作可能であり、前記条件は、必要なネットワークサービスを定め、前記UICCモジュールは、前記必要なネットワークサービスが利用可能であることをチェックするように動作可能であり、かつ、前記必要なネットワークサービスが利用可能な場合、前記選択されたUICCアプリケーションを起動する前記コマンドを送信するように動作可能である」のに対し、引用発明1は、その様な特定がない点。

5. 判断
そこで、まず、上記相違点3について検討する。
上記「3.刊行物の記載事項」の項Cのとおり、「アプリケーションの起動の可否を判定するためのネットワークに関する条件をアプリケーション起動管理記憶部に保持しておき、アプリケーションを起動する要求があった場合、前記条件に基づいてアプリケーションが実行可能と判定されるとアプリケーションを起動する通信端末。」との引用発明3が記載されている。しかしながら、引用発明1の「専用アプリケーションを選択する末端使用者入力に応答して、前記選択された専用アプリケーションを起動する」に、引用発明3を採用したとしても、ネットワークサービスに関する条件を「UICCアプリケーションメタデータ」に含めてUICCに予め記憶しておき、携帯端末における起動時又はリセット時の段階で、UICCに記憶された「UICCアプリケーションメタデータ」を読み出して携帯端末の記憶手段にする構成を導き出すことができない。
また、上記「3.刊行物の記載事項」の項B、D?Gに記載したように引用発明2、4?7にも、相違点3に係る発明の「前記UICCアプリケーションメタデータは、UICCアプリケーションを起動するのに必要な複数の条件を含み、前記UICCモジュールは、UICCアプリケーションのユーザ選択に応答して、前記選択されたUICCアプリケーションを起動する前記コマンドを送信する前に、前記選択されたUICCアプリケーションに関連する条件をチェックするように動作可能であり、前記条件は、必要なネットワークサービスを定め、前記UICCモジュールは、前記必要なネットワークサービスが利用可能であることをチェックするように動作可能であり、かつ、前記必要なネットワークサービスが利用可能な場合、前記選択されたUICCアプリケーションを起動する前記コマンドを送信するように動作可能である」に相当する事項は記載も示唆もされていないから、これら刊行物の記載によっても本願発明を導き出すことはできない。

よって、本願発明は、上記相違点1、2について検討するまでもなく、引用発明1?7に基いて、当業者が容易に発明をすることができたとはいえない。

(4)小括
したがって、本願発明は、引用発明1?7に基いて、当業者が容易に発明をすることができたとはいえない。

請求項2、3について
請求項2、3は、本願発明をさらに限定したものであるから、上記(3)と同じ理由により、引用発明1?7に基づいて当業者が容易に発明をすることができたとはいえない。

請求項4について
請求項4は、本願発明と同様の技術的特徴を有するものであるから、上記(3)と同じ理由により、引用発明1?7に基づいて当業者が容易に発明をすることができたとはいえない。

請求項5について
請求項5は、本願発明をさらに限定したものであるから、上記(3)と同じ理由により、引用発明1?7に基づいて当業者が容易に発明をすることができたとはいえない。

6.むすび
以上のとおり、本願の請求項1?5に係る発明は、当業者が引用発明1?7に基づいて容易に発明をすることができたものではないから、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。

 
審決日 2016-09-14 
出願番号 特願2013-500820(P2013-500820)
審決分類 P 1 8・ 121- WY (H04M)
最終処分 成立  
前審関与審査官 松原 徳久  
特許庁審判長 大塚 良平
特許庁審判官 林 毅
萩原 義則
発明の名称 通信装置  
代理人 丸山 隆夫  
  • この表をプリントする

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