JP6782609B2 - 端末、方法及びプログラム - Google Patents

Description

本発明は、端末、方法及びプログラムに関する。

スマートフォンに用いられるモバイルＯＳ（Operating System）として、Ａｎｄｒｏｉｄ（登録商標）及びｉＯＳが知られている。これらのモバイルＯＳには、ＯＳベンダにより提供される標準アプリケーションが予めインストールされている。標準アプリケーションには、例えば、電話の発着信を行う通話アプリケーション、電話帳を管理する電話帳アプリケーションなどがある。モバイルＯＳ及び標準アプリケーションにより提供されるＡＰＩ（Application Programming Interface）の仕様は、例えば非特許文献１などに公開されている。

"iOS Address Book プログラミングガイド"、[online]、[平成２８年１０月６日検索]、インターネット＜https://developer.apple.com/jp/documentation/AddressBookProgrammingGuideforiPhone.pdf＞

一般的に、標準アプリケーションとしてインストールされている電話帳アプリケーションには、任意のアプリケーションから、電話帳に登録されているレコードにアクセスするＡＰＩが提供されている。しかしながら、本ＡＰＩを用いることで、悪意のある第三者が、電話帳に登録されているレコードを取得して外部に送信するマルウェア等を提供することが可能であり、情報漏えいに繋がるリスクがあるという問題がある。電話帳に電話番号及びユーザ名を登録しなければ情報漏えいを防ぐことができる。しかしながら、電話帳に電話番号及びユーザ名を登録しないと、利用者の利便性を損ねるという問題が生じることになる。

開示の技術は上記に鑑みてなされたものであって、ＯＳベンダが標準アプリケーションを提供する端末において、マルウェア等による情報漏えいリスクを軽減しつつ、利用者の利便性を確保することが可能な技術を提供することを目的とする。

開示の技術の端末は、ＯＳベンダにより提供される第一のアプリケーションと、第三者により提供される第二のアプリケーションとがインストールされた端末であって、前記第一のアプリケーションは、着信を受けたこと及び発信元電話番号を前記第二のアプリケーションに通知する着信通知手段と、前記第二のアプリケーションから、発信元ユーザ名を取得する取得手段と、取得された前記発信元ユーザ名を表示する表示手段と、を有し、前記第二のアプリケーションは、電話帳を、当該端末のＯＳにおいて前記第二のアプリケーションのみから参照可能な記憶領域に記憶する記憶手段と、前記第一のアプリケーションから、電話の着信を受けたこと及び発信元電話番号の通知を受け付ける受付手段と、前記第一のアプリケーションから、着信を受けたこと及び発信元電話番号の通知を受け付けた場合に、前記電話帳から発信元電話番号に対応する発信元ユーザ名を取得して前記第一のアプリケーションに通知するユーザ名通知手段と、を有する。

開示の技術によれば、ＯＳベンダが標準アプリケーションを提供する端末において、マルウェア等による情報漏えいリスクを軽減しつつ、利用者の利便性を確保することが可能な技術が提供される。

各実施の形態に係る電話帳管理システムの構成例を示す図である。 第一の実施の形態に係るサーバの機能構成例を示す図である。 第一の実施の形態に係る端末の機能構成例を示す図である。 第一の実施の形態において着信時に端末が行う処理手順の一例を示すシーケンス図である。 第一の実施の形態における電話帳の同期先の例を示す図である。 第二の実施の形態に係る端末の機能構成例を示す図である。 第二の実施の形態における電話帳の同期先の例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。本実施の形態に係る電話帳管理システムは、主に企業内で用いられる電話帳を管理することを想定しているが、これに限定されるものではない。本実施の形態に係る電話帳管理システムは、個人で電話帳を管理する場合にも利用することが可能である。

＜＜システム構成＞＞
図１は、各実施の形態に係る電話帳管理システムの構成例を示す図である。本電話帳管理システムは、電話帳を管理するサーバ１と、サーバ１と通信可能な端末２とを含む。図１には端末２が１つ図示されているが、本電話帳管理システムは、２以上の端末２を含んでいてもよい。

サーバ１で管理される電話帳には、少なくとも、宛先の電話番号とユーザ名とが対応づけて登録されている。

端末２は、モバイルＯＳがインストールされたスマートフォン、及び、タブレット端末などである。モバイルＯＳは、ｉＯＳであってもよいし、Ａｎｄｒｏｉｄ（登録商標）であってもよい。また、端末２には、ＯＳベンダにより提供される標準アプリケーション（以下、標準ＡＰＬと称する）として、通話アプリケーション（以下、標準通話ＡＰＬ３０と称する）と電話帳を管理する電話帳アプリケーション（以下、標準電話帳ＡＰＬ４０と称する）が予めインストールされている。標準電話帳ＡＰＬ４０は、任意のＡＰＬから、電話帳に登録されているレコードにアクセスするＡＰＩを備えている。従って、標準電話帳ＡＰＬ４０が管理する電話帳は、任意のＡＰＬから参照可能な電話帳と称してもよい。本実施の形態では、標準電話帳ＡＰＬ４０が管理する電話帳を空にしておく（電話番号等の登録を行わない）ことで個人情報がマルウェア等を介して外部に漏洩することを防止する。

