• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 全部申し立て 2項進歩性  H04M
審判 全部申し立て 特36条4項詳細な説明の記載不備  H04M
審判 全部申し立て 特36条6項1、2号及び3号 請求の範囲の記載不備  H04M
管理番号 1352318
異議申立番号 異議2019-700120  
総通号数 235 
発行国 日本国特許庁(JP) 
公報種別 特許決定公報 
発行日 2019-07-26 
種別 異議の決定 
異議申立日 2019-02-14 
確定日 2019-05-31 
異議申立件数
事件の表示 特許第6375464号発明「発信者情報表示装置及びプログラム」の特許異議申立事件について、次のとおり決定する。 
結論 特許第6375464号の請求項1ないし4に係る特許を維持する。 
理由 第1 手続の経緯
特許第6375464号の請求項1?4に係る発明についての出願は、平成29年11月30日に出願した特願2017-230417号(以下、「原出願」という。)の一部を、平成30年3月9日に新たな特許出願とした特願2018-43479号に係るものであって、平成30年7月27日にその特許権の設定登録がされ、平成30年8月15日に特許公報が発行された。その後、その特許に対し、平成31年2月14日に特許異議申立人澤木紀一(以下、「異議申立人」という。)より、全請求項に対して特許異議の申立てがなされた。

第2 本件発明
特許第6375464号の請求項1?4の特許に係る発明は、それぞれ、その特許請求の範囲の請求項1?4に記載された事項により特定される次のとおりのものである。

「【請求項1】
基本ソフトウェアによって制御されるとともに、前記基本ソフトウェア上で動作するアプリケーション・プログラムを実行するプロセッサと、
前記基本ソフトウェアと前記アプリケーション・プログラムとを記憶する領域と、利用者がアクセスできない秘匿領域を含む記憶手段と、
発信元電話機より電話着信を受ける通信手段と、
を備え、
前記アプリケーション・プログラムは、前記プロセッサを
電話番号と当該電話番号に対応する名称情報とを含むデータを前記秘匿領域に格納する手段と、
前記データに含まれる電話番号及び名称情報を、前記秘匿領域に格納されており前記電話着信を受けた場合に前記基本ソフトウェアが検索可能であって、かつ利用者がアクセスできない第1の発信者データへ登録する手段と、
して機能させる
ことを特徴とする発信者情報表示装置。
【請求項2】
前記記憶手段は利用者がアクセス可能な公開領域をさらに含み、前記公開領域には、前記利用者の登録命令に応じて電話番号及び名称情報が登録される第2の発信者データが格納され、
前記発信元電話機より前記電話着信を受けた場合に、前記発信元電話機の発信者電話番号に基づいて前記第2の発信者データを検索し、前記第2の発信者データに前記発信者電話番号が含まれない場合に、前記第1の発信者データを検索する検索手段と、
前記電話着信を受けた場合に発信元に関する情報を表示し、前記第1の発信者データに前記発信者電話番号が含まれる場合に、前記発信者電話番号に対応する名称情報を表示する表示手段と、
をさらに備える
ことを特徴とする請求項1に記載の発信者情報表示装置。
【請求項3】
コンピュータの基本ソフトウェアによって制御されるとともに、前記基本ソフトウェア上で動作するプログラムであって、
前記コンピュータを、
電話番号と当該電話番号に対応する名称情報とを含むデータを、前記コンピュータが備える記憶手段のうち利用者がアクセスできない秘匿領域に格納する格納手段と、
前記データに含まれる電話番号及び名称情報を、前記秘匿領域に格納されており電話着信を受けた場合に前記基本ソフトウェアが検索可能であって、かつ利用者がアクセスできない発信者データへ登録する登録手段と
して機能させるためのプログラム。
【請求項4】
前記格納手段は、前記データを暗号化し、
前記登録手段は、前記暗号化された前記データを復号する
ことを特徴とする請求項3に記載のプログラム。」(以下、請求項1?4に係る発明を、順に「本件発明1?4」といい、総称して「本件発明」という。)

第3 申立理由の概要
異議申立人は、本件の請求項1?4に係る特許は、取消理由1及び取消理由2により、取り消されるべき旨を主張する。

1.取消理由1の概要
異議申立人は、取消理由1として、本件の請求項1?4に係る特許は発明の詳細な説明に記載されておらず、不明確であること(特許法第36条第6項第1号ないし2号)、発明の詳細な説明の記載はいわゆる当業者が実施できる程度に明確かつ十分でないこと(特許法第36条第4項第1号)を主張し、具体的な理由として、以下の(1-1)?(1-3)を主張している。

(1-1)本件発明1?4について、「利用者がアクセスできない秘匿領域」の実現手段が開示されておらず(特許法第36条第6項第1号違反)、不明確であり(特許法第36条第6項第2号違反)、発明の詳細な説明の記載は当業者が「利用者がアクセスできない秘匿領域」を実施できる程度に明確かつ十分でもないこと(第36条第4項第1号違反)(以下、「取消理由1-1」という。)
(1-2)本件発明1は、「発信者情報表示装置」であるにも関わらず、「表示装置」または「表示手段」(さらには発信者特定手段)を備えていないものが含まれること(特許法第36条第6項第2号違反)(以下、「取消理由1-2」という。)
(1-3)本件発明1?4について、「利用者がアクセスできない秘匿領域」およびこれを利用する処理の技術的意義が不明確であること(特許法第36条第6項第1号ないし第2号違反)(以下、「取消理由1-3」という。)

2.取消理由2の概要
異議申立人は、証拠として、甲第1?11号証を提出し、本件発明1?4はCallKitを含むiOS(iOS10)にしたがって動作し、かつCallKitを利用するアプリケーション・プログラムがインストールされたiPhone(iPhone 7)そのものを規定するにすぎないこと(当業者であれば、CallKitを含むiOS(iOS10)に関する知識に基づいて本件発明1?4を容易に想到できたこと)(特許法第29条第2項違反)を主張している。
取消理由2の証拠として提出された、甲第1?11号証は以下のとおりである。

甲第1の1号証:「CallKit | Apple Developer Documentation」インターネットアーカイブに保存されている、2017.7.14時点におけるApple Inc.のウェブページ
甲第1の2号証:「CallKit | Apple Developer Documentation」インターネットアーカイブに保存されている、2017.7.14時点におけるApple Inc.のウェブページ(甲第1の1において、4枚目のプログラム記述部分中、印字されていない部分を印字するもの)
甲第2号証:「addIdentificationEntry(withNextSequentialPhoneNumber:label:)」Apple Inc.のCallKitに関する開発者向け資料のウェブページ
甲第3号証:「CXCallDirectoryExtensionContext」Apple Inc.のCallKitに関する開発者向け資料のウェブページ
甲第4号証:「What are Frameworks?」Apple Inc.のフレームワークを解説するウェブページ
甲第5号証:「App Extension Programming Guide: Understand How an App Extension Works」Apple Inc.のApp Extensionを説明するウェブページ
甲第6号証:「iOSのセキュリティ iOS10」
甲第7の1号証:「File System Programming Guide: File System Basics」Apple Inc.のFile System Basicsを説明するウェブページ
甲第7の2号証:File System Programming Guideのリビジョンヒストリ
甲第7の3号証:iOSアプリのファイル保存について
甲第8号証:「iPhone 7の仕様」インターネットアーカイブに保存されている、2016.9.7時点におけるApple Inc.のウェブページ
甲第9号証:「What’s new in iOS 10 News room」
甲第10号証:「Documentation Archive, What’s New in iOS, iOS 10.0」
甲第11号証:「Appleセキュリティアップデート」

