【事件の表示】
　特許第６３７５４６４号発明「発信者情報表示装置及びプログラム」の特許異議申立事件について、次のとおり決定する。
【結　論】
　特許第６３７５４６４号の請求項１ないし４に係る特許を維持する。
【理　由】
第１　手続の経緯
　特許第６３７５４６４号の請求項１〜４に係る発明についての出願は、平成２９年１１月３０日に出願した特願２０１７−２３０４１７号（以下、「原出願」という。）の一部を、平成３０年３月９日に新たな特許出願とした特願２０１８−４３４７９号に係るものであって、平成３０年７月２７日にその特許権の設定登録がされ、平成３０年８月１５日に特許公報が発行された。その後、その特許に対し、平成３１年２月１４日に特許異議申立人澤木紀一（以下、「異議申立人」という。）より、全請求項に対して特許異議の申立てがなされた。
第２　本件発明
　特許第６３７５４６４号の請求項１〜４の特許に係る発明は、それぞれ、その特許請求の範囲の請求項１〜４に記載された事項により特定される次のとおりのものである。
「【請求項１】
　基本ソフトウェアによって制御されるとともに、前記基本ソフトウェア上で動作するアプリケーション・プログラムを実行するプロセッサと、
　前記基本ソフトウェアと前記アプリケーション・プログラムとを記憶する領域と、利用者がアクセスできない秘匿領域を含む記憶手段と、
　発信元電話機より電話着信を受ける通信手段と、
を備え、
　前記アプリケーション・プログラムは、前記プロセッサを
　電話番号と当該電話番号に対応する名称情報とを含むデータを前記秘匿領域に格納する手段と、
　前記データに含まれる電話番号及び名称情報を、前記秘匿領域に格納されており前記電話着信を受けた場合に前記基本ソフトウェアが検索可能であって、かつ利用者がアクセスできない第１の発信者データへ登録する手段と、
して機能させる
ことを特徴とする発信者情報表示装置。
【請求項２】
　前記記憶手段は利用者がアクセス可能な公開領域をさらに含み、前記公開領域には、前記利用者の登録命令に応じて電話番号及び名称情報が登録される第２の発信者データが格納され、
　前記発信元電話機より前記電話着信を受けた場合に、前記発信元電話機の発信者電話番号に基づいて前記第２の発信者データを検索し、前記第２の発信者データに前記発信者電話番号が含まれない場合に、前記第１の発信者データを検索する検索手段と、
　前記電話着信を受けた場合に発信元に関する情報を表示し、前記第１の発信者データに前記発信者電話番号が含まれる場合に、前記発信者電話番号に対応する名称情報を表示する表示手段と、
をさらに備える
ことを特徴とする請求項１に記載の発信者情報表示装置。
【請求項３】
　コンピュータの基本ソフトウェアによって制御されるとともに、前記基本ソフトウェア上で動作するプログラムであって、
　前記コンピュータを、
　電話番号と当該電話番号に対応する名称情報とを含むデータを、前記コンピュータが備える記憶手段のうち利用者がアクセスできない秘匿領域に格納する格納手段と、
　前記データに含まれる電話番号及び名称情報を、前記秘匿領域に格納されており電話着信を受けた場合に前記基本ソフトウェアが検索可能であって、かつ利用者がアクセスできない発信者データへ登録する登録手段と
して機能させるためのプログラム。
【請求項４】
　前記格納手段は、前記データを暗号化し、
　前記登録手段は、前記暗号化された前記データを復号する
ことを特徴とする請求項３に記載のプログラム。」（以下、請求項１〜４に係る発明を、順に「本件発明１〜４」といい、総称して「本件発明」という。）
第３　申立理由の概要
　異議申立人は、本件の請求項１〜４に係る特許は、取消理由１及び取消理由２により、取り消されるべき旨を主張する。
１．取消理由１の概要
　異議申立人は、取消理由１として、本件の請求項１〜４に係る特許は発明の詳細な説明に記載されておらず、不明確であること（特許法第３６条第６項第１号ないし２号）、発明の詳細な説明の記載はいわゆる当業者が実施できる程度に明確かつ十分でないこと（特許法第３６条第４項第１号）を主張し、具体的な理由として、以下の（１−１）〜（１−３）を主張している。
（１−１）本件発明１〜４について、「利用者がアクセスできない秘匿領域」の実現手段が開示されておらず（特許法第３６条第６項第１号違反）、不明確であり（特許法第３６条第６項第２号違反）、発明の詳細な説明の記載は当業者が「利用者がアクセスできない秘匿領域」を実施できる程度に明確かつ十分でもないこと（第３６条第４項第１号違反）（以下、「取消理由１−１」という。）
（１−２）本件発明１は、「発信者情報表示装置」であるにも関わらず、「表示装置」または「表示手段」（さらには発信者特定手段）を備えていないものが含まれること（特許法第３６条第６項第２号違反）（以下、「取消理由１−２」という。）
（１−３）本件発明１〜４について、「利用者がアクセスできない秘匿領域」およびこれを利用する処理の技術的意義が不明確であること（特許法第３６条第６項第１号ないし第２号違反）（以下、「取消理由１−３」という。）
２．取消理由２の概要
　異議申立人は、証拠として、甲第１〜１１号証を提出し、本件発明１〜４はCallKitを含むiOS（iOS10）にしたがって動作し、かつCallKitを利用するアプリケーション・プログラムがインストールされたiPhone（iPhone 7）そのものを規定するにすぎないこと（当業者であれば、CallKitを含むiOS（iOS10）に関する知識に基づいて本件発明１〜４を容易に想到できたこと）（特許法第２９条第２項違反）を主張している。
　取消理由２の証拠として提出された、甲第１〜１１号証は以下のとおりである。
甲第１の１号証：「CallKit | Apple Developer Documentation」インターネットアーカイブに保存されている、2017.7.14時点におけるApple Inc.のウェブページ
甲第１の２号証：「CallKit | Apple Developer Documentation」インターネットアーカイブに保存されている、2017.7.14時点におけるApple Inc.のウェブページ（甲第１の１において、４枚目のプログラム記述部分中、印字されていない部分を印字するもの）
甲第２号証：「addIdentificationEntry(withNextSequentialPhoneNumber:label:)」Apple Inc.のCallKitに関する開発者向け資料のウェブページ
甲第３号証：「CXCallDirectoryExtensionContext」Apple Inc.のCallKitに関する開発者向け資料のウェブページ
甲第４号証：「What are Frameworks?」Apple Inc.のフレームワークを解説するウェブページ
甲第５号証：「App Extension Programming Guide: Understand How an App Extension Works」Apple Inc.のApp Extensionを説明するウェブページ
甲第６号証：「iOSのセキュリティ iOS10」
甲第７の１号証：「File System Programming Guide: File System Basics」Apple Inc.のFile System Basicsを説明するウェブページ
甲第７の２号証：File System Programming Guideのリビジョンヒストリ
甲第７の３号証：iOSアプリのファイル保存について
甲第８号証：「iPhone 7の仕様」インターネットアーカイブに保存されている、2016.9.7時点におけるApple Inc.のウェブページ
甲第９号証：「What’s new in iOS 10 News room」
甲第１０号証：「Documentation Archive, What’s New in iOS, iOS 10.0」
甲第１１号証：「Appleセキュリティアップデート」
第４　当審の判断
１．取消理由１について
（１）取消理由１−１について
　異議申立人は、「利用者がアクセスできない秘匿領域」について、本件特許明細書はその具体的な実現手段を全く説明しておらず、いわば願望を述べるにとどまっており、特に「削除」に関しては、利用者が（発信者情報データＸ３を削除）「できる」という記載および「できない」という記載がどちらも存在し、「できる」ようにするための具体的構成も、「できない」ようにするための具体的な構成も全く説明していない旨を主張している。
　ここで、本件明細書の【００２８】には、「秘匿領域Ｘは、利用者Ｕがアクセスすることができない領域である。秘匿領域Ｘは、例えばアプリケーション領域などである。」と記載されている。
　一方、異議申立人は、利用者がアクセスすることができない領域及びアクセスできる領域の具体的な実現手段や具体的構成が全く説明されていないと主張する。
　しかし、後記２−２（３）に記載されるように２０１６年８月１９日（平成２８年８月１９日）に掲載された甲第７号証の３の１枚目には、iOSアプリケーションは通常、「Library」ディレクトリに用意した、Application SupportおよびCachesのサブディレクトリを使い、「Libraryサブディレクトリ以下」に置いた、すなわち、保存したファイルについて、ユーザが見ることができないことが記載されている。iOSアプリケーションがファイルを保存する「Libraryサブディレクトリ」は、アプリケーションが使用する領域であるから、「アプリケーション領域」に他ならない。つまり、甲第７号証の３には、「アプリケーション領域」である「Libraryサブディレクトリ」は、ユーザが見ることができない（アクセスできない）ようにファイルを保存する領域、すなわち秘匿領域であることが記載されている。
　したがって、「アプリケーション領域」である「Libraryサブディレクトリ」を用いることで、基本ソフトウェア（iOS）のファイルシステムによって、利用者がアクセスできないように記憶領域へのアクセス制御を行う技術は、甲第７号証の３に示されているように、技術常識であるといえる。
　加えて、甲第７号証の３には、ユーザが作成したデータを保存するための「Documents」ディレクトリには、ユーザがアクセスできることが示されており、利用者がアクセスできる（例えば、削除できる）ように制御することも、技術常識であるといえる。
　そうすると、本件の発明の詳細な説明における、「秘匿領域Ｘは、例えばアプリケーション領域などである。」との記載（【００２８】）は、本件の原出願の出願時における技術常識を考慮すれば、「利用者がアクセスできない秘匿領域」を実現する具体的な手段に基づく記載であるから、本件発明１〜４は、特許法第３６条第４項第１号の要件に違反するものではない。
　そして、「利用者がアクセスできない秘匿領域」の実現手段は、本件の発明の詳細な説明（【００２８】）に記載されているから、特許法第３６条第６項第１号の要件に違反するものではない。
　また、本件の原出願の出願時における、上述した基本ソフトウェアのファイルシステムに関する技術常識を考慮すれば、「利用者がアクセスできない秘匿領域」の実現手段は十分に開示されているといえ、当業者は、本件発明１〜４における「利用者がアクセスできない秘匿領域」との発明特定事項を明確に把握することができるから、本件発明１〜４は、特許法第３６条第６項第２号の要件に違反するものではない。
（２）取消理由１−２について
　異議申立人は、本件発明は「発信者情報表示装置」であるが、表示装置（表示手段）を必須の構成として含まず、発信者を特定する装置や手段を必須の構成として含まないから、本件発明１は明確でない旨を主張している。
　しかしながら、「発信者情報表示装置」は、「表示装置」の一種に他ならないから、「発信者情報表示装置」が表示手段を含むことは自明である。
　また、請求項１には、「発信元電話機より電話着信を受ける通信手段」を備えることが記載され、「第１の発信者データ」を「前記電話着信を受けた場合に前記基本ソフトウェアが検索可能」であることも記載されているから、電話着信に基づいて、発信者を特定することは自明である。
　したがって、当業者は、本件発明１について、「発信者情報表示装置」が「表示手段」を有しており、電話着信に基づいて発信者を特定するものであることを明確に把握することができるから、本件発明１は、特許法第３６条第６項第２号の要件に違反するものではない。
（３）取消理由１−３について
　異議申立人は、本件発明１〜４の「利用者がアクセスできない秘匿領域」について、本件特許明細書には、利用者が登録、削除、閲覧、編集などのアクセスを行うことができない領域であると説明され（【００１７】，【００２３】，【００３４】参照）、本件発明１および３によれば、利用者は、「秘匿領域」に格納・登録された電話番号及び名称情報をたとえば「閲覧」する（見る）ことができないものであることを指摘した上で、利用者が「閲覧」できないはずの秘匿領域に登録されるアドレスデータ中の名称情報は、本件特許明細書では、内部電話帳Ｙ１に着信電話番号を含むアドレスデータが登録されておらず、しかしながら発信者情報データＸ３に登録されていることを条件（以下、「所定の条件」という。）にして表示され、利用者が見る（閲覧する）（アクセスする）ことができると説明されているから、本件発明１〜４の内容と本件特許明細書の記載は明らかに矛盾している旨を主張している。
　要するに、異議申立人は、本件発明１〜４の「利用者がアクセスできない秘匿領域」について、明細書では、利用者が閲覧などのアクセスを行うことができない領域であると説明されているのにも関わらず、本件発明１および３によれば、所定の条件が満足されれば利用者が秘匿領域に登録される名称情報を閲覧することができるから、矛盾している旨を主張している。
　ここで、本件明細書の【００２８】には、秘匿領域とは、「利用者Ｕがアクセスすることができない領域」であると記載されており、【００３４】には、発信者情報データＸ３は秘匿領域Ｘに格納されているため、利用者Ｕは発信者情報データＸ３に対して登録、削除、閲覧、編集などのアクセスを行うことはできず、発信者情報データＸ３は、利用者Ｕに対し秘匿された電話帳であることが記載されている。
　また、本件明細書の【００２３】及び【００４０】の記載によれば、本件の実施形態は、発信元電話機からの着信時に内部電話帳に加えて当該発信者情報データを検索し、検索により得られた発信者情報をユーザ端末２のディスプレイに表示する、すなわち、発信者情報表示処理を実行するものである。
　発信者情報表示処理について、本件明細書の【０１１４】〜【０１１８】及び図１０には、ユーザ端末２のＯＳ２１が発信者情報表示処理を行い、発信者情報データＸ３内で着信された電話の電話番号と一致する電話番号を含むアドレスデータが見つかった場合は、当該アドレスデータに含まれる表示名が発信者情報として表示されることが記載されている。
　以上によれば、本件発明１〜４における「利用者がアクセスできない秘匿領域」は、利用者が登録、削除、閲覧、編集などのアクセスを行うことができない領域と解される。
　また、請求項１，３には、「発信者情報表示処理」に対応して、電話番号及び名称情報を、秘匿領域に格納されており電話着信を受けた場合に基本ソフトウェアが検索可能であって、かつ利用者がアクセスできない第１の発信者データへ登録することも記載されており、電話着信を受けた場合は（発信者情報を表示するために）基本ソフトウェアが発信者データを検索可能であることも記載されている。
　つまり、本件発明１〜４において、電話着信を受けた場合に、発信者情報を表示するために第１の発信者データにアクセスし、検索を行っているのは基本ソフトウェアであって、これは、利用者が（自らの意志で）第１の発信者データにアクセスして閲覧することを意味するものでもない。
　そうすると、本件発明１〜４は、利用者が第１の発信者データに登録、削除、閲覧、編集などのアクセスを行うことができないようにしつつ、電話着信を受けた場合は、発信者情報を表示するために、基本ソフトウェアが第１の発信者データを検索可能なものであるから、「所定の条件」が満足されると、発信者情報（秘匿領域に格納された発信者情報データＸ３内のアドレスデータに含まれる表示名）が表示されるとの発明の詳細な説明の記載と矛盾するものではない。
　次に、「利用者がアクセスできない秘匿」を利用する処理の技術的意義について検討する。本件明細書の【０００４】〜【０００７】の記載によれば、本件発明１〜４が解決しようとする課題は、利用者に対し利便性高くかつ安全に発信者情報を提示することであって、具体的には、着信した際に誰からの電話かを知ることができるようにし、かつ、端末を紛失することで、電話帳の個人情報のみならずビジネスに関する情報まで漏洩してしまうリスクを未然に防ぐことである。
　そうすると、本件発明１〜４は、「電話番号及び名称情報」が登録された「第１の発信者情報データ」を、「電話着信を受けた場合」に「基本ソフトウェアが検索」することで、誰からの電話かを知ることができるようにし、かつ、「第１の発信者情報データ」を「利用者がアクセスできない秘匿領域」に格納することで、情報漏洩してしまうリスクを未然に防ぐためのものであるといえる。
　異議申立人の主張するように、本件特許明細書の実施形態が、電話着信を受けた場合に、発信者情報表示処理を行って、「所定の条件」が満足されると、秘匿領域に格納された発信者情報データＸ３内のアドレスデータに含まれる表示名（名称情報）を表示すると説明されていたとしても、これは、利用者に対し利便性高く発信者情報を提示するために行っているのであって、表示された表示名（名称情報）以外の発信者情報データが漏洩するわけでもない。
　また、発信者情報データＸ３が、利用者が登録、削除、閲覧、編集などのアクセスを行うことができない秘匿領域に格納されていることで、電話着信を受けていない場合には、表示名（名称情報）は表示されないから、電話着信を受けた場合に限り安全に発信者情報を提示できるといえる。
　以上を勘案すると、本件発明１〜４における「利用者がアクセスできない秘匿領域」を利用する処理は、利用者に対し利便性高くかつ安全に発信者情報を提示するとの課題を解決するためのものといえ、その技術的意義は明確である。
　したがって、本件発明１〜４の内容と本件発明の詳細な説明の記載は矛盾するものではなく、「利用者がアクセスできない秘匿領域」を利用する処理の技術的意義も明確であるから、本件発明１〜４は、特許法第３６条第６項第１号ないし第２号の要件に違反するものではない。
（４）小括
　以上のとおり、取消理由１（取消理由１−１〜１−３）によって請求項１〜４に係る特許を取り消すことはできない。
２．　取消理由２について
２−１　甲号証の記載
（１）甲第１号証（甲第１号証の１および甲第１号証の２（甲第１号証の１のうち、４枚目のプログラム記述部分中、印字されていない部分を示すもの））には、以下の記載がある（下線は当審で付加した）。
「Framework
CallKit
Display the system-calling UI for your app's VoIP services, and coordinate your calling services with other apps and the system.
Overview
CallKit lets you integrate your calling services with other call-related apps on the system. CallKit provides the calling interface, and you handle the back-end communication with your VoIP service. For incoming and outgoing calls, CallKit displays the same interfaces as the Phone app, giving your app a more native look and feel. And CallKit responds appropriately to system-level behaviors such as Do Not Disturb.
In addition to handling calls, you can provide a Call Directory app extension to provide caller ID information and a list of blocked numbers associated with your service.」（１枚目）
（当審仮訳：
フレームワーク（Framework）
Callkit
あなたのアプリケーションのVoIPサービスのために、システムコールを行うUIを表示し、
そしてあなたの通話サービスを他のアプリケーションやシステムと連携する
概要（Overview）
CallKitは、あなたの通話サービスを、システム上の他の通話関連アプリケーションと統合させてくれる。CallKitが、通話のインタフェースを提供する
通話の着信や発信があると、CallKitは電話アプリケーションと同じインタフェースを表示し、
通話の処理に加えて、あなたは、あなたのサービスに関連して、発信者ID情報と着信拒否番号のリストを与えるためのCall Directory app extensionを提供することができる。
「Call Blocking and Identification
Apps can create a Call Directory app extension to identify and block incoming callers by their phone number.」（３枚目）
（当審仮訳：
着信拒否と識別（Call Blocking and Identification）
アプリケーションは、電話番号によって着信した発信者を特定して、拒否するためにCall Directory app extensionを作成することができる。
「Identifying Incoming Callers
When a phone receives an incoming call, the system first consults the user’s contacts to find a matching phone number. If no match is found, the system then consults your app’s Call Directory extension to find a matching entry to identify the phone number. This is useful for applications that maintain a contact list for a user that’s separate from the system contacts, such as a social network, or for identifying incoming calls that may be initiated from within the app, such as for customer service support or a delivery notification.
For example, consider a user who is friends with Jane in a social networking app, but who doesn’t have her phone number in their contacts. The social networking app has a Call Directory app extension, which downloads and adds the phone numbers of all of the user’s friends. Because of this, when the user gets an incoming call from Jane, the system displays something like “(App Name) Caller ID: Jane Appleseed” rather than “Unknown Caller”.」（４枚目）
（当審仮訳：
発信者の特定
電話機が着信を受けると、システムは、一致する電話番号を見つけるために、まずユーザの連絡先を調べ、一致するものがなければ、システムはあなたのアプリケーションのCall Directory extensionを調べて一致するエントリを見つける。これは、ソーシャルネットワーク
のアプリケーションにおいて開始され得る着信を特定するような、システムの連絡先とは分離された、ユーザのための連絡先のリストを保持するアプリケーションに有用である。
例えば、ソーシャルネットワークアプリケーションのJaneと友人であるが、彼女の電話番号が連絡先にないユーザを想定する。
ソーシャルネットワークアプリケーションは、Call Directory app extensionを持っており、Call Directory app extensionによりユーザの友人の全ての電話番号をダウンロードして追加する。これにより、ユーザがJaneから着信を受けたとき、システムは「発信者不明」ではなく「（アプリケーション名）発信者ID：Jane Appleseed」のように表示を行う。
　したがって、甲第１号証には、
「通話サービスをシステム上の他の通話関連アプリケーションと連携・統合させ、通話のインタフェースを提供するものであり、
　通話の着信や発信があると、電話アプリケーションと同じインタフェースを表示し、
　通話の処理に加えて、あなたのサービスに関連して、発信者ID情報を与えるためのCall Directory app extensionを提供することができ、
　アプリケーションは、電話番号によって着信した発信者を特定するためにCall Directory app extensionを作成することができ、
　発信者の特定にあたって、電話機が着信を受けると、システムは、一致する電話番号を見つけるために、まずユーザの連絡先を調べ、一致するものがなければ、システムはあなたのアプリケーションのCall Directory extensionを調べて一致するエントリを見つけ、
　これは、ソーシャルネットワークのアプリケーション内から開始され得る着信を特定するような、システムの連絡先とは分離された、ユーザのための連絡先のリストを保持するアプリケーションで有用であり、
　ソーシャルネットワークアプリケーションは、Call Directory app extensionを持っており、Call Directory app extensionによりユーザの友人の全ての電話番号をダウンロードして追加し、
　これにより、ユーザがJaneから着信を受けたとき、システムは『発信者不明』ではなく『（アプリケーション名）発信者ID：Jane Appleseed』のように表示を行う、
　フレームワークであるCallKit」が記載されているといえる。
（２）甲第２号証には、「addIdentificationEntry」について記載されている。
（３）甲第３号証には、「CXCallDirectoryExtensionContext」について記載されている。
（４）甲第４号証には、以下の記載がある（下線は当審で付加した）。
「What are Frameworks?
A framework is a hierarchical directory that encapsulates shared resources, such as a dynamic shared library, nib files, image files, localized strings, header files, and reference documentation in a single package. Multiple applications can use all of these resources simultaneously. The system loads them into memory as needed and shares the one copy of the resource among all applications whenever possible.」（１枚目）
（当審仮訳：
フレームワークとは何か？
フレームワークとは、例えば、ダイナミック共通ライブラリ、nibファイル、イメージファイル、ローカライズされた文字列、ヘッダーファイルおよび参照ドキュメントなどの共有リソースを１つのパッケージとし、カプセル化した階層的なディレクトリである。
システムは必要に応じてそれらのリソースをメモリに読み込むことで、いつでも可能なときに全てのアプリケーション間でリソースの１つのコピーを共有する。
　したがって、甲第４号証には、
「フレームワークとは、例えば、ダイナミック共通ライブラリ、nibファイル、イメージファイル、ローカライズされた文字列、ヘッダーファイルおよび参照ドキュメントなどの共有リソースを１つのパッケージとし、カプセル化した階層的なディレクトリであり、システムは必要に応じてそれらのリソースをメモリに読み込むことで、いつでも可能なときに全てのアプリケーション間でリソースの１つのコピーを共有する」ことが記載されているといえる。
（５）甲第５号証には、以下の記載がある（下線は当審で付加した）。
「Understand How an App Extension Works
An app extension is not an app. It implements a specific, well scoped task that adheres to the policies defined by a particular extension point.
An App Extension’s Life Cycle
Because an app extension is not an app, its life cycle and environment are different. In most cases, an extension launches when a user chooses it from an app’s UI or from a presented activity view controller. An app that a user employs to choose an app extension is called a host app. A host app defines the context provided to the extension and kicks off the extension life cycle when it sends a request in response to a user action. An extension typically terminates soon after it completes the request it received from the host app.
For example, imagine that a user selects some text in an OS X host app, activates the Share button, and chooses an app extension from the sharing list to help them post the text to a social sharing website. The host app responds to the user’s choice by issuing to the extension a request that contains the selected text. A generalized version of this situation is pictured in step 1 of Figure 2-1. 」（１枚目）
（当審仮訳：
App Extensionがどう機能するか理解する
App extensionはアプリではない
App extensionのライフサイクル
App extensionはアプリではないため、そのライフサイクルと環境は異なる。ほとんどの場合、
extensionは、ユーザがアプリのUIまたはアクティブに表示されている表示コントローラから選択したときに起動する。ユーザがApp extensionを選択するために使用するアプリは、ホストアプリと呼ばれる。
extensionは典型的には、ホストアプリから受け取った要求を完了した直後に終了する。
例えば、ユーザがOS Xホストアプリで何らかのテキストを選択し、「共有」ボタンをアクティブにし、共有リストからApp extensionを選択して、そのテキストをソーシャル共有ウェブサイトに投稿できるようにすると考える。ホストアプリは、選択したテキストを含む要求をextensionに発行することで、ユーザの選択に応答する。この状況を一般化したバージョンが図2-1のステップ1に図示されている。」
「In step 2 of Figure 2-1, the system instantiates the app extension identified in the host app’s request and sets up a communication channel between them. The extension displays its view within the context of the host app and then uses the items it received in the host app’s request to perform its task (in this example, the extension receives the selected text).
In step 3 of Figure 2-1, the user performs or cancels the task in the app extension and dismisses it. In response to this action, the extension completes the host app’s request by immediately performing the user’s task or, if necessary, initiating a background process to perform it. The host app tears down the extension’s view and the user returns to their previous context within the host app. When the extension’s task is finished, whether immediately or later, a result may be returned to the host app.
Shortly after the app extension performs its task (or starts a background session to perform it), the system terminates the extension, as shown in step 4.」（１枚目）
（当審仮訳：
図2-1のステップ2で、
システムは
それらの間に通信チャネルを設定する。
図2-1のステップ3では、
ユーザはApp extensionでタスクを実行またはキャンセルしてそれを却下する。このアクションに応答して、extensionはすぐにユーザのタスクを実行するか、
によって、ホストアプリケーションの要求を完了する。
App extensionがそのタスクを実行した
直後に、システムはステップ4に示すようにextensionを終了する。
　したがって、甲第５号証には、
「App extensionとは、アプリケーションではなく、ユーザがアプリのUIまたはアクティブに表示されている表示コントローラからApp extensionを選択すると、システムがApp extensionを起動し、ユーザがApp extensionを選択するために使用するアプリであるホストアプリとApp extensnionとの間に通信チャネルを設定し、典型的には、ユーザのタスクを実行して、ホストアプリから受けた要求を完了すると、直後に終了するもの」であることが記載されているといえる。
（６）甲第６号証には、以下の記載がある（下線は当審で付加した）。
「
iOSのセキュリティ
　iOS 10
　2017年3月」（表紙）
「Appのセキュリティ
Appは現代のモバイル・セキュリティ・アーキテクチャにおいて最も重要な要素の１つです。App は生産性においてすばらしいメリットをもたらす一方で、適切に扱わないと、システムのセキュリティ、安定性、およびユーザデータに悪影響を及ぼす可能性があります。
このため、iOS には複数の保護レイヤーを構築し、App が署名され、検証され、サンドボックス化されていることを保証することでユーザデータを保護しています。これらの要素によって安定した安全な App プラットフォームが提供されているので、
何千人ものデベロッパによる数十万もの App を、システムの完全性を損なうことなく iOS に配信することが可能になっています。
「ランタイムプロセスのセキュリティ
App が承認済みのソースからのものであることが確認されると、ほかの App やシステムのほかの部分の危殆化を防止するための iOS のセキュリティ対策が強制的に適用されます。
すべての他社製 App は「サンドボックス化」されるので、ほかの App によって保存されたファイルにアクセスしたり、デバイスに変更を加えたりすることはできません。これにより、ほかの Appによって保存された情報が収集または変更されるのを防ぐことができます。
他社製 App が自身の情報以外の情報にアクセスする必要がある場合は、iOS によって明示的に提供されるサービスを使用したときのみアクセスできます。
　したがって、甲第６号証（p.20）には、
「多数のAppを、システムの完全性を損なうことなく、iOSに配信することが可能になって」いることが記載されているといえる。
　そして、「iOS10のセキュリティについて、すべての他社製 App は「サンドボックス化」されるので、ほかの App によって保存されたファイルにアクセスしたり、デバイスに変更を加えたりすることはできず、これにより、ほかの Appによって保存された情報が収集または変更されるのを防ぐことができ」ることが記載されているといえる。
　また、「他社製 App が自身の情報以外の情報にアクセスする必要がある場合は、iOS によって明示的に提供されるサービスを使用したときのみアクセスでき」ることが記載されているといえる。
（７）甲第７の１号証には、iOSアプリで共通に利用されるディレクトリとして、Libraryサブディレクトリについて記載がある。
（８）甲第７の２号証の記載によれば、「File System Programming Guide」について、「ファイル、ディレクトリ、システムにおける他のコンテンツをどのように生成し、管理するかを記述した新しい文書が２０１１年６月６日に存在したこと」が認められる。
（９）甲第７の３号証には、以下の記載がある（下線は当審で付加した）。
「
iOSアプリのファイル保存について
「はじめに
iOSアプリのファイル保存が可能なディレクトリ
iOS App
　　├── 
Documents
　　├── 
Library
　　│　 ├── Caches
　　│　 └── Preferences
　　└── 
tmp
」（１枚目）
「
Library
これは、ユーザのデータファイル以外のファイル用の最上位ディレクトリです。通常、標準的なサブディレクトリを用意し、いずれか適当な場所に保存します。iOSアプリケーションは通常、Application SupportおよびCachesというサブディレクトリを使いますが、独自のサブディレクトリを作成しても構いません。
ユーザに見せたくないファイルはLibraryサブディレクトリ以下に置いてください。ユーザデータのファイル保存用に使ってはなりません。
Libraryディレクトリの内容は、Cachesサブディレクトリ以下を除き、iTunesによるバックアップの対象になります。」（１枚目）
　したがって、甲第７の３号証には、
「iOSアプリのファイル保存について、ファイル保存が可能なディレクトリとして、Documents、Library、tmp等があり、ユーザに見せたくないファイルはLibraryサブディレクトリ以下に置くべきであり、Libraryはユーザデータのファイル保存用に使ってはならない」ことが記載されているといえる。
（１０）甲第８号証には、写真及び図面とともに、iPhone 7について以下の記載がある（下線は当審で付加した）。
「
容量
２
32GB
　　　　
128GB
　　　　
256GB
「
」（２枚目）
「
」（２枚目）
「
」（４枚目）
「
」（７枚目）
「
」（７枚目）
　甲第８号証の１枚目及び７枚目の記載によれば、iPhone7は、32GB，128GBまたは256GBのいずれかの容量を有する記憶手段と、オペレーティングシステムiOS10及び内蔵アプリケーションを有している。そして、オペレーティングシステムiOS10及び内蔵アプリケーションが記憶手段の所定の領域に記憶されていることは自明である。
　甲第８号証の記載によれば、iPhone7は携帯電話／ワイヤレス通信の機能、内蔵アプリケーションとしての電話アプリケーションを備えており、携帯電話として機能するから、発信元電話機より電話着信を受ける通信手段を備えているといえる。
　また、iPhone7において、チップA10が、オペレーティングシステムiOS10によって制御され、オペレーティングシステムiOS10上で内蔵アプリケーションを実行することは明らかである。
　したがって、甲第８号証には、
「オペレーティングシステムiOS10によって制御されるとともに、前記オペレーティングシステムiOS10上で動作する内蔵アプリケーションを実行するチップ（A10）と、
　前記オペレーティングシステムiOS10と内蔵アプリケーションとを記憶する領域を含む記憶手段（32GB，128GBまたは256GBの容量の記憶装置）と、
　発信元電話機より電話着信を受ける通信手段と、
　ディスプレイと、
　を備えるiPhone 7。」が記載されているといえる。
（１１）甲第９号証には、以下の記載がある（下線は当審で付加した）。
「UPDATE
September 13, 2016
What’s new in iOS 10」（１枚目）
（当審仮訳：
アップデート
２０１６年９月１３日
iOS 10の新着情報）
「The Biggest iOS Release Ever is Available Today
The biggest iOS release ever is available today as a free update for iPhone and iPad. iOS 10 is a massive release for Messages, brings new ways to use Siri with your favorite apps and introduces Memories in Photos, an exciting way to help you rediscover favorite and forgotten occasions from your photo library.」（１枚目）
（当審仮訳：
これまでで最大のiOSリリースが本日利用可能になりました
iPhoneとiPad向けの無料のアップデートとして、これまでで最大のiOSリリースが本日利用可能になりました。
　したがって、甲第９号証には、「iOS 10のリリース日は２０１６年９月１３日（平成２８年９月１３日）」であること、そして、「iOS 10はiPhoneとiPadで利用可能」であることが記載されているといえる。
（１２）甲第１０号証には、以下の記載がある（下線は当審で付加した）。
「iOS 10.0
This article summarizes the key developer-related features introduced in iOS 10, which runs on currently shipping iOS devices. The article also lists the documents that describe new features in more detail.」（１枚目）
（当審仮訳：
iOS 10.0
この記事は、
iOS 10で導入される主要な開発者関連の特徴
「CallKit
The CallKit framework (CallKit.framework) lets VoIP apps integrate with the iPhone UI and give users a great experience. Use this framework to let users view and answer incoming VoIP calls on the lock screen and manage contacts from VoIP calls in the Phone app’s Favorites and Recents views.
CallKit also introduces app extensions that enable call blocking and caller identification. You can create an app extension that can associate a phone number with a name or tell the system when a number should be blocked.」（６枚目）
（当審仮訳：
CallKit
CallKitフレームワーク（CallKit.framework）は、VoIPアプリをiPhoneのUIと統合させ、
ユーザにロックスクリーン上で、着信したVoIPコールを閲覧し応答させ、電話アプリのFavorites（よく使う項目）およびRecent views（履歴）でVoIPコールからの連絡先を管理させることができる。
CallKitは、app extensionを導入し、それにより着信拒否や発信者識別を可能とする。あなたは、電話番号を名前と関連づけたり、システムに電話番号がブロックされるべきときを伝えたりするためにapp extensionを生成することができる。
　したがって、甲１０号証には、「iOS10で導入される主要な開発者関連の特徴として、CallKitが導入され、CallKitフレームワークはVoIPアプリをiPhoneのUIと統合させ、ユーザにロックスクリーン上で、着信したVoIPコールを閲覧し応答させ、電話アプリのFavorites（よく使う項目）およびRecent views（履歴）でVoIPコールからの連絡先を管理させる」ことが記載されているといえる。
　また、「CallKitは、app extensionを導入し、それにより着信拒否や発信者識別を可能とし、電話番号を名前と関連づけたり、システムに電話番号がブロックされるべきときを伝えたりするためにapp extensionを生成することができる。」ことが記載されているといえる。
（１３）甲第１１号証には、Appleセキュリティアップデートについて、以下の記載がある（下線は当審で付加した）。
「
iOS 10
iPhone 5 以降
2016-09-13
　したがって、甲１１号証には、「iOS 10は、２０１６年９月１３日（平成２８年９月１３日）にリリースされ、iPhone5以降を対象としたものである。」ことが記載されているといえる。
２−２　甲号証から把握される公知技術
（１）オペレーティングシステムである「iOS 10」について記載されている甲第８号証は、２０１６年９月７日（平成２８年９月７日）に掲載されたものであり、甲第１０号証は、２０１７年６月６日（平成２９年６月６日）に更新されたものである。
　したがって、２−１（１０），（１２）で述べた甲第８号証及び甲第１０号証の記載事実は、原出願の出願日前に公知である。
　甲第９号証は、２０１６年９月１３日（平成２８年９月１３日）に更新されたものであるから、２−１（１１）で述べた甲第９号証の記載事実は、原出願の出願日前に公知である。
　ここで、甲第８号証及び甲第１０号証には、「iOS 10」のリリース日について記載されていないものの、甲第９号証の記載によれば、２−１（１１）のとおり、「iOS 10」は２０１６年９月１３日に利用可能なオペレーティングシステムとしてリリースされているから、「iOS10」は、甲第８号証及び甲第１０号証に記載された特徴のみならず、実際に利用可能なオペレーティングシステムとして原出願の出願日より前に公知である。
　なお、甲第１１号証は、２０１９年２月１３日（平成３１年２月１３日）に公開されたものであり、原出願の出願日前に公知ではないものの、２−１（１３）で述べたように、甲第９号証と同様に「iOS 10」のリリース日が２０１６年９月１３日（平成２８年９月１３日）であることが記載されている。
　そうすると、
「CallKit、すなわち、発信者識別を可能とするapp extensionが導入可能なフレームワーク、を導入する、オペレーティングシステムiOS10によって制御されるとともに、前記オペレーティングシステム上で動作する内蔵アプリケーションを実行するチップ（A10）と、
　前記オペレーティングシステムiOS10と内蔵アプリケーションとを記憶する領域を含む記憶手段（32GB，128GBまたは256GBの容量の記憶装置）と、
　発信元電話機より電話着信を受ける通信手段と、
　ディスプレイと、
　を備えるiPhone 7。」は公知技術である。
（２）甲第１号証は、２０１７年７月１４日（平成２９年７月１４日）に掲載されたものであるから、２−１（１）で述べた甲第１号証の記載事実は、原出願の出願日前に公知である。
　甲第１号証には、２−１（１）のとおり、「フレームワークであるCallKit」について記載されているものの、「CallKit」がどのようなハードウェア環境・ソフトウェア環境で動作するのかについて明記されていない。
　ここで、甲第９号証の記載によれば、iOS 10はiPhoneで利用可能であり、甲第１０号証の記載によれば、CallKitはiOS10で導入されたものである。また、甲第１１号証の記載によれば、iOS 10は、iPhone5以降を対象としたものであり、これはiPhone5以降のiPhoneであるiPhone7がオペレーティングシステムiOS10を有するとの甲第８号証の記載とも整合する。
　甲第１号証及び甲第１０号証は、同じアップル社のウェブページ（apple.com）で掲載されたものであり、甲第１号証に記載された「CallKit」と、甲第１０号証に記載された「CallKit」は、同じフレームワークを示しているといえる。
　そうすると、甲第１号証に記載された「CallKit」は、iOS 10がインストールされたiPhone5以降で利用可能といえる。
次に、甲第４号証は、２０１３年９月１７日（平成２５年９月１７日）に更新されたものであり、甲第５号証は、２０１７年１０月１９日（平成２９年１０月１９日）に更新されたものであるから、２−１（４），（５）で述べた甲第４，５号証の記載事実は、原出願の出願日前に公知である。
　甲第１号証及び甲第４，５，１０号証は、全て同じアップル社のウェブページ（apple.com）で掲載されたものであるから、甲第１号証に記載された「Framework」と、甲第４号証に記載された「Framework」は同じものを示しており、甲第１号証、甲第５号証及び甲第１０号証のそれぞれに記載された「app extension」は、同じものを示しているといえる。
　甲第４号証の記載によれば、２−１（４）のとおり、フレームワークとは、システムがメモリに読み込むことで、いつでも可能なときに全てのアプリケーション間で共有するものである。しかしながら、甲第４号証は一般的なフレームワーク（Framework）に関して記載したものであり、電話着信を受けた場合の発信者情報の表示について記載したものではない。
　甲第５号証の記載によれば、２−１（５）のとおり、「App extensionとは、システムにより起動され、ユーザがApp extensionを選択するために使用するアプリであるホストアプリとApp extensnionとの間に通信チャネルを設定し、典型的には、ユーザのタスクを実行して、ホストアプリから受けた要求を完了する」ものである。しかしながら、甲第５号証は一般的なApp extensionに関して記載したものであり、電話着信を受けた場合の発信者情報の表示について記載したものではない。
　なお、「CallKit」に関連して、２−１（２），（３）のとおり、甲第２号証には、「addIdentificationEntry」について、甲第３号証には、「CXCallDirectoryExtensionContext」についてそれぞれ記載されているものの、その作成日や更新日の記載はないから、甲第２号証及び甲第３号証の記載事実が原出願の出願日前に公知であるとはいえない。
　したがって、甲第１号証及び甲第１０号証によれば、「CallKit」とは、
「iOS 10で導入されたフレームワークであり、
　発信者ID情報を与えるためのCall Directory app extensionを提供することができ、Call Directory app extensionを導入することにより発信者識別を可能とし、
　アプリケーションが、電話番号によって着信した発信者を特定するために、Call Directory app extensionを作成することができ、
　また、電話番号を名前と関連づけるために、Call Directory app extensionを作成することができる、
フレームワーク」であり、公知技術である。
　そして、「CallKitフレームワークを用いたソーシャルネットワークアプリケーション」が、
「電話番号によって着信した発信者を特定するために、Call Directory app extensionを用いて、
　ユーザの友人の全ての電話番号をダウンロードして追加し、
　発信者の特定にあたって、電話機が着信を受けると、システムは、一致する電話番号を見つけるために、まずユーザの連絡先を調べ、一致するものがなければ、システムはあなたのアプリケーションのCall Directory extensionを調べて一致するエントリを見つけ、
　発信者情報（例えば、発信者ID：Jane Appleseed）の表示を行うソーシャルネットワークアプリケーション。」であることも公知技術である。
　また、甲第１号証及び甲第８〜１１号証によれば、上記の「ソーシャルネットワークアプリケーション」は、iOS 10が動作するiPhone7で利用可能であることが公知である。
（３）甲第６号証は、２０１７年３月（平成２９年３月）に作成されたものであるから、２−１（６）で述べた甲第６号証の記載事実は、原出願の出願日前に公知である。
　しかし、甲第６号証の記載は、２−１（６）のとおり、ほかのAppによって保存されたファイルへの他社製Appのアクセス制限に関するものであるが、Appによって保存されたファイルへの利用者のアクセス制限、すなわち、「利用者がアクセスできない」領域やデータに関するものではない。
　次に、甲第７の３号証は、２０１６年８月１９日（平成２８年８月１９日）に投稿（掲載）されたものであるから、２−１（９）で述べた甲第７の３号証の記載事実は、原出願の出願日前に公知である。
　甲第７の３号証の記載によれば、２−１（９）のとおり、「iOSアプリのファイル保存について、ファイル保存が可能なディレクトリとして、Documents、Library、tmp等があり、ユーザに見せたくないファイルはLibraryサブディレクトリ以下に置くべきであり、Libraryはユーザデータのファイル保存用に使ってはならない」ことが公知である。甲第７の３号証には、iOSのバージョンについて記載されていないものの、その更新日が２０１６年８月１９日であり、iOS 10のリリース日である２０１６年９月１３日より前であるから、iOS 10よりも以前のバージョンのiOSで既にLibraryサブディレクトリがファイル保存可能なディレクトリとして公知であったといえる。
　甲第７の１号証には、「Updated: 2018-04-09」と記載されており、その更新日は平成３０年４月９日であるが、当該更新日は原出願の出願日より後であり、当該更新日の記載からは、甲第７の１号証の記載事実が原出願の出願日前に公知であるとはいえない。
　異議申立人は甲第７の１号証の作成日を立証するための証拠として、甲第７の２号証を示している。ここで、甲第７の２号証には、その更新日が２０１８年４月９日（平成３０年４月９日）であることが記載されていることから、甲第７の２号証は原出願の出願日前に公知ではない。
　甲第７の２号証によれば、２−１（８）のとおり、「File System Programming Guide」について、「ファイル、ディレクトリ、システムにおける他のコンテンツをどのように生成し、管理するかを記述した新しい文書が２０１１年６月６日に存在したこと」が事実として認められるが、当該新しい文書の内容について記載がなく、当該新しい文書の内容が甲第７の１号証と同じであるか否か不明であるから、甲第７の２号証の記載を参酌しても、甲第７の１号証の記載事実が原出願の出願日より前に公知であるとはいえない。
　なお、甲第７の１号証の３枚目には、iOSのファイルシステムに関連して、iOSアプリで共通に利用されるディレクトリとして、Libraryサブディレクトリを、ユーザに見せたくないファイルに使用するとの記載があり、その記載内容については、甲第７の３号証と整合している。
　したがって、甲第７の３号証によれば、iOS10におけるアプリについて、
「iOSアプリは、Documents、Library、tmp等のディレクトリをファイル保存に利用可能であり、ユーザに見せたくないファイルは、Libraryサブディレクトリ以下に置くべき」ことは公知技術である。
（４）スマートフォンのＯＳ上でミドルウェア（フレームワーク）を用いてアプリケーションが動作することは技術常識であるから、（１）〜（３）に記載された公知技術により、（１）に記載の「iPhone7」のiOS10上で、（２）に記載の「CallKit」及び「ソーシャルネットワークアプリケーション」を動作させ、該ソフトウェアが（３）に記載の「iOS10におけるアプリ」のファイルアクセスを用いること、つまり、
「オペレーティングシステム（iOS10）によって制御されるとともに、前記オペレーティングシステム上で動作する内蔵アプリケーション及びCallKitフレームワークを用いたソーシャルネットワークアプリケーションを実行するチップ（A10）と、
　前記オペレーティングシステム、前記内蔵アプリケーション及び前記ソーシャルネットワークアプリケーションとを記憶する領域を含む記憶手段と、
　発信元電話機より電話着信を受ける通信手段と、
　ディスプレイと、
　を備え、
　前記ソーシャルネットワークアプリケーションは、
　Documents、Library、tmp等のディレクトリをファイル保存に利用可能であり、ユーザに見せたくないファイルは、Libraryサブディレクトリ以下に置くように設計されており、
　前記ソーシャルネットワークアプリケーションは、さらに、
　電話番号によって着信した発信者を特定するために、CallKitによって導入されるCall Directory app extensionを用いて、ユーザの友人の全ての電話番号をダウンロードして追加し、
　発信者の特定にあたって、電話機であるiPhone7が着信を受けると、前記オペレーティングシステムは、一致する電話番号を見つけるために、まずユーザの連絡先を調べ、一致するものがなければ、システムはソーシャルネットワークアプリケーションのCall Directory extensionを調べて一致するエントリを見つけ、発信者情報（例えば、発信者ID：Jane Appleseed）の表示を行う
　iPhone 7。」は公然知られた発明（以下、「引用発明」という。）である。
２−３　本件発明１〜４の進歩性について
（１）本件発明１と引用発明との対比
（ア）引用発明における「オペレーティングシステム（iOS10）」は、本件発明１における「基本ソフトウェア」に相当する。
（イ）引用発明における「CallKitフレームワークを用いたソーシャルネットワークアプリケーション」は、アプリケーション・プログラムであるから、引用発明における「ソーシャルネットワークアプリケーション」と、本件発明１における「アプリケーション・プログラム」は、「基本ソフトウェア上で動作し、記憶手段の領域に記憶されるアプリケーション・プログラム」である点で共通する。
（ウ）「チップ」とは、一般にＣＰＵの俗称として使用され、ＣＰＵはプロセッサであるから、引用発明における「チップ（A10）」は、本件発明１における「プロセッサ」に相当する。
（エ）引用発明における「記憶手段」は、「オペレーティングシステム」及び「ソーシャルネットワークアプリケーション」を記憶する領域を含む。さらに、「ソーシャルネットワークアプリケーション」は、iOS 10上で動作するiOSアプリであって、ユーザに見せたくないファイルを置くべき、Libraryサブディレクトリ以下のディレクトリをファイル保存に利用可能であるから、「記憶手段」は、ユーザがアクセスできない領域を含むといえる。
　ここで、本件発明１における「秘匿領域」とは、本件明細書の【００２８】の記載によれば、「利用者Ｕがアクセスすることができない領域」であるから、引用発明における「記憶手段」に含まれるユーザがアクセスできない領域は「秘匿領域」といえる。
　したがって、引用発明における「記憶手段」と、本件発明１における「記憶手段」とは、「基本ソフトウェアとアプリケーション・プログラムとを記憶する領域と、利用者がアクセスできない秘匿領域を含む」点で一致する。
（オ）引用発明における「発信元電話機より電話着信を受ける通信手段」は、本件発明１における「発信元電話機より電話着信を受ける通信手段」に相当する。
（カ）引用発明における「Call Directory app extension」は、電話番号によって着信した発信者を特定するためのものであるから、「Call Directory app extension」に電話番号と発信者情報（すなわち、発信者の名称情報）の対応関係（エントリ）がデータとして記憶されることは明らかである。
　したがって、Call Directory app extensionを用いて、ユーザの友人の全ての電話番号をダウンロードして追加することで、電話番号及び発信者の名称情報（例えば、発信者ID：Jane Appleseed）を含むデータが記憶手段に格納されるといえる。
　また、引用発明における「Call Directory app extension」は、電話機であるiPhone7が着信を受けると、オペレーティングシステム（iOS10）が、「Call Directory app extension」を調べて電話番号に一致するエントリを見つけるものであるから、電話番号及び発信者の名称情報を、電話着信を受けた場合にオペレーティングシステムが検索可能であるといえる。
　そして、アプリケーション・プログラムが、プロセッサにより処理されることで、所定の機能を発揮することは技術常識である。
　そうすると、引用発明における「ソーシャルネットワークアプリケーション」と、本件発明１における「アプリケーション・プログラム」は、「プロセッサ」を「電話番号と当該電話番号に対応する名称情報とを含むデータを格納する手段」として機能させ、「電話番号及び発信者の名称情報を、電話着信を受けた場合に基本ソフトウェアが検索可能」であるように機能させる「アプリケーション・プログラム」である点で共通する。
（キ）引用発明における「iPhone7」は、表示装置である「ディスプレイ」を備え、発信者情報（例えば、発信者ID：Jane Appleseed）の表示を行うから、引用発明における「ディスプレイを備え、発信者情報の表示を行うiPhone7」は、「発信者情報表示装置」であるといえる。
　上記（ア）〜（カ）より、本件発明１と引用発明との一致点は、次のとおりである。
【一致点】
「基本ソフトウェアによって制御されるとともに、前記基本ソフトウェア上で動作するアプリケーション・プログラムを実行するプロセッサと、
　基本ソフトウェアと前記アプリケーション・プログラムとを記憶する領域と、利用者がアクセスできない秘匿領域を含む記憶手段と、
　発信元電話機より電話着信を受ける通信手段と、
を備え、
　前記アプリケーション・プログラムは、前記プロセッサを
　電話番号と当該電話番号に対応する名称情報とを含むデータを格納する手段として機能させ、
　前記データに含まれる電話番号及び発信者の名称情報を、電話着信を受けた場合に基本ソフトウェアが検索可能であるように機能させる
発信者情報表示装置。」
　一方で、本件発明１と引用発明とは、以下の点で相違する。
【相違点１】
　「電話番号と当該電話番号に対応する名称情報とを含むデータを格納する手段」について、本件発明１では、「アプリケーション・プログラム」は、「プロセッサ」を「電話番号と当該電話番号に対応する名称情報とを含むデータを前記秘匿領域に格納する手段」として機能させるのに対し、引用発明では、「ソーシャルネットワークアプリケーション」は、「チップ」を「電話番号によって着信した発信者を特定するために、Call Directory app extensionを用いて、ユーザの友人の全ての電話番号をダウンロードして追加」するように機能させるものの、「Call Directory app extension」に記憶される電話番号と発信者情報が「秘匿領域」に格納されるか不明である点。
【相違点２】
　「前記データに含まれる電話番号及び名称情報を、電話着信を受けた場合に基本ソフトウェアが検索可能」とする点について、本件発明１では、「アプリケーション・プログラム」は、「プロセッサ」を「前記データに含まれる電話番号及び名称情報を、前記秘匿領域に格納されており前記電話着信を受けた場合に前記基本ソフトウェアが検索可能であって、かつ利用者がアクセスできない第１の発信者データへ登録する手段」として機能させるのに対して、引用発明では、「ソーシャルネットワークアプリケーション」は、「チップ」を「Call Directory app extension」に記憶された電話番号と発信者情報を、「秘匿領域」に格納されており「利用者がアクセスできない発信者データ」へ登録する手段として機能させるか不明である点。
（２）本件発明１の進歩性についての判断
　（１）で挙げた【相違点１】について検討する。
　本件発明１における「秘匿領域」とは、２−３（エ）で述べたように、「利用者Ｕがアクセスすることができない領域」である。
　また、本件明細書の【０００４】の記載によれば、本件発明が解決しようとする課題の一つは、携帯端末を紛失すると、電話帳（アドレス帳）から、個人情報のみならずビジネスに関する情報まで漏洩してしまうリスクを未然に防ぐことであるから、本件発明１における「秘匿領域」は、携帯端末を紛失することで、他の利用者に当該携帯端末が利用され、電話帳（アドレス帳）から情報漏洩してしまうリスクを防ぐために設けられていると考えられる。
　これに対し、引用発明の「記憶手段」は、「利用者がアクセスできない秘匿領域を含む」ものであり、また、甲第７の３号証には、「iOSアプリは、Documents、Library、tmp等のディレクトリをファイル保存に利用可能であり、ユーザに見せたくないファイルは、Libraryサブディレクトリ以下に置くべき」ことが記載されている。
　しかしながら、甲第７の３号証、あるいは、甲第１号証、甲第４〜６号証及び甲第８〜１１号証のいずれにも、「Call Directory app extension」あるいはユーザの友人の電話番号と発信者情報がユーザに見せたくないファイルであることは記載されていないから、当業者が「Call Directory app extension」をLibraryサブディレクトリ以下に作成・保存する動機付けが生じるとはいえない。
　したがって、甲第１号証、甲第４〜６号証、甲第７の３号証及び甲第８〜１１号証には、「アプリケーション・プログラム」は、「プロセッサ」を「電話番号と当該電話番号に対応する名称情報とを含むデータ」を利用者がアクセスすることができない領域である「秘匿領域に格納する手段」として機能させる点について記載されていない。
　以上より、「アプリケーション・プログラム」が、「プロセッサ」を「電話番号と当該電話番号に対応する名称情報とを含むデータ」を利用者がアクセスすることができない領域である「秘匿領域に格納する手段」として機能させる点は、甲第１号証、甲第４〜６号証、甲第７の３号証及び甲第８〜１１号証に基づいて当業者が容易になし得るものではない。
　次に、（１）で挙げた【相違点２】について検討する。
　本件発明１における「第１の発信者情報データ」とは、実施形態の「発信者情報データＸ３」に対応するものである。
　本件明細書の【００３４】の記載によれば、「発信者情報データＸ３」は、「発信者の表示名及び電話番号などを含むアドレスデータ」であり、秘匿領域に格納されているため、利用者は「登録、削除、閲覧、編集などのアクセスを行うこと」はできず、利用者に対し「秘匿された電話帳」である（なお、本件明細書の【００４７】の記載によれば、「第１の発信者情報データ」（発信者情報データＸ３）の削除は可能としてもよい）。
　しかし、甲第１号証、甲第４〜６号証、甲第７の３号証及び甲第８〜１１号証には、アプリケーション・プログラムが、チップをCall Directory app extensionによりダウンロードされた電話番号及び発信者情報を、発信者データとして登録する手段として機能させる点について記載されていない。
　仮に、当業者が、Call Directory app extensionによりダウンロードされた電話番号及び発信者情報を、発信者データとして登録することを容易になし得るとしても、当該発信者データを利用者がアクセスできない「秘匿領域」に格納する点について、甲第１号証、甲第４〜６号証、甲第７の３号証及び甲第８〜１１号証には、記載されていないから、【相違点１】において述べたとおり、当業者が「Call Directory app extension」をLibraryサブディレクトリ以下に作成・保存する動機付けが生じるとはいえない。
　以上より、「アプリケーション・プログラム」が、「プロセッサ」を「前記データに含まれる電話番号及び名称情報を、前記秘匿領域に格納されており前記電話着信を受けた場合に前記基本ソフトウェアが検索可能であって、かつ利用者がアクセスできない第１の発信者データへ登録する手段」として機能させる点は、甲第１号証、甲第４〜６号証、甲第７の３号証及び甲第８〜１１号証に基づいて当業者が容易になし得るものではない。
　よって、本件発明１と引用発明は相違点１ないし２の点で相違し、相違点１ないし２の点は、甲第１〜１１号証に基づいて当業者が容易になし得るものではない。
（３）異議申立人の主張について
　異議申立人は、「Call Directory app extension」はサンドボックス（sandbox）によって保護されることで他のアプリから保護されるので、たとえば、windowsのエクスプローラのようなプログラムを用いて利用者は登録、閲覧、編集、削除をすることはできず、「Call Directory app extension」は「秘匿領域」に相当する旨を主張している。
　また、異議申立人は、甲第３号証には、CallKitにおいて、識別エントリ（連絡先）の追加（登録）および削除は処理機能として用意されているものの、例えば読出し、編集は処理機能として用意されておらず、CallKitを含むiOS10を搭載したiPhone 7において、CallKitは、ダウンロードされたデータを「Call Directory app extension」に追加（登録）すること、および削除することしか認められていないから、「Call Directory app extension」は「秘匿領域」に相当する旨を主張している。
　しかし、（２）でも述べたように、本件発明１における「秘匿領域」とは、「電話番号と当該電話番号に対応する名称情報とを含むデータを格納する手段」として、プロセッサを機能させる「アプリケーション・プログラム」以外の他社製App（アプリ）から、秘匿される領域を意味しているのではなく、あくまで利用者がアクセスすることができない領域であるから、「Call Directory app extension」は「秘匿領域」に相当するものではない。
　ここで、甲第６号証には、「iOS 10では、すべての他社製 App は、「サンドボックス化」され、ほかの App によって保存されたファイルにアクセスすることはできず、iOS によって明示的に提供されるサービスを使用したときのみ自身の情報以外の情報にアクセスすることができ」ることが記載されているものの、利用者がAppによって保存されたファイルにアクセスすることができないようにする点については記載されていない。
　例えば、利用者が、ファイルを保存したアプリケーション自体や内蔵アプリケーション、あるいは、他社製AppがiOSによって明示的に提供されるサービスを使用したときにも、利用者が保存されたファイルにアクセスできないようにすることについて、甲第６号証に記載されていない。
　次に、甲第３号証には、２−１（３）で述べたように、その作成日や公知日は記載されていないものの、CallKitにおいて、識別エントリ（連絡先）の読出し、編集は処理機能として用意されておらず、CallKitを含むiOS10を搭載したiPhone 7においては、ダウンロードされたデータを「Call Directory app extension」に追加（登録）および削除することしか認められていないとの異議申立人の主張についても一応検討しておく。
　甲第３号証には、CallKitは識別エントリ（連絡先）の読出し、編集を禁止するものであることが記載されているわけではない。
　加えて、甲第１０号証には、むしろCallKitフレームワークにより、VoIPアプリをiPhoneのUIと統合させ、電話アプリのFavorites（よく使う項目）およびRecent views（履歴）でVoIPコールからの連絡先を管理できることが記載されている。
　したがって、甲第３号証に、CallKitにおける、読出し、編集の処理機能についての記載がないことをもって、CallKitは、ダウンロードされたデータを「Call Directory app extension」に追加（登録）すること、および削除することしか認められていないとまではいえない。
（４）本件発明２〜４の進歩性についての判断
　本件発明２〜４は、本件発明１をさらに限定した発明であるから、上記（２），（３）に記載した本件発明１に対する理由と同様の理由により、甲第１号証〜甲第１１号証に基づいて、当業者が容易に発明することができたものではない。
（５）小括
　以上のとおり、取消理由２によって請求項１〜４に係る特許を取り消すことはできない。
第５　むすび
　したがって、特許異議の申立ての取消理由１、取消理由２及び証拠によっては、請求項１〜４に係る特許を取り消すことはできない。
　また、他に請求項１〜４に係る特許を取り消すべき理由を発見しない。
　よって、結論のとおり決定する。
【異議決定日】
令和１年５月２０日（２０１９．５．２０）