また、端末２には、ＯＳベンダ以外の第三者（サードパーティー）により提供される、電話帳を管理するアプリケーション（以下、電話帳管理ＡＰＬ２０と称する）がインストールされている。電話帳管理ＡＰＬ２０は、サーバ１と通信することで、サーバ１で管理されている電話帳の全部又は一部と、電話帳管理ＡＰＬ２０自身が管理する電話帳とを同期する機能を有する。また、電話帳管理ＡＰＬ２０は、電話帳管理ＡＰＬ２０自身が管理する電話帳を、電話帳管理ＡＰＬ２０のみから参照可能な記憶領域に格納する。例えば、ｉＯＳ及びＡｎｄｒｏｉｄ（登録商標）などのモバイルＯＳは、個人情報の漏洩等のセキュリティリスクを抑えるため、インストールされたＡＰＬに対し、ＡＰＬ自身のみが参照可能な記憶領域を確保する機能を有している。電話帳管理ＡＰＬ２０は、電話帳管理ＡＰＬ２０のみが参照可能な記憶領域に電話帳を格納することで、電話帳に含まれる個人情報がマルウェア等を介して外部に漏洩することを防止する。

以下、本実施の形態を第一の実施の形態と第二の実施の形態に分けて説明する。第一の実施の形態は、モバイルＯＳがＡｎｄｒｏｉｄ（登録商標）である場合を想定しており、第二の実施の形態は、モバイルＯＳがｉＯＳである場合を想定している。しかしながら、モバイルＯＳの種類はこれに限定されるものではない。

＜＜第一の実施の形態＞＞
第一の実施の形態では、標準通話ＡＰＬ３０は、着信を受けたこと及び発信元電話番号を他のＡＰＬに通知するＡＰＩと、発信元ユーザ名を他のＡＰＬから受け取るＡＰＩとを備えている。また、標準通話ＡＰＬ３０は、受け取った発信元ユーザ名を、端末２の着信画面に表示する機能を備えている。電話帳管理ＡＰＬ２０は、標準通話ＡＰＬ３０から着信を受けたこと及び発信元電話番号の通知を受けた場合、電話帳管理ＡＰＬ２０のみから参照可能な記憶領域に格納されている電話帳から発信元ユーザ名を検索して標準通話ＡＰＬ３０に通知する。これにより、発信元電話番号を端末２のディスプレイに表示することができ、電話帳に含まれる個人情報がマルウェア等を介して外部に漏洩することを防止しつつ、利用者の利便性を確保することが可能になる。

＜機能構成＞
（サーバ）
図２は、第一の実施の形態に係るサーバの機能構成例を示す図である。本実施の形態に係るサーバ１は、通信部１０１と、記憶部１０２と、同期部１０３とを有する。

通信部１０１と、記憶部１０２と、同期部１０３とは、１つのコンピューターを用いて実現されてもよいし、異なるコンピューターを用いて実現されていてもよいし、細かい単位でコンピューターが分散されていてもよい。すなわち、サーバ１は、１又は複数のコンピューターを用いて実現されていてもよい。また、当該１又は複数のコンピューターは、仮想化技術を利用した仮想サーバであってもよいし、クラウド上に実装された仮想サーバであってもよい。

通信部１０１は、端末２と通信する機能を有する。記憶部１０２は、サーバ１が管理する電話帳を記憶する機能を有する。同期部１０３は、端末２からの要求に基づき、記憶部１０２に記憶されている電話帳の全部又は一部を端末２に送信することで、端末２に記憶されている電話帳と同期を行う機能を有する。

（端末）
図３は、第一の実施の形態に係る端末の機能構成例を示す図である。第一の実施の形態に係る端末２には、電話帳管理ＡＰＬ２０と、標準通話ＡＰＬ３０と、標準電話帳ＡＰＬ４０と、ＯＳ５０とがインストールされている。電話帳管理ＡＰＬ２０は、受付部２０１と、通知部２０２と、同期部２０３と、判定部２０４と、記憶部２０５とを有する。また、標準通話ＡＰＬ３０は、発着信処理部３０１と、通知部３０２と、取得部３０３と、表示部３０４とを有する。また、標準電話帳ＡＰＬ４０は、電話帳を格納可能な記憶部４０１を有する。また、ＯＳ５０は、端末２と通信する通信部５０１を有する。ＯＳ５０は、ＯＳとしての動作を行うための図示しない機能も有するものである。電話帳管理ＡＰＬ２０及び標準通話ＡＰＬ３０は、各々が備えるＡＰＩを介して各種情報の通知を行う。

受付部２０１は、標準通話ＡＰＬ３０から、電話の着信を受けたこと及び発信元電話番号の通知を受け付ける。通知部２０２は、受付部２０１で電話の着信を受けたこと及び発信元電話番号の通知を受け付けた場合に、記憶部２０５に記憶されている電話帳を検索することで発信元ユーザ名を取得し、取得した発信元ユーザ名を標準通話ＡＰＬ３０に通知する。