第4 当審の判断
1.取消理由1について
(1)取消理由1-1について
異議申立人は、「利用者がアクセスできない秘匿領域」について、本件特許明細書はその具体的な実現手段を全く説明しておらず、いわば願望を述べるにとどまっており、特に「削除」に関しては、利用者が(発信者情報データX3を削除)「できる」という記載および「できない」という記載がどちらも存在し、「できる」ようにするための具体的構成も、「できない」ようにするための具体的な構成も全く説明していない旨を主張している。
ここで、本件明細書の【0028】には、「秘匿領域Xは、利用者Uがアクセスすることができない領域である。秘匿領域Xは、例えばアプリケーション領域などである。」と記載されている。
一方、異議申立人は、利用者がアクセスすることができない領域及びアクセスできる領域の具体的な実現手段や具体的構成が全く説明されていないと主張する。
しかし、後記2-2(3)に記載されるように2016年8月19日(平成28年8月19日)に掲載された甲第7号証の3の1枚目には、iOSアプリケーションは通常、「Library」ディレクトリに用意した、Application SupportおよびCachesのサブディレクトリを使い、「Libraryサブディレクトリ以下」に置いた、すなわち、保存したファイルについて、ユーザが見ることができないことが記載されている。iOSアプリケーションがファイルを保存する「Libraryサブディレクトリ」は、アプリケーションが使用する領域であるから、「アプリケーション領域」に他ならない。つまり、甲第7号証の3には、「アプリケーション領域」である「Libraryサブディレクトリ」は、ユーザが見ることができない(アクセスできない)ようにファイルを保存する領域、すなわち秘匿領域であることが記載されている。
したがって、「アプリケーション領域」である「Libraryサブディレクトリ」を用いることで、基本ソフトウェア(iOS)のファイルシステムによって、利用者がアクセスできないように記憶領域へのアクセス制御を行う技術は、甲第7号証の3に示されているように、技術常識であるといえる。
加えて、甲第7号証の3には、ユーザが作成したデータを保存するための「Documents」ディレクトリには、ユーザがアクセスできることが示されており、利用者がアクセスできる(例えば、削除できる)ように制御することも、技術常識であるといえる。
そうすると、本件の発明の詳細な説明における、「秘匿領域Xは、例えばアプリケーション領域などである。」との記載(【0028】)は、本件の原出願の出願時における技術常識を考慮すれば、「利用者がアクセスできない秘匿領域」を実現する具体的な手段に基づく記載であるから、本件発明1?4は、特許法第36条第4項第1号の要件に違反するものではない。
そして、「利用者がアクセスできない秘匿領域」の実現手段は、本件の発明の詳細な説明(【0028】)に記載されているから、特許法第36条第6項第1号の要件に違反するものではない。
また、本件の原出願の出願時における、上述した基本ソフトウェアのファイルシステムに関する技術常識を考慮すれば、「利用者がアクセスできない秘匿領域」の実現手段は十分に開示されているといえ、当業者は、本件発明1?4における「利用者がアクセスできない秘匿領域」との発明特定事項を明確に把握することができるから、本件発明1?4は、特許法第36条第6項第2号の要件に違反するものではない。

(2)取消理由1-2について
異議申立人は、本件発明は「発信者情報表示装置」であるが、表示装置(表示手段)を必須の構成として含まず、発信者を特定する装置や手段を必須の構成として含まないから、本件発明1は明確でない旨を主張している。
しかしながら、「発信者情報表示装置」は、「表示装置」の一種に他ならないから、「発信者情報表示装置」が表示手段を含むことは自明である。
また、請求項1には、「発信元電話機より電話着信を受ける通信手段」を備えることが記載され、「第1の発信者データ」を「前記電話着信を受けた場合に前記基本ソフトウェアが検索可能」であることも記載されているから、電話着信に基づいて、発信者を特定することは自明である。
したがって、当業者は、本件発明1について、「発信者情報表示装置」が「表示手段」を有しており、電話着信に基づいて発信者を特定するものであることを明確に把握することができるから、本件発明1は、特許法第36条第6項第2号の要件に違反するものではない。

(3)取消理由1-3について
異議申立人は、本件発明1?4の「利用者がアクセスできない秘匿領域」について、本件特許明細書には、利用者が登録、削除、閲覧、編集などのアクセスを行うことができない領域であると説明され(【0017】,【0023】,【0034】参照)、本件発明1および3によれば、利用者は、「秘匿領域」に格納・登録された電話番号及び名称情報をたとえば「閲覧」する(見る)ことができないものであることを指摘した上で、利用者が「閲覧」できないはずの秘匿領域に登録されるアドレスデータ中の名称情報は、本件特許明細書では、内部電話帳Y1に着信電話番号を含むアドレスデータが登録されておらず、しかしながら発信者情報データX3に登録されていることを条件(以下、「所定の条件」という。)にして表示され、利用者が見る(閲覧する)(アクセスする)ことができると説明されているから、本件発明1?4の内容と本件特許明細書の記載は明らかに矛盾している旨を主張している。
要するに、異議申立人は、本件発明1?4の「利用者がアクセスできない秘匿領域」について、明細書では、利用者が閲覧などのアクセスを行うことができない領域であると説明されているのにも関わらず、本件発明1および3によれば、所定の条件が満足されれば利用者が秘匿領域に登録される名称情報を閲覧することができるから、矛盾している旨を主張している。
ここで、本件明細書の【0028】には、秘匿領域とは、「利用者Uがアクセスすることができない領域」であると記載されており、【0034】には、発信者情報データX3は秘匿領域Xに格納されているため、利用者Uは発信者情報データX3に対して登録、削除、閲覧、編集などのアクセスを行うことはできず、発信者情報データX3は、利用者Uに対し秘匿された電話帳であることが記載されている。
また、本件明細書の【0023】及び【0040】の記載によれば、本件の実施形態は、発信元電話機からの着信時に内部電話帳に加えて当該発信者情報データを検索し、検索により得られた発信者情報をユーザ端末2のディスプレイに表示する、すなわち、発信者情報表示処理を実行するものである。
発信者情報表示処理について、本件明細書の【0114】?【0118】及び図10には、ユーザ端末2のOS21が発信者情報表示処理を行い、発信者情報データX3内で着信された電話の電話番号と一致する電話番号を含むアドレスデータが見つかった場合は、当該アドレスデータに含まれる表示名が発信者情報として表示されることが記載されている。
以上によれば、本件発明1?4における「利用者がアクセスできない秘匿領域」は、利用者が登録、削除、閲覧、編集などのアクセスを行うことができない領域と解される。
また、請求項1,3には、「発信者情報表示処理」に対応して、電話番号及び名称情報を、秘匿領域に格納されており電話着信を受けた場合に基本ソフトウェアが検索可能であって、かつ利用者がアクセスできない第1の発信者データへ登録することも記載されており、電話着信を受けた場合は(発信者情報を表示するために)基本ソフトウェアが発信者データを検索可能であることも記載されている。
つまり、本件発明1?4において、電話着信を受けた場合に、発信者情報を表示するために第1の発信者データにアクセスし、検索を行っているのは基本ソフトウェアであって、これは、利用者が(自らの意志で)第1の発信者データにアクセスして閲覧することを意味するものでもない。
そうすると、本件発明1?4は、利用者が第1の発信者データに登録、削除、閲覧、編集などのアクセスを行うことができないようにしつつ、電話着信を受けた場合は、発信者情報を表示するために、基本ソフトウェアが第1の発信者データを検索可能なものであるから、「所定の条件」が満足されると、発信者情報(秘匿領域に格納された発信者情報データX3内のアドレスデータに含まれる表示名)が表示されるとの発明の詳細な説明の記載と矛盾するものではない。