同期部２０３は、サーバ１に記憶される電話帳の全部又は一部と、記憶部２０５に記憶される電話帳との同期を行う機能を有する。また、同期部２０３は、サーバ１に記憶される電話帳のうち、利用頻度が高い候補の順に所定の件数の電話帳、又は事前に同期対象として設定されている所定の件数の電話帳を取得し、記憶部２０５に記憶されている電話帳と同期する機能を有していてもよい。また、同期部２０３は、サーバ１に記憶される電話帳の全部又は一部を、判定部２０４で判定された同期先の電話帳と同期させるようにしてもよい。例えば、同期部２０３は、判定部２０４において、サーバ１に記憶される電話帳の全部又は一部を、自身の記憶部２０５に記憶されている電話帳と同期させると判定された場合に、サーバ１から取得した電話帳を、自身の記憶部２０５に記憶されている電話帳と同期させるようにしてもよい。

判定部２０４は、サーバ１から取得した電話帳を、記憶部２０５に記憶されている電話帳と同期させるか、標準電話帳ＡＰＬ４０が管理する電話帳と同期させるか、又は、いずれの電話帳とも同期させないかを、所定の条件に基づいて判定する機能を有する。記憶部２０５は、電話帳を、電話帳管理ＡＰＬ２０のみから参照可能な記憶領域に記憶する機能を有する。

発着信処理部３０１は、ＯＳ５０と連携し、通話の発信及び着信に関する処理を行う機能を有する。通知部３０２は、発着信処理部３０１で電話の着信を受けたこと及び発信元電話番号を、電話帳管理ＡＰＬ２０に通知する機能を有する。取得部３０３は、電話帳管理ＡＰＬ２０から、発信元ユーザ名を取得する機能を有する。表示部３０４は、取得部３０３で取得した発信元ユーザ名を端末２が備えるディスプレイ等に表示する機能を有する。

なお、判定部２０４をサーバ１に配置するようにしてもよい。この場合、端末２の同期部２０３は、サーバ１に配置された判定部で判定された同期先の電話帳と同期を行う。

＜処理手順＞
続いて、第一の実施の形態に係る端末２が行う動作について、図を参照しつつ説明する。

（発信元のユーザ名の表示について）
図４は、着信時に端末が行う処理手順の一例を示すシーケンス図である。まず、標準通話ＡＰＬ３０の発着信処理部３０１は、ＯＳ５０から、着信を受けたこと及び発信元の電話番号を受け付ける（Ｓ１０１）。続いて、標準通話ＡＰＬ３０の通知部３０２は、着信を受けたこと及び発信元電話番号を、電話帳管理ＡＰＬ２０に通知する。電話帳管理ＡＰＬ２０の受付部２０１は、着信を受けたこと及び発信元電話番号を標準通話ＡＰＬ３０から受け付ける（Ｓ１０２）。

続いて、電話帳管理ＡＰＬ２０の通知部２０２は、発信元電話番号をキーに記憶部２０５に記憶されている電話帳を検索し、発信元ユーザ名を取得する（Ｓ１０３）。

続いて、通知部２０２は、発信元ユーザ名を標準通話ＡＰＬ３０に通知する。標準通話ＡＰＬ３０の取得部３０３は、発信元ユーザ名を電話帳管理ＡＰＬ２０から取得する（Ｓ１０４）。続いて、標準通話ＡＰＬ３０の表示部３０４は、取得された発信元ユーザ名を端末２が備えるディスプレイに表示させる（Ｓ１０５）。

（電話帳の同期処理について）
第一の実施の形態では、電話帳管理ＡＰＬ２０は、サーバ１と通信することで、サーバ１で管理されている電話帳の全部又は一部と、電話帳管理ＡＰＬ２０が管理する電話帳とを同期する機能を有する。ここで、サーバ１に格納されている電話帳の件数が多い場合、同期に時間を要することになる。第一の実施の形態に係る電話帳管理システムは、主に企業内で用いられる電話帳を管理することを想定していることから、電話帳の件数は膨大である可能性が高い。そこで、第一の実施の形態では、サーバ１で管理されている電話帳のうち、所定の件数のレコードのみを電話帳管理ＡＰＬ２０で管理される電話帳と同期するようにしてもよい。より具体的には、サーバ１の同期部１０３及び電話帳管理ＡＰＬ２０の同期部２０３は、サーバ１に記憶されている電話帳のうち、利用頻度が高い候補の順に所定の件数のレコード、又は事前に同期対象として設定されている所定の件数のレコードを、電話帳管理ＡＰＬ２０で管理される電話帳と同期するようにしてもよい。

なお、サーバ１で管理される電話帳は、複数のカテゴリに分割されていてもよい。複数のカテゴリとは、例えば、各社員が共通に利用する社内の電話番号（例えば、各部門の代表番号など）が格納される電話帳、各社員が共通に利用する社外の電話番号（例えば、顧客の電話番号など）が格納される電話帳、各社員が個人的に利用する電話番号が格納される電話帳などである。この場合、上述した"利用頻度が高い候補の順"は、複数のカテゴリ全体で利用頻度が高い順であってもよいし、複数のカテゴリの各々について利用頻度が高い順であってもよい。前者の場合、複数のカテゴリ全体で利用頻度が高い候補の順に所定の件数のレコードが電話帳管理ＡＰＬ２０で管理される電話帳と同期され、後者の場合、複数のカテゴリの各々について、所定の件数のレコードが電話帳管理ＡＰＬ２０で管理される電話帳と同期されることになる。

同期が行われるタイミングは、例えば、予め定められたタイミング（例えば１日１回など）であってもよいし、サーバ１で管理される電話帳が更新されたタイミングであってもよい。

以上説明した同期処理によれば、サーバ１に格納されている電話帳の件数が多い場合であっても、同期に要する時間を短縮することが可能になる。

また、具体的には後述するが、本実施の形態では"電話帳の同期を行わない"ことも可能である。しかしながら、電話帳の同期を行わない場合、電話帳の参照が必要になる度にサーバ１及び端末２の間で通信が発生してしまい、電話帳の参照可否が端末２の通信環境に依存してしまうことになる。一方、電話帳の同期を行う場合、端末２の中に電話帳が保存されることから、電話帳の参照可否が端末２の通信環境に依存してしまうという問題を防止することが可能になる。

（電話帳の同期先について）
これまでに説明した処理手順では、サーバ１で管理される電話帳は、端末２の電話帳管理ＡＰＬ２０で管理される電話帳と同期される前提であった。しかしながら、端末２の利用形態によっては、更なる利便性を確保したい場合や、セキュリティを更に高めたい場合や、サーバ１及び端末２間の通信頻度／通信量を考慮したい場合などが想定される。そこで、図５に示すように、端末２の判定部２０４は、サーバ１から取得した電話帳を、電話帳管理ＡＰＬ２０で管理される電話帳と同期させるか（図５（ａ））、標準電話帳ＡＰＬ４０で管理される電話帳と同期させるか（図５（ｂ））、又は、いずれの電話帳とも同期させないか（図５（ｃ））を、"所定の条件"に基づいて判定し、同期部２０３は、判定結果に従って同期処理を行うようにしてもよい。例えば、標準電話帳ＡＰＬ４０で管理される電話帳と同期させる場合、マルウェアによる情報漏えいリスクは高まるものの、他のＡＰＬ（例えばＳＮＳのＡＰＬなど）から電話帳にアクセスすることができるため、ユーザの利便性を高めることができる。また、いずれの電話帳とも同期させない場合、万が一ユーザが端末２を紛失したとしても、端末２の取得者に電話帳を参照されるリスクを排除することが可能になる。なお、いずれの電話帳とも同期させない場合、図４のステップＳ１０３の処理手順において、電話帳管理ＡＰＬ２０の通知部２０２は、標準通話ＡＰＬ３０から着信があったこと及び発信元電話番号の通知を受ける度にサーバ１に発信元ユーザ名を問い合わせることになる。以下、判定部２０４が同期先を判定する際の"所定の条件"の具体例について説明する。なお、判定部２０４は、以下に示す具体例のうち複数を組み合わせることで同期先を判定するようにしてもよい。

［所定の条件の具体例（その１）］
"所定の条件"は、端末２に登録されているユーザのスケジュール情報又はＯＳ５０で把握される移動先（例えば海外ローミング中である等）に基づく条件であってもよい。例えば、移動先が海外である場合、判定部２０４は、着信の度にサーバ１から電話帳の取得が行われることによる海外ローミング料金が高額になる可能性を考慮し、電話帳管理ＡＰＬ２０で管理される電話帳、又は、標準電話帳ＡＰＬ４０で管理される電話帳と同期すべきと判定するようにしてもよい。また、移動先が海外である場合、ユーザが端末２を紛失した場合に発見が困難である可能性が高い。そのため、判定部２０４は、取得者に電話帳を参照されるリスクと海外ローミング料金が高額になる可能性の両方を考慮し、電話帳管理ＡＰＬ２０で管理される電話帳と同期すべきであると判定するようにしてもよい。

［所定の条件の具体例（その２）］
"所定の条件"は、端末２に特定のＡＰＬ（例えばＳＮＳのＡＰＬ）がインストールされているか否かであってもよい。特定のＡＰＬがインストールされている場合、判定部２０４は、特定のＡＰＬから電話帳の参照が可能になることによるユーザの利便性向上を考慮し、標準電話帳ＡＰＬ４０で管理される電話帳と同期すべきと判定するようにしてもよい。一方、特定のＡＰＬがインストールされていない場合、判定部２０４は、電話帳管理ＡＰＬ２０で管理される電話帳と同期すべきと判定するようにしてもよい。なお、判定部２０４は、特定のＡＰＬがインストールされている場合であっても、当該特定のＡＰＬの利用頻度（例えば、起動回数、使用回数等）を取得し、利用頻度が低い場合（例えば、起動回数、使用回数等が所定の閾値以下の場合）は、電話帳管理ＡＰＬ２０で管理される電話帳と同期すべきと判定するようにしてもよい。