次に、「利用者がアクセスできない秘匿」を利用する処理の技術的意義について検討する。本件明細書の【0004】?【0007】の記載によれば、本件発明1?4が解決しようとする課題は、利用者に対し利便性高くかつ安全に発信者情報を提示することであって、具体的には、着信した際に誰からの電話かを知ることができるようにし、かつ、端末を紛失することで、電話帳の個人情報のみならずビジネスに関する情報まで漏洩してしまうリスクを未然に防ぐことである。
そうすると、本件発明1?4は、「電話番号及び名称情報」が登録された「第1の発信者情報データ」を、「電話着信を受けた場合」に「基本ソフトウェアが検索」することで、誰からの電話かを知ることができるようにし、かつ、「第1の発信者情報データ」を「利用者がアクセスできない秘匿領域」に格納することで、情報漏洩してしまうリスクを未然に防ぐためのものであるといえる。
異議申立人の主張するように、本件特許明細書の実施形態が、電話着信を受けた場合に、発信者情報表示処理を行って、「所定の条件」が満足されると、秘匿領域に格納された発信者情報データX3内のアドレスデータに含まれる表示名(名称情報)を表示すると説明されていたとしても、これは、利用者に対し利便性高く発信者情報を提示するために行っているのであって、表示された表示名(名称情報)以外の発信者情報データが漏洩するわけでもない。
また、発信者情報データX3が、利用者が登録、削除、閲覧、編集などのアクセスを行うことができない秘匿領域に格納されていることで、電話着信を受けていない場合には、表示名(名称情報)は表示されないから、電話着信を受けた場合に限り安全に発信者情報を提示できるといえる。
以上を勘案すると、本件発明1?4における「利用者がアクセスできない秘匿領域」を利用する処理は、利用者に対し利便性高くかつ安全に発信者情報を提示するとの課題を解決するためのものといえ、その技術的意義は明確である。
したがって、本件発明1?4の内容と本件発明の詳細な説明の記載は矛盾するものではなく、「利用者がアクセスできない秘匿領域」を利用する処理の技術的意義も明確であるから、本件発明1?4は、特許法第36条第6項第1号ないし第2号の要件に違反するものではない。

(4)小括
以上のとおり、取消理由1(取消理由1-1?1-3)によって請求項1?4に係る特許を取り消すことはできない。