［所定の条件の具体例（その３）］
"所定の条件"は、端末２に設定されているセキュリティレベルであってもよい。例えば、セキュリティレベルが３段階であると仮定した場合、判定部２０４は、セキュリティレベルが低く設定されている場合に、標準電話帳ＡＰＬ４０で管理される電話帳と同期すべきと判定し、セキュリティレベルが中に設定されている場合に、電話帳管理ＡＰＬ２０で管理される電話帳と同期すべきと判定し、セキュリティレベルが高に設定されている場合に、いずれの電話帳とも同期を行うべきではないと判定するようにしてもよい。

［所定の条件の具体例（その４）］
"所定の条件"は、端末２を利用するユーザの属性（業種など）に基づく条件であってもよい。また、端末２を利用するユーザの属性と同期先との対応づけは、予め端末２内に格納された設定ファイルで示されていてもよい。また、端末２を利用するユーザの属性は、任意のタイミングでサーバ１から端末２に通知されるようにしてもよいし、ユーザにより端末２に入力されてもよい。判定部２０４は、サーバ１から通知された（又は端末２に入力された）ユーザの属性と設定ファイルとを比較することで、ユーザの属性に対応する同期先と同期すべきと判定することになる。

［所定の条件の具体例（その５）］
"所定の条件"はユーザに指示された同期先であってもよい。つまり、判定部２０４は、端末２のユーザに指示された同期先と同期すべきと判定するようにしてもよい。

以上説明した同期先の判定方法によれば、端末２の利用形態に応じて適切な同期先を選択することが可能になる。なお、前述した「（電話帳の同期処理について）」で説明した同期処理を、以上説明した同期先の判定方法で判定された同期先との同期処理に適用することも可能である。

＜＜第二の実施の形態＞＞
第二の実施の形態では、標準通話ＡＰＬ３０は、第一の実施の形態のように、着信を受けたこと及び発信元電話番号を他のＡＰＬに通知するＡＰＩと、発信元ユーザ名を他のＡＰＬから受け取るＡＰＩとを備えていない。その代りとして、標準電話帳ＡＰＬ４０は、上述の電話帳に加えて、他のＡＰＬから書込みのみが可能な電話帳（以下、「秘匿電話帳」と称する）を記憶領域に格納する機能を備えている。秘匿電話帳は、標準通話ＡＰＬ３０及び標準電話帳ＡＰＬ４０のみが参照可能であり、他のＡＰＬには参照権限が与えられていない。標準通話ＡＰＬ３０は、着信を受けると、発信元電話番号に対応する発信元ユーザ名が電話帳又は秘匿電話帳に格納されているかを検索し、発信元ユーザ名が検索された場合、発信元ユーザ名を着信画面に表示する機能を備えている。

電話帳管理ＡＰＬ２０は、サーバ１で管理されている電話帳の全部又は一部を、秘匿電話帳と同期するように動作する。これにより、発信元電話番号を端末２のディスプレイに表示することができ、電話帳に含まれる個人情報がマルウェア等を介して外部に漏洩することを防止しつつ、利用者の利便性を確保することが可能になる。

＜機能構成＞
第二の実施の形態に係るサーバの機能構成は、第一の実施の形態と同一であるため説明は省略する。

（端末）
図６は、第二の実施の形態に係る端末の機能構成例を示す図である。電話帳管理ＡＰＬ２０は、同期部２０３と、判定部２０４と、記憶部２０５とを有する。標準通話ＡＰＬ３０は、発着信処理部３０１と、表示部３０４とを有する。また、標準電話帳ＡＰＬ４０は、電話帳を格納可能な記憶部４０１を有する。なお、第二の実施の形態では、電話帳管理ＡＰＬ２０と標準通話ＡＰＬ３０とは直接通信しないことから、第一の実施の形態に係る電話帳管理ＡＰＬ２０が備える受付部２０１と通知部２０２と、第一の実施の形態に係る標準通話ＡＰＬ３０が備える通知部３０２と取得部３０３とを有していなくてもよい。

同期部２０３は、サーバ１に記憶される電話帳の全部又は一部と、標準電話帳ＡＰＬ４０で管理される秘匿電話帳との同期を行う機能を有する。また、同期部２０３は、サーバ１に記憶される電話帳の全部又は一部と、電話帳管理ＡＰＬ２０で管理される電話帳及び標準電話帳ＡＰＬ４０で管理される秘匿電話帳との同期を行うようにしてもよい。また、同期部２０３は、サーバ１に記憶される電話帳の全部又は一部と、標準電話帳ＡＰＬ４０で管理される電話帳との同期を行うようにしてもよい。

また、同期部２０３は、サーバ１に記憶される電話帳のうち、利用頻度が高い候補の順に所定の件数の電話帳、又は事前に同期対象として設定されている所定の件数の電話帳を取得し、各種の電話帳（電話帳管理ＡＰＬ２０で管理される電話帳、標準電話帳ＡＰＬ４０で管理される電話帳）と同期する機能を有していてもよい。また、同期部２０３は、サーバ１に記憶される電話帳の全部又は一部を、判定部２０４で判定された同期先の電話帳と同期させるようにしてもよい。

判定部２０４は、サーバ１から取得した電話帳を、標準電話帳ＡＰＬ４０が管理する秘匿電話帳と同期させるか、電話帳管理ＡＰＬ２０で管理される電話帳及び標準電話帳ＡＰＬ４０で管理される秘匿電話帳と同期させるか、又は、標準電話帳ＡＰＬ４０が管理する電話帳と同期させるかを、所定の条件に基づいて判定する機能を有する。記憶部２０５は、電話帳を、電話帳管理ＡＰＬ２０のみから参照可能な記憶領域に記憶する機能を有する。

発着信処理部３０１は、ＯＳ５０と連携し、通話の発信及び着信に関する処理を行う機能を有する。表示部３０４は、発信元電話番号をキーに秘匿電話帳を検索することで発信元ユーザ名を取得し、取得した発信元ユーザ名を端末２が備えるディスプレイ等に表示する機能を有する。記憶部４０１は、標準電話帳ＡＰＬ４０及び標準通話ＡＰＬ３０のみから参照可能な電話帳を記憶する機能を有する。

なお、判定部２０４をサーバ１に配置するようにしてもよい。この場合、端末２の同期部２０３は、サーバ１に配置された判定部で判定された同期先の電話帳と同期を行う。

＜処理手順＞
続いて、第二の実施の形態に係る端末２が行う動作について、図を参照しつつ説明する。

（発信元のユーザ名の表示について）
第二の実施の形態の場合、発信元のユーザ名の表示は、秘匿電話帳に格納されたレコードを用いて標準通話ＡＰＬ３０と標準電話帳ＡＰＬ４０とが連携して行う。まず、標準通話ＡＰＬ３０の発着信処理部３０１は、ＯＳ５０から、着信を受けたこと及び発信元の電話番号を受け付ける。続いて、標準通話ＡＰＬ３０の表示部３０４は、発信元電話番号をキーに秘匿電話帳を検索することで発信元ユーザ名を取得し、取得した発信元ユーザ名を端末２が備えるディスプレイ等に表示させる。

（電話帳の同期処理について）
電話帳の同期処理は、第一の実施の形態における「（電話帳の同期処理について）」で説明した動作において、"電話帳管理ＡＰＬ２０で管理される電話帳"を、"標準電話帳ＡＰＬ４０で管理される秘匿電話帳"、"電話帳管理ＡＰＬ２０で管理される電話帳及び標準電話帳ＡＰＬ４０で管理される秘匿電話帳"又は、"標準電話帳ＡＰＬ４０で管理される電話帳"に置き換えた動作と同一であるため説明は省略する。

（電話帳の同期先について）
端末２の判定部２０４は、サーバ１から取得した電話帳を、標準電話帳ＡＰＬ４０が管理する秘匿電話帳と同期させるか（図７（ａ））、電話帳管理ＡＰＬ２０で管理される電話帳及び標準電話帳ＡＰＬ４０で管理される秘匿電話帳と同期させるか（図７（ｂ））、又は、標準電話帳ＡＰＬ４０で管理される電話帳と同期させるか（図７（ｃ））を、"所定の条件"に基づいて判定し、同期部２０３は、判定結果に従って同期処理を行うようにしてもよい。

以下、判定部２０４が同期先を判定する際の"所定の条件"の具体例について説明する。なお、判定部２０４は、以下に示す具体例のうち複数を組み合わせることで同期先を判定するようにしてもよい。

［所定の条件の具体例（その１）］
"所定の条件"は、端末２に登録されているユーザのスケジュール情報又はＯＳ５０で把握される移動先（例えば海外ローミング中である等）に基づく条件であってもよい。例えば、移動先が海外である場合、ユーザが端末２を紛失した場合に発見が困難である可能性が高い。そのため、判定部２０４は、取得者に電話帳を参照されるリスクを考慮し、標準電話帳ＡＰＬ４０で管理される秘匿電話帳、又は、電話帳管理ＡＰＬ２０で管理される電話帳及び標準電話帳ＡＰＬ４０で管理される秘匿電話帳と同期すべきと判定するようにしてもよい。