2. 取消理由2について
2-1 甲号証の記載
(1)甲第1号証(甲第1号証の1および甲第1号証の2(甲第1号証の1のうち、4枚目のプログラム記述部分中、印字されていない部分を示すもの))には、以下の記載がある(下線は当審で付加した)。
「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.」(1枚目)
(当審仮訳:
フレームワーク(Framework)
Callkit
あなたのアプリケーションのVoIPサービスのために、システムコールを行うUIを表示し、そしてあなたの通話サービスを他のアプリケーションやシステムと連携する。
概要(Overview)
CallKitは、あなたの通話サービスを、システム上の他の通話関連アプリケーションと統合させてくれる。CallKitが、通話のインタフェースを提供することで、あなたのVoIPサービスを用いたバックエンド通信が扱えるようになる。通話の着信や発信があると、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.」(3枚目)
(当審仮訳:
着信拒否と識別(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”.」(4枚目)
(当審仮訳:
発信者の特定(Identifying Incoming Callers)
電話機が着信を受けると、システムは、一致する電話番号を見つけるために、まずユーザの連絡先を調べ、一致するものがなければ、システムはあなたのアプリケーションのCall Directory extensionを調べて一致するエントリを見つける。これは、ソーシャルネットワークや、カスタマーサービスサポートや配達通知などのアプリケーションにおいて開始され得る着信を特定するような、システムの連絡先とは分離された、ユーザのための連絡先のリストを保持するアプリケーションに有用である。
例えば、ソーシャルネットワークアプリケーションのJaneと友人であるが、彼女の電話番号が連絡先にないユーザを想定する。
ソーシャルネットワークアプリケーションは、Call Directory app extensionを持っており、Call Directory app extensionによりユーザの友人の全ての電話番号をダウンロードして追加する。これにより、ユーザがJaneから着信を受けたとき、システムは「発信者不明」ではなく「(アプリケーション名)発信者ID:Jane Appleseed」のように表示を行う。)

したがって、甲第1号証には、
「通話サービスをシステム上の他の通話関連アプリケーションと連携・統合させ、通話のインタフェースを提供するものであり、
通話の着信や発信があると、電話アプリケーションと同じインタフェースを表示し、
通話の処理に加えて、あなたのサービスに関連して、発信者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」が記載されているといえる。

(2)甲第2号証には、「addIdentificationEntry」について記載されている。

(3)甲第3号証には、「CXCallDirectoryExtensionContext」について記載されている。

(4)甲第4号証には、以下の記載がある(下線は当審で付加した)。
「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.」(1枚目)
(当審仮訳:
フレームワークとは何か?
フレームワークとは、例えば、ダイナミック共通ライブラリ、nibファイル、イメージファイル、ローカライズされた文字列、ヘッダーファイルおよび参照ドキュメントなどの共有リソースを1つのパッケージとし、カプセル化した階層的なディレクトリである。多数のアプリケーションは同時にこれらのリソースを利用することができる。システムは必要に応じてそれらのリソースをメモリに読み込むことで、いつでも可能なときに全てのアプリケーション間でリソースの1つのコピーを共有する。)

したがって、甲第4号証には、
「フレームワークとは、例えば、ダイナミック共通ライブラリ、nibファイル、イメージファイル、ローカライズされた文字列、ヘッダーファイルおよび参照ドキュメントなどの共有リソースを1つのパッケージとし、カプセル化した階層的なディレクトリであり、システムは必要に応じてそれらのリソースをメモリに読み込むことで、いつでも可能なときに全てのアプリケーション間でリソースの1つのコピーを共有する」ことが記載されているといえる。

(5)甲第5号証には、以下の記載がある(下線は当審で付加した)。
「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. 」(1枚目)
(当審仮訳:
App Extensionがどう機能するか理解する
App extensionはアプリではない。それは特定の拡張ポイントによって定義されたポリシーを守る、特定された明確な範囲のタスクを実装する。
App extensionのライフサイクル
App extensionはアプリではないため、そのライフサイクルと環境は異なる。ほとんどの場合、extensionは、ユーザがアプリのUIまたはアクティブに表示されている表示コントローラから選択したときに起動する。ユーザがApp extensionを選択するために使用するアプリは、ホストアプリと呼ばれる。ホストアプリは、ユーザーアクションに応答して要求を送信すると、当該extensionに提供されるコンテキストを定義し、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.」(1枚目)
(当審仮訳:
図2-1のステップ2で、システムはホストアプリの要求で識別されたapp extensionをインスタンス化し、それらの間に通信チャネルを設定する。extensionは、ホストアプリのコンテキスト内で画面を表示してから、ホストアプリのリクエストで受け取ったアイテムを使用してタスクを実行する(この例では、extensionは選択されたテキストを受け取る)。
図2-1のステップ3では、ユーザはApp extensionでタスクを実行またはキャンセルしてそれを却下する。このアクションに応答して、extensionはすぐにユーザのタスクを実行するか、必要に応じてそれを実行するためのバックグラウンドプロセスを開始することによって、ホストアプリケーションの要求を完了する。ホストアプリはextensionの表示を破棄し、ユーザはホストアプリ内の以前のコンテキストに戻る。extensionのタスクが完了したとき、すぐに、または、後に、結果がホストアプリに返されることがある。
App extensionがそのタスクを実行した(または、それを実行するためのバックグラウンドセッションを開始した)直後に、システムはステップ4に示すようにextensionを終了する。)

したがって、甲第5号証には、
「App extensionとは、アプリケーションではなく、ユーザがアプリのUIまたはアクティブに表示されている表示コントローラからApp extensionを選択すると、システムがApp extensionを起動し、ユーザがApp extensionを選択するために使用するアプリであるホストアプリとApp extensnionとの間に通信チャネルを設定し、典型的には、ユーザのタスクを実行して、ホストアプリから受けた要求を完了すると、直後に終了するもの」であることが記載されているといえる。

(6)甲第6号証には、以下の記載がある(下線は当審で付加した)。
「iOSのセキュリティ
iOS 10
2017年3月」(表紙)

「Appのセキュリティ
Appは現代のモバイル・セキュリティ・アーキテクチャにおいて最も重要な要素の1つです。App は生産性においてすばらしいメリットをもたらす一方で、適切に扱わないと、システムのセキュリティ、安定性、およびユーザデータに悪影響を及ぼす可能性があります。
このため、iOS には複数の保護レイヤーを構築し、App が署名され、検証され、サンドボックス化されていることを保証することでユーザデータを保護しています。これらの要素によって安定した安全な App プラットフォームが提供されているので、何千人ものデベロッパによる数十万もの App を、システムの完全性を損なうことなく iOS に配信することが可能になっています。そして、ユーザは、ウイルス、マルウェア、不正な攻撃などを過度に心配することなく、iOS デバイス上のこれらの App にアクセスできます。」(19ページ)

「ランタイムプロセスのセキュリティ
App が承認済みのソースからのものであることが確認されると、ほかの App やシステムのほかの部分の危殆化を防止するための iOS のセキュリティ対策が強制的に適用されます。
すべての他社製 App は「サンドボックス化」されるので、ほかの App によって保存されたファイルにアクセスしたり、デバイスに変更を加えたりすることはできません。これにより、ほかの Appによって保存された情報が収集または変更されるのを防ぐことができます。各 App にはファイル保存用の一意のホームディレクトリが用意されますが、これは App がインストールされるときにランダムに割り当てられます。他社製 App が自身の情報以外の情報にアクセスする必要がある場合は、iOS によって明示的に提供されるサービスを使用したときのみアクセスできます。」(20ページ)

したがって、甲第6号証(p.20)には、
「多数のAppを、システムの完全性を損なうことなく、iOSに配信することが可能になって」いることが記載されているといえる。
そして、「iOS10のセキュリティについて、すべての他社製 App は「サンドボックス化」されるので、ほかの App によって保存されたファイルにアクセスしたり、デバイスに変更を加えたりすることはできず、これにより、ほかの Appによって保存された情報が収集または変更されるのを防ぐことができ」ることが記載されているといえる。
また、「他社製 App が自身の情報以外の情報にアクセスする必要がある場合は、iOS によって明示的に提供されるサービスを使用したときのみアクセスでき」ることが記載されているといえる。

(7)甲第7の1号証には、iOSアプリで共通に利用されるディレクトリとして、Libraryサブディレクトリについて記載がある。

(8)甲第7の2号証の記載によれば、「File System Programming Guide」について、「ファイル、ディレクトリ、システムにおける他のコンテンツをどのように生成し、管理するかを記述した新しい文書が2011年6月6日に存在したこと」が認められる。

(9)甲第7の3号証には、以下の記載がある(下線は当審で付加した)。
「iOSアプリのファイル保存について」(1枚目)

「はじめに
iOSアプリのファイル保存が可能なディレクトリは以下ようになっている(はず)
iOS App
├── Documents
├── Library
│ ├── Caches
│ └── Preferences
└── tmp
」(1枚目)

「Library
これは、ユーザのデータファイル以外のファイル用の最上位ディレクトリです。通常、標準的なサブディレクトリを用意し、いずれか適当な場所に保存します。iOSアプリケーションは通常、Application SupportおよびCachesというサブディレクトリを使いますが、独自のサブディレクトリを作成しても構いません。
ユーザに見せたくないファイルはLibraryサブディレクトリ以下に置いてください。ユーザデータのファイル保存用に使ってはなりません。
Libraryディレクトリの内容は、Cachesサブディレクトリ以下を除き、iTunesによるバックアップの対象になります。」(1枚目)

したがって、甲第7の3号証には、
「iOSアプリのファイル保存について、ファイル保存が可能なディレクトリとして、Documents、Library、tmp等があり、ユーザに見せたくないファイルはLibraryサブディレクトリ以下に置くべきであり、Libraryはユーザデータのファイル保存用に使ってはならない」ことが記載されているといえる。

(10)甲第8号証には、写真及び図面とともに、iPhone 7について以下の記載がある(下線は当審で付加した)。
「容量^(2)32GB
128GB
256GB」(1枚目)



」(2枚目)



」(2枚目)



」(4枚目)



」(7枚目)



」(7枚目)

甲第8号証の1枚目及び7枚目の記載によれば、iPhone7は、32GB,128GBまたは256GBのいずれかの容量を有する記憶手段と、オペレーティングシステムiOS10及び内蔵アプリケーションを有している。そして、オペレーティングシステムiOS10及び内蔵アプリケーションが記憶手段の所定の領域に記憶されていることは自明である。
甲第8号証の記載によれば、iPhone7は携帯電話/ワイヤレス通信の機能、内蔵アプリケーションとしての電話アプリケーションを備えており、携帯電話として機能するから、発信元電話機より電話着信を受ける通信手段を備えているといえる。
また、iPhone7において、チップA10が、オペレーティングシステムiOS10によって制御され、オペレーティングシステムiOS10上で内蔵アプリケーションを実行することは明らかである。

したがって、甲第8号証には、
「オペレーティングシステムiOS10によって制御されるとともに、前記オペレーティングシステムiOS10上で動作する内蔵アプリケーションを実行するチップ(A10)と、
前記オペレーティングシステムiOS10と内蔵アプリケーションとを記憶する領域を含む記憶手段(32GB,128GBまたは256GBの容量の記憶装置)と、
発信元電話機より電話着信を受ける通信手段と、
ディスプレイと、
を備えるiPhone 7。」が記載されているといえる。

(11)甲第9号証には、以下の記載がある(下線は当審で付加した)。

「UPDATE
September 13, 2016
What’s new in iOS 10」(1枚目)
(当審仮訳:
アップデート
2016年9月13日
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.」(1枚目)
(当審仮訳:
これまでで最大のiOSリリースが本日利用可能になりました
iPhoneとiPad向けの無料のアップデートとして、これまでで最大のiOSリリースが本日利用可能になりました。iOS 10はメッセージについての大規模なリリースであり、あなたの大好きなアプリにSiriの新しい利用方法をもたらし、写真に、あなたの写真ライブラリから大好きで忘れられた出来事を再発見するのを助ける面白い方法であるメモリー機能を導入します。)

したがって、甲第9号証には、「iOS 10のリリース日は2016年9月13日(平成28年9月13日)」であること、そして、「iOS 10はiPhoneとiPadで利用可能」であることが記載されているといえる。

(12)甲第10号証には、以下の記載がある(下線は当審で付加した)。

「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.」(1枚目)
(当審仮訳:
iOS 10.0
この記事は、iOS 10で導入される主要な開発者関連の特徴を要約したものである。iOS 10は現在出荷されているiOSデバイス上で動作する。この記事はまた、新しい特徴についてより詳細にリストアップしている。)

「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.」(6枚目)
(当審仮訳:
CallKit
CallKitフレームワーク(CallKit.framework)は、VoIPアプリをiPhoneのUIと統合させ、ユーザにすばらしい体験をもたらす。このフレームワークを使うことで、ユーザにロックスクリーン上で、着信したVoIPコールを閲覧し応答させ、電話アプリのFavorites(よく使う項目)およびRecent views(履歴)でVoIPコールからの連絡先を管理させることができる。
CallKitは、app extensionを導入し、それにより着信拒否や発信者識別を可能とする。あなたは、電話番号を名前と関連づけたり、システムに電話番号がブロックされるべきときを伝えたりするためにapp extensionを生成することができる。)

したがって、甲10号証には、「iOS10で導入される主要な開発者関連の特徴として、CallKitが導入され、CallKitフレームワークはVoIPアプリをiPhoneのUIと統合させ、ユーザにロックスクリーン上で、着信したVoIPコールを閲覧し応答させ、電話アプリのFavorites(よく使う項目)およびRecent views(履歴)でVoIPコールからの連絡先を管理させる」ことが記載されているといえる。
また、「CallKitは、app extensionを導入し、それにより着信拒否や発信者識別を可能とし、電話番号を名前と関連づけたり、システムに電話番号がブロックされるべきときを伝えたりするためにapp extensionを生成することができる。」ことが記載されているといえる。

(13)甲第11号証には、Appleセキュリティアップデートについて、以下の記載がある(下線は当審で付加した)。
「iOS 10 iPhone 5 以降、iPad (第 4 世代) 以降、iPod touch (第 6 世代) 以降 2016-09-13」(12枚目)

したがって、甲11号証には、「iOS 10は、2016年9月13日(平成28年9月13日)にリリースされ、iPhone5以降を対象としたものである。」ことが記載されているといえる。

2-2 甲号証から把握される公知技術
(1)オペレーティングシステムである「iOS 10」について記載されている甲第8号証は、2016年9月7日(平成28年9月7日)に掲載されたものであり、甲第10号証は、2017年6月6日(平成29年6月6日)に更新されたものである。
したがって、2-1(10),(12)で述べた甲第8号証及び甲第10号証の記載事実は、原出願の出願日前に公知である。
甲第9号証は、2016年9月13日(平成28年9月13日)に更新されたものであるから、2-1(11)で述べた甲第9号証の記載事実は、原出願の出願日前に公知である。
ここで、甲第8号証及び甲第10号証には、「iOS 10」のリリース日について記載されていないものの、甲第9号証の記載によれば、2-1(11)のとおり、「iOS 10」は2016年9月13日に利用可能なオペレーティングシステムとしてリリースされているから、「iOS10」は、甲第8号証及び甲第10号証に記載された特徴のみならず、実際に利用可能なオペレーティングシステムとして原出願の出願日より前に公知である。
なお、甲第11号証は、2019年2月13日(平成31年2月13日)に公開されたものであり、原出願の出願日前に公知ではないものの、2-1(13)で述べたように、甲第9号証と同様に「iOS 10」のリリース日が2016年9月13日(平成28年9月13日)であることが記載されている。
そうすると、
「CallKit、すなわち、発信者識別を可能とするapp extensionが導入可能なフレームワーク、を導入する、オペレーティングシステムiOS10によって制御されるとともに、前記オペレーティングシステム上で動作する内蔵アプリケーションを実行するチップ(A10)と、
前記オペレーティングシステムiOS10と内蔵アプリケーションとを記憶する領域を含む記憶手段(32GB,128GBまたは256GBの容量の記憶装置)と、
発信元電話機より電話着信を受ける通信手段と、
ディスプレイと、
を備えるiPhone 7。」は公知技術である。

(2)甲第1号証は、2017年7月14日(平成29年7月14日)に掲載されたものであるから、2-1(1)で述べた甲第1号証の記載事実は、原出願の出願日前に公知である。
甲第1号証には、2-1(1)のとおり、「フレームワークであるCallKit」について記載されているものの、「CallKit」がどのようなハードウェア環境・ソフトウェア環境で動作するのかについて明記されていない。
ここで、甲第9号証の記載によれば、iOS 10はiPhoneで利用可能であり、甲第10号証の記載によれば、CallKitはiOS10で導入されたものである。また、甲第11号証の記載によれば、iOS 10は、iPhone5以降を対象としたものであり、これはiPhone5以降のiPhoneであるiPhone7がオペレーティングシステムiOS10を有するとの甲第8号証の記載とも整合する。
甲第1号証及び甲第10号証は、同じアップル社のウェブページ(apple.com)で掲載されたものであり、甲第1号証に記載された「CallKit」と、甲第10号証に記載された「CallKit」は、同じフレームワークを示しているといえる。
そうすると、甲第1号証に記載された「CallKit」は、iOS 10がインストールされたiPhone5以降で利用可能といえる。
次に、甲第4号証は、2013年9月17日(平成25年9月17日)に更新されたものであり、甲第5号証は、2017年10月19日(平成29年10月19日)に更新されたものであるから、2-1(4),(5)で述べた甲第4,5号証の記載事実は、原出願の出願日前に公知である。
甲第1号証及び甲第4,5,10号証は、全て同じアップル社のウェブページ(apple.com)で掲載されたものであるから、甲第1号証に記載された「Framework」と、甲第4号証に記載された「Framework」は同じものを示しており、甲第1号証、甲第5号証及び甲第10号証のそれぞれに記載された「app extension」は、同じものを示しているといえる。
甲第4号証の記載によれば、2-1(4)のとおり、フレームワークとは、システムがメモリに読み込むことで、いつでも可能なときに全てのアプリケーション間で共有するものである。しかしながら、甲第4号証は一般的なフレームワーク(Framework)に関して記載したものであり、電話着信を受けた場合の発信者情報の表示について記載したものではない。
甲第5号証の記載によれば、2-1(5)のとおり、「App extensionとは、システムにより起動され、ユーザがApp extensionを選択するために使用するアプリであるホストアプリとApp extensnionとの間に通信チャネルを設定し、典型的には、ユーザのタスクを実行して、ホストアプリから受けた要求を完了する」ものである。しかしながら、甲第5号証は一般的なApp extensionに関して記載したものであり、電話着信を受けた場合の発信者情報の表示について記載したものではない。
なお、「CallKit」に関連して、2-1(2),(3)のとおり、甲第2号証には、「addIdentificationEntry」について、甲第3号証には、「CXCallDirectoryExtensionContext」についてそれぞれ記載されているものの、その作成日や更新日の記載はないから、甲第2号証及び甲第3号証の記載事実が原出願の出願日前に公知であるとはいえない。

したがって、甲第1号証及び甲第10号証によれば、「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)の表示を行うソーシャルネットワークアプリケーション。」であることも公知技術である。
また、甲第1号証及び甲第8?11号証によれば、上記の「ソーシャルネットワークアプリケーション」は、iOS 10が動作するiPhone7で利用可能であることが公知である。

(3)甲第6号証は、2017年3月(平成29年3月)に作成されたものであるから、2-1(6)で述べた甲第6号証の記載事実は、原出願の出願日前に公知である。
しかし、甲第6号証の記載は、2-1(6)のとおり、ほかのAppによって保存されたファイルへの他社製Appのアクセス制限に関するものであるが、Appによって保存されたファイルへの利用者のアクセス制限、すなわち、「利用者がアクセスできない」領域やデータに関するものではない。

次に、甲第7の3号証は、2016年8月19日(平成28年8月19日)に投稿(掲載)されたものであるから、2-1(9)で述べた甲第7の3号証の記載事実は、原出願の出願日前に公知である。
甲第7の3号証の記載によれば、2-1(9)のとおり、「iOSアプリのファイル保存について、ファイル保存が可能なディレクトリとして、Documents、Library、tmp等があり、ユーザに見せたくないファイルはLibraryサブディレクトリ以下に置くべきであり、Libraryはユーザデータのファイル保存用に使ってはならない」ことが公知である。甲第7の3号証には、iOSのバージョンについて記載されていないものの、その更新日が2016年8月19日であり、iOS 10のリリース日である2016年9月13日より前であるから、iOS 10よりも以前のバージョンのiOSで既にLibraryサブディレクトリがファイル保存可能なディレクトリとして公知であったといえる。
甲第7の1号証には、「Updated: 2018-04-09」と記載されており、その更新日は平成30年4月9日であるが、当該更新日は原出願の出願日より後であり、当該更新日の記載からは、甲第7の1号証の記載事実が原出願の出願日前に公知であるとはいえない。
異議申立人は甲第7の1号証の作成日を立証するための証拠として、甲第7の2号証を示している。ここで、甲第7の2号証には、その更新日が2018年4月9日(平成30年4月9日)であることが記載されていることから、甲第7の2号証は原出願の出願日前に公知ではない。
甲第7の2号証によれば、2-1(8)のとおり、「File System Programming Guide」について、「ファイル、ディレクトリ、システムにおける他のコンテンツをどのように生成し、管理するかを記述した新しい文書が2011年6月6日に存在したこと」が事実として認められるが、当該新しい文書の内容について記載がなく、当該新しい文書の内容が甲第7の1号証と同じであるか否か不明であるから、甲第7の2号証の記載を参酌しても、甲第7の1号証の記載事実が原出願の出願日より前に公知であるとはいえない。
なお、甲第7の1号証の3枚目には、iOSのファイルシステムに関連して、iOSアプリで共通に利用されるディレクトリとして、Libraryサブディレクトリを、ユーザに見せたくないファイルに使用するとの記載があり、その記載内容については、甲第7の3号証と整合している。

したがって、甲第7の3号証によれば、iOS10におけるアプリについて、
「iOSアプリは、Documents、Library、tmp等のディレクトリをファイル保存に利用可能であり、ユーザに見せたくないファイルは、Libraryサブディレクトリ以下に置くべき」ことは公知技術である。

(4)スマートフォンのOS上でミドルウェア(フレームワーク)を用いてアプリケーションが動作することは技術常識であるから、(1)?(3)に記載された公知技術により、(1)に記載の「iPhone7」のiOS10上で、(2)に記載の「CallKit」及び「ソーシャルネットワークアプリケーション」を動作させ、該ソフトウェアが(3)に記載の「iOS10におけるアプリ」のファイルアクセスを用いること、つまり、
「オペレーティングシステム(iOS10)によって制御されるとともに、前記オペレーティングシステム上で動作する内蔵アプリケーション及びCallKitフレームワークを用いたソーシャルネットワークアプリケーションを実行するチップ(A10)と、
前記オペレーティングシステム、前記内蔵アプリケーション及び前記ソーシャルネットワークアプリケーションとを記憶する領域を含む記憶手段と、
発信元電話機より電話着信を受ける通信手段と、
ディスプレイと、
を備え、
前記ソーシャルネットワークアプリケーションは、
Documents、Library、tmp等のディレクトリをファイル保存に利用可能であり、ユーザに見せたくないファイルは、Libraryサブディレクトリ以下に置くように設計されており、
前記ソーシャルネットワークアプリケーションは、さらに、
電話番号によって着信した発信者を特定するために、CallKitによって導入されるCall Directory app extensionを用いて、ユーザの友人の全ての電話番号をダウンロードして追加し、
発信者の特定にあたって、電話機であるiPhone7が着信を受けると、前記オペレーティングシステムは、一致する電話番号を見つけるために、まずユーザの連絡先を調べ、一致するものがなければ、システムはソーシャルネットワークアプリケーションのCall Directory extensionを調べて一致するエントリを見つけ、発信者情報(例えば、発信者ID:Jane Appleseed)の表示を行う
iPhone 7。」は公然知られた発明(以下、「引用発明」という。)である。

2-3 本件発明1?4の進歩性について
(1)本件発明1と引用発明との対比
(ア)引用発明における「オペレーティングシステム(iOS10)」は、本件発明1における「基本ソフトウェア」に相当する。
(イ)引用発明における「CallKitフレームワークを用いたソーシャルネットワークアプリケーション」は、アプリケーション・プログラムであるから、引用発明における「ソーシャルネットワークアプリケーション」と、本件発明1における「アプリケーション・プログラム」は、「基本ソフトウェア上で動作し、記憶手段の領域に記憶されるアプリケーション・プログラム」である点で共通する。
(ウ)「チップ」とは、一般にCPUの俗称として使用され、CPUはプロセッサであるから、引用発明における「チップ(A10)」は、本件発明1における「プロセッサ」に相当する。
(エ)引用発明における「記憶手段」は、「オペレーティングシステム」及び「ソーシャルネットワークアプリケーション」を記憶する領域を含む。さらに、「ソーシャルネットワークアプリケーション」は、iOS 10上で動作するiOSアプリであって、ユーザに見せたくないファイルを置くべき、Libraryサブディレクトリ以下のディレクトリをファイル保存に利用可能であるから、「記憶手段」は、ユーザがアクセスできない領域を含むといえる。
ここで、本件発明1における「秘匿領域」とは、本件明細書の【0028】の記載によれば、「利用者Uがアクセスすることができない領域」であるから、引用発明における「記憶手段」に含まれるユーザがアクセスできない領域は「秘匿領域」といえる。
したがって、引用発明における「記憶手段」と、本件発明1における「記憶手段」とは、「基本ソフトウェアとアプリケーション・プログラムとを記憶する領域と、利用者がアクセスできない秘匿領域を含む」点で一致する。
(オ)引用発明における「発信元電話機より電話着信を受ける通信手段」は、本件発明1における「発信元電話機より電話着信を受ける通信手段」に相当する。
(カ)引用発明における「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」を調べて電話番号に一致するエントリを見つけるものであるから、電話番号及び発信者の名称情報を、電話着信を受けた場合にオペレーティングシステムが検索可能であるといえる。
そして、アプリケーション・プログラムが、プロセッサにより処理されることで、所定の機能を発揮することは技術常識である。
そうすると、引用発明における「ソーシャルネットワークアプリケーション」と、本件発明1における「アプリケーション・プログラム」は、「プロセッサ」を「電話番号と当該電話番号に対応する名称情報とを含むデータを格納する手段」として機能させ、「電話番号及び発信者の名称情報を、電話着信を受けた場合に基本ソフトウェアが検索可能」であるように機能させる「アプリケーション・プログラム」である点で共通する。
(キ)引用発明における「iPhone7」は、表示装置である「ディスプレイ」を備え、発信者情報(例えば、発信者ID:Jane Appleseed)の表示を行うから、引用発明における「ディスプレイを備え、発信者情報の表示を行うiPhone7」は、「発信者情報表示装置」であるといえる。

上記(ア)?(カ)より、本件発明1と引用発明との一致点は、次のとおりである。
【一致点】
「基本ソフトウェアによって制御されるとともに、前記基本ソフトウェア上で動作するアプリケーション・プログラムを実行するプロセッサと、
基本ソフトウェアと前記アプリケーション・プログラムとを記憶する領域と、利用者がアクセスできない秘匿領域を含む記憶手段と、
発信元電話機より電話着信を受ける通信手段と、
を備え、
前記アプリケーション・プログラムは、前記プロセッサを
電話番号と当該電話番号に対応する名称情報とを含むデータを格納する手段として機能させ、
前記データに含まれる電話番号及び発信者の名称情報を、電話着信を受けた場合に基本ソフトウェアが検索可能であるように機能させる
発信者情報表示装置。」

一方で、本件発明1と引用発明とは、以下の点で相違する。
【相違点1】
「電話番号と当該電話番号に対応する名称情報とを含むデータを格納する手段」について、本件発明1では、「アプリケーション・プログラム」は、「プロセッサ」を「電話番号と当該電話番号に対応する名称情報とを含むデータを前記秘匿領域に格納する手段」として機能させるのに対し、引用発明では、「ソーシャルネットワークアプリケーション」は、「チップ」を「電話番号によって着信した発信者を特定するために、Call Directory app extensionを用いて、ユーザの友人の全ての電話番号をダウンロードして追加」するように機能させるものの、「Call Directory app extension」に記憶される電話番号と発信者情報が「秘匿領域」に格納されるか不明である点。

【相違点2】
「前記データに含まれる電話番号及び名称情報を、電話着信を受けた場合に基本ソフトウェアが検索可能」とする点について、本件発明1では、「アプリケーション・プログラム」は、「プロセッサ」を「前記データに含まれる電話番号及び名称情報を、前記秘匿領域に格納されており前記電話着信を受けた場合に前記基本ソフトウェアが検索可能であって、かつ利用者がアクセスできない第1の発信者データへ登録する手段」として機能させるのに対して、引用発明では、「ソーシャルネットワークアプリケーション」は、「チップ」を「Call Directory app extension」に記憶された電話番号と発信者情報を、「秘匿領域」に格納されており「利用者がアクセスできない発信者データ」へ登録する手段として機能させるか不明である点。

(2)本件発明1の進歩性についての判断
(1)で挙げた【相違点1】について検討する。
本件発明1における「秘匿領域」とは、2-3(エ)で述べたように、「利用者Uがアクセスすることができない領域」である。
また、本件明細書の【0004】の記載によれば、本件発明が解決しようとする課題の一つは、携帯端末を紛失すると、電話帳(アドレス帳)から、個人情報のみならずビジネスに関する情報まで漏洩してしまうリスクを未然に防ぐことであるから、本件発明1における「秘匿領域」は、携帯端末を紛失することで、他の利用者に当該携帯端末が利用され、電話帳(アドレス帳)から情報漏洩してしまうリスクを防ぐために設けられていると考えられる。

これに対し、引用発明の「記憶手段」は、「利用者がアクセスできない秘匿領域を含む」ものであり、また、甲第7の3号証には、「iOSアプリは、Documents、Library、tmp等のディレクトリをファイル保存に利用可能であり、ユーザに見せたくないファイルは、Libraryサブディレクトリ以下に置くべき」ことが記載されている。
しかしながら、甲第7の3号証、あるいは、甲第1号証、甲第4?6号証及び甲第8?11号証のいずれにも、「Call Directory app extension」あるいはユーザの友人の電話番号と発信者情報がユーザに見せたくないファイルであることは記載されていないから、当業者が「Call Directory app extension」をLibraryサブディレクトリ以下に作成・保存する動機付けが生じるとはいえない。

したがって、甲第1号証、甲第4?6号証、甲第7の3号証及び甲第8?11号証には、「アプリケーション・プログラム」は、「プロセッサ」を「電話番号と当該電話番号に対応する名称情報とを含むデータ」を利用者がアクセスすることができない領域である「秘匿領域に格納する手段」として機能させる点について記載されていない。
以上より、「アプリケーション・プログラム」が、「プロセッサ」を「電話番号と当該電話番号に対応する名称情報とを含むデータ」を利用者がアクセスすることができない領域である「秘匿領域に格納する手段」として機能させる点は、甲第1号証、甲第4?6号証、甲第7の3号証及び甲第8?11号証に基づいて当業者が容易になし得るものではない。

次に、(1)で挙げた【相違点2】について検討する。
本件発明1における「第1の発信者情報データ」とは、実施形態の「発信者情報データX3」に対応するものである。
本件明細書の【0034】の記載によれば、「発信者情報データX3」は、「発信者の表示名及び電話番号などを含むアドレスデータ」であり、秘匿領域に格納されているため、利用者は「登録、削除、閲覧、編集などのアクセスを行うこと」はできず、利用者に対し「秘匿された電話帳」である(なお、本件明細書の【0047】の記載によれば、「第1の発信者情報データ」(発信者情報データX3)の削除は可能としてもよい)。
しかし、甲第1号証、甲第4?6号証、甲第7の3号証及び甲第8?11号証には、アプリケーション・プログラムが、チップをCall Directory app extensionによりダウンロードされた電話番号及び発信者情報を、発信者データとして登録する手段として機能させる点について記載されていない。
仮に、当業者が、Call Directory app extensionによりダウンロードされた電話番号及び発信者情報を、発信者データとして登録することを容易になし得るとしても、当該発信者データを利用者がアクセスできない「秘匿領域」に格納する点について、甲第1号証、甲第4?6号証、甲第7の3号証及び甲第8?11号証には、記載されていないから、【相違点1】において述べたとおり、当業者が「Call Directory app extension」をLibraryサブディレクトリ以下に作成・保存する動機付けが生じるとはいえない。
以上より、「アプリケーション・プログラム」が、「プロセッサ」を「前記データに含まれる電話番号及び名称情報を、前記秘匿領域に格納されており前記電話着信を受けた場合に前記基本ソフトウェアが検索可能であって、かつ利用者がアクセスできない第1の発信者データへ登録する手段」として機能させる点は、甲第1号証、甲第4?6号証、甲第7の3号証及び甲第8?11号証に基づいて当業者が容易になし得るものではない。

よって、本件発明1と引用発明は相違点1ないし2の点で相違し、相違点1ないし2の点は、甲第1?11号証に基づいて当業者が容易になし得るものではない。

(3)異議申立人の主張について
異議申立人は、「Call Directory app extension」はサンドボックス(sandbox)によって保護されることで他のアプリから保護されるので、たとえば、windowsのエクスプローラのようなプログラムを用いて利用者は登録、閲覧、編集、削除をすることはできず、「Call Directory app extension」は「秘匿領域」に相当する旨を主張している。
また、異議申立人は、甲第3号証には、CallKitにおいて、識別エントリ(連絡先)の追加(登録)および削除は処理機能として用意されているものの、例えば読出し、編集は処理機能として用意されておらず、CallKitを含むiOS10を搭載したiPhone 7において、CallKitは、ダウンロードされたデータを「Call Directory app extension」に追加(登録)すること、および削除することしか認められていないから、「Call Directory app extension」は「秘匿領域」に相当する旨を主張している。

しかし、(2)でも述べたように、本件発明1における「秘匿領域」とは、「電話番号と当該電話番号に対応する名称情報とを含むデータを格納する手段」として、プロセッサを機能させる「アプリケーション・プログラム」以外の他社製App(アプリ)から、秘匿される領域を意味しているのではなく、あくまで利用者がアクセスすることができない領域であるから、「Call Directory app extension」は「秘匿領域」に相当するものではない。
ここで、甲第6号証には、「iOS 10では、すべての他社製 App は、「サンドボックス化」され、ほかの App によって保存されたファイルにアクセスすることはできず、iOS によって明示的に提供されるサービスを使用したときのみ自身の情報以外の情報にアクセスすることができ」ることが記載されているものの、利用者がAppによって保存されたファイルにアクセスすることができないようにする点については記載されていない。
例えば、利用者が、ファイルを保存したアプリケーション自体や内蔵アプリケーション、あるいは、他社製AppがiOSによって明示的に提供されるサービスを使用したときにも、利用者が保存されたファイルにアクセスできないようにすることについて、甲第6号証に記載されていない。

次に、甲第3号証には、2-1(3)で述べたように、その作成日や公知日は記載されていないものの、CallKitにおいて、識別エントリ(連絡先)の読出し、編集は処理機能として用意されておらず、CallKitを含むiOS10を搭載したiPhone 7においては、ダウンロードされたデータを「Call Directory app extension」に追加(登録)および削除することしか認められていないとの異議申立人の主張についても一応検討しておく。
甲第3号証には、CallKitは識別エントリ(連絡先)の読出し、編集を禁止するものであることが記載されているわけではない。
加えて、甲第10号証には、むしろCallKitフレームワークにより、VoIPアプリをiPhoneのUIと統合させ、電話アプリのFavorites(よく使う項目)およびRecent views(履歴)でVoIPコールからの連絡先を管理できることが記載されている。
したがって、甲第3号証に、CallKitにおける、読出し、編集の処理機能についての記載がないことをもって、CallKitは、ダウンロードされたデータを「Call Directory app extension」に追加(登録)すること、および削除することしか認められていないとまではいえない。

(4)本件発明2?4の進歩性についての判断
本件発明2?4は、本件発明1をさらに限定した発明であるから、上記(2),(3)に記載した本件発明1に対する理由と同様の理由により、甲第1号証?甲第11号証に基づいて、当業者が容易に発明することができたものではない。

(5)小括
以上のとおり、取消理由2によって請求項1?4に係る特許を取り消すことはできない。

第5 むすび
したがって、特許異議の申立ての取消理由1、取消理由2及び証拠によっては、請求項1?4に係る特許を取り消すことはできない。
また、他に請求項1?4に係る特許を取り消すべき理由を発見しない。
よって、結論のとおり決定する。
 
異議決定日 2019-05-20 
出願番号 特願2018-43479(P2018-43479)
審決分類 P 1 651・ 537- Y (H04M)
P 1 651・ 121- Y (H04M)
P 1 651・ 536- Y (H04M)
最終処分 維持  
前審関与審査官 白川 瑞樹  
特許庁審判長 吉田 隆之
特許庁審判官 富澤 哲生
古河 雅輝
登録日 2018-07-27 
登録番号 特許第6375464号(P6375464)
権利者 株式会社トランス・アーキテクト
発明の名称 発信者情報表示装置及びプログラム  
代理人 特許業務法人スズエ国際特許事務所  
  • この表をプリントする

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