［所定の条件の具体例（その２）］
"所定の条件"は、端末２に特定のＡＰＬ（例えばＳＮＳのＡＰＬ）がインストールされているか否かであってもよい。特定のＡＰＬがインストールされている場合、判定部２０４は、特定のＡＰＬから電話帳の参照が可能になることによるユーザの利便性向上を考慮し、標準電話帳ＡＰＬ４０で管理される電話帳と同期すべきと判定するようにしてもよい。一方、特定のＡＰＬがインストールされていない場合、判定部２０４は、標準電話帳ＡＰＬ４０で管理される秘匿電話帳、又は、電話帳管理ＡＰＬ２０で管理される電話帳及び標準電話帳ＡＰＬ４０で管理される秘匿電話帳と同期すべきと判定するようにしてもよい。なお、判定部２０４は、特定のＡＰＬがインストールされている場合であっても、当該特定のＡＰＬの利用頻度（例えば、起動回数、使用回数等）を取得し、利用頻度が低い場合（例えば、起動回数、使用回数等が所定の閾値以下の場合）は、標準電話帳ＡＰＬ４０で管理される秘匿電話帳、又は、電話帳管理ＡＰＬ２０で管理される電話帳及び標準電話帳ＡＰＬ４０で管理される秘匿電話帳と同期すべきと判定するようにしてもよい。

［所定の条件の具体例（その３）］
"所定の条件"は、端末２に設定されているセキュリティレベルであってもよい。例えば、セキュリティレベルが３段階であると仮定した場合、判定部２０４は、セキュリティレベルが低く設定されている場合に、標準電話帳ＡＰＬ４０で管理される電話帳と同期すべきと判定し、セキュリティレベルが中に設定されている場合に、電話帳管理ＡＰＬ２０で管理される電話帳及び標準電話帳ＡＰＬ４０で管理される秘匿電話帳と同期すべきと判定し、セキュリティレベルが高に設定されている場合に、標準電話帳ＡＰＬ４０で管理される秘匿電話帳と同期すべきと判定するようにしてもよい。

［所定の条件の具体例（その４）］
所定の条件の具体例（その４）は、第一の実施の形態と同一であるため説明は省略する。

［所定の条件の具体例（その５）］
所定の条件の具体例（その５）は、第一の実施の形態と同一であるため説明は省略する。

［所定の条件の具体例（その６）］
"所定の条件"は、電話帳のバックアップの必要性であってもよい。判定部２０４は、端末２の中で電話帳のバックアップが必要である場合、電話帳管理ＡＰＬ２０で管理される電話帳及び標準電話帳ＡＰＬ４０で管理される秘匿電話帳と同期すべきと判定し、端末２の中で電話帳のバックアップが必要ではない場合、標準電話帳ＡＰＬ４０で管理される秘匿電話帳と同期すべきと判定するようにしてもよい。

以上説明した同期先の判定方法によれば、端末２の利用形態に応じて適切な同期先を選択することが可能になる。

＜＜実施形態の補足＞＞
各実施の形態において、標準通話ＡＰＬ３０と標準電話帳ＡＰＬ４０とは別個のＡＰＬである前提で説明したが、標準通話ＡＰＬ３０及び標準電話帳ＡＰＬ４０が備える各種機能は、モバイルＯＳの仕様により、どのような実装方法で提供されていてもよい。例えば、標準電話帳ＡＰＬ４０は標準通話ＡＰＬ３０の一部であってもよい。すなわち、標準電話帳ＡＰＬ４０が備える各種機能は、標準通話ＡＰＬ３０が備える機能として提供されていてもよい。また、標準通話ＡＰＬ３０及び標準電話帳ＡＰＬ４０はＯＳ５０の一部であってもよい。すなわち、標準通話ＡＰＬ３０及び標準電話帳ＡＰＬ４０が備える各種機能はＯＳ５０が備える機能として提供されていてもよい。

また、各実施の形態において、標準通話ＡＰＬ３０及び標準電話帳ＡＰＬ４０の各々がＡＰＩを提供している前提で説明したが、これらのＡＰＩは、モバイルＯＳの仕様により、どのような実装方法で提供されていてもよい。例えば、各実施の形態において標準通話ＡＰＬ３０及び標準電話帳ＡＰＬ４０の各々が提供するとして説明したＡＰＩは、ＯＳ５０により提供されていてもよい。

電話帳管理ＡＰＬ２０は、第一の実施の形態及び第二の実施の形態の両方を実行可能であってもよい。すなわち、電話帳管理ＡＰＬ２０は、第一の実施の形態で説明した機能構成と、第二の実施の形態で説明した機能構成との両方の機能構成を備えていてもよい。また、端末２は、第一の実施の形態及び第二の実施の形態の両方を実行可能であってもよい。すなわち、端末２は、第一の実施の形態で説明した機能構成と、第二の実施の形態で説明した機能構成との両方の機能構成を備えていてもよい。

第二の実施の形態において、電話帳管理ＡＰＬ２０は、電話帳を管理せずに、主に同期処理のみを行うＡＰＬであってもよい。すなわち、電話帳管理ＡＰＬ２０には記憶部２０５が含まれていなくてもよい。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。実施の形態で述べたシーケンスは、矛盾の無い限り順序を入れ替えてもよい。

以上、実施の形態に係るサーバ１及び端末２が有する各機能部は、これらが備えるＣＰＵ及びメモリなどのハードウェア資源を用いて、サーバ１及び端末２の各々で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、当該プログラムは、記憶媒体に格納することができる。

１ サーバ
２ 端末
２０ 電話帳管理ＡＰＬ
３０ 標準通話ＡＰＬ
４０ 標準電話帳ＡＰＬ
５０ ＯＳ
１０１ 通信部
１０２ 記憶部
１０３ 同期部
２０１ 受付部
２０２ 通知部
２０３ 同期部
２０４ 判定部
２０５ 記憶部
３０１ 発着信処理部
３０２ 通知部
３０３ 取得部
３０４ 表示部
４０１ 記憶部
５０１ 通信部

Claims (6)

1. ＯＳベンダにより提供される第一のアプリケーションと、第三者により提供される第二のアプリケーションとがインストールされた端末であって、
   前記第一のアプリケーションは、
   着信を受けたこと及び発信元電話番号を前記第二のアプリケーションに通知する着信通知手段と、
   前記第二のアプリケーションから、発信元ユーザ名を取得する取得手段と、
   取得された前記発信元ユーザ名を表示する表示手段と、
   を有し、
   前記第二のアプリケーションは、
   電話帳を、当該端末のＯＳにおいて前記第二のアプリケーションのみから参照可能な記憶領域に記憶する記憶手段と、
   前記第一のアプリケーションから、電話の着信を受けたこと及び発信元電話番号の通知を受け付ける受付手段と、
   前記第一のアプリケーションから、着信を受けたこと及び発信元電話番号の通知を受け付けた場合に、前記電話帳から発信元電話番号に対応する発信元ユーザ名を取得して前記第一のアプリケーションに通知するユーザ名通知手段と、
   を有する端末。
2. 前記第二のアプリケーションは、
   当該端末と通信可能なサーバに記憶される電話帳のうち、利用頻度が高い候補の順に所定の件数の電話帳、又は事前に同期対象として設定されている所定の件数の電話帳を取得し、前記記憶手段に記憶されている電話帳と同期させる同期手段、を有する、
   請求項１に記載の端末。
3. ＯＳベンダにより提供される第一のアプリケーションと、第三者により提供される第二のアプリケーションとがインストールされた端末であって、
   前記第一のアプリケーションは、
   前記第一のアプリケーションのみから参照可能な電話帳を記憶する記憶手段と、
   着信を受けた場合に、前記電話帳から発信元ユーザ名を取得して表示する表示手段と、
   を有し、
   前記第二のアプリケーションは、
   当該端末と通信可能なサーバに記憶される電話帳の全部又は一部を、前記記憶手段に記憶されている電話帳に書き込む書込手段、
   を有する端末。
4. ＯＳベンダにより提供される第一のアプリケーションと、第三者により提供される第二のアプリケーションとがインストールされた端末が実行する方法であって、
   前記第一のアプリケーションが、着信を受けたこと及び発信元電話番号を前記第二のアプリケーションに通知するステップと、
   前記第二のアプリケーションが、前記第一のアプリケーションから、着信を受けたこと及び発信元電話番号の通知を受け付けた場合に、当該端末のＯＳにおいて前記第二のアプリケーションのみから参照可能な記憶領域に記憶されている電話帳から、前記発信元電話番号に対応する発信元ユーザ名を取得して前記第一のアプリケーションに通知するステップと、
   前記第一のアプリケーションが、前記第二のアプリケーションから、前記発信元ユーザ名を取得するステップと、
   前記第一のアプリケーションが、前記発信元ユーザ名を表示するステップと、
   を有する方法。
5. ＯＳベンダにより提供されるアプリケーションがインストールされた端末に実行させるプログラムであって、
   前記アプリケーションから、電話の着信を受けたこと及び発信元電話番号の通知を受け付けるステップと、
   前記アプリケーションから、着信を受けたこと及び発信元電話番号の通知を受け付けた場合に、前記端末のＯＳにおいて当該プログラムのみから参照可能な記憶領域に記憶されている電話帳から、前記発信元電話番号に対応する発信元ユーザ名を取得して前記アプリケーションに通知するステップと、
   を有するプログラム。
6. ＯＳベンダにより提供されるアプリケーションがインストールされた端末に実行させるプログラムであって、
   前記端末と通信可能なサーバに記憶される電話帳を、前記アプリケーションのみから参照可能な電話帳と同期させるか、当該プログラムのみから参照可能な電話帳及び前記アプリケーションのみから参照可能な電話帳と同期させるか、又は、任意のアプリケーションから参照可能な電話帳と同期させるかを判定するステップと、
   前記アプリケーションのみから参照可能な電話帳と同期させると判定された場合に、前記サーバに記憶される電話帳と前記アプリケーションのみから参照可能な電話帳とを同期させ、当該プログラムのみから参照可能な電話帳及び前記アプリケーションのみから参照可能な電話帳と同期させると判定された場合に、前記サーバに記憶される電話帳と当該プログラムのみから参照可能な電話帳及び前記アプリケーションのみから参照可能な電話帳とを同期させ、任意のアプリケーションから参照可能な電話帳と同期させると判定された場合に、前記サーバに記憶される電話帳と任意のアプリケーションから参照可能な電話帳とを同期させるステップと、
   を有するプログラム。

Images