(57)【要約】      （修正有）【課題】簡単かつ効率的な機構で、同時に共通のコアソフトウェアスタックと通信することができる電子機器の提供。【解決手段】ＩＰ（インターネットプロトコル）通信のための電子機器は、メモリ、ＡＰＩ（アプリケーション・プログラミング・インターフェース）、複数のコアソフトウェアスタック、及びプロセッサを備える。メモリは、複数のアプリケーションのデータを格納するために使用される。ＡＰＩは複数のユーザーコマンドを受信するために使用される。複数のＡＰＩの各ＡＰＩは、複数のアプリケーションの１つのアプリケーションに対応する。コアソフトウェアスタックは、メモリに格納されおり、複数のＡＰＩによってアクセス可能である。プロセッサは、メモリに結合されており、複数のユーザーコマンドに応じて、コアソフトウェアスタックと複数のＡＰＩとの間でデータをアクセスするために使用される。【選択図】図２
2016081535.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰ（インターネットプロトコル）通信のための電子機器であって、
複数のアプリケーションのデータを格納するように構成されるメモリと、
複数のユーザーコマンドを受信するように構成され、各アプリケーション・プログラミング・インターフェースが複数のアプリケーションのうちの１つと対応している、複数のアプリケーション・プログラミング・インターフェースと、
前記メモリに格納される、前記複数のアプリケーション・プログラミング・インターフェースによってアクセス可能である、コアソフトウェアスタックと、
前記メモリに結合されており、前記複数のユーザーコマンドに応じて、前記コアソフトウェアスタックと前記複数のアプリケーション・プログラミング・インターフェースとの間でデータをアクセスするように構成されている、プロセッサと、備える、
電子機器。
【請求項２】
前記複数のアプリケーション・プログラミング・インターフェースの各アプリケーション・プログラミング・インタフェースは、対応するアプリケーションと前記コアソフトウェアスタックとの間で通信する共有メモリ機構を使用する、
請求項１に記載の電子機器。
【請求項３】
前記コアソフトウェアスタックは複数のプロトコルを管理するように構成されている、
請求項１に記載の電子機器。
【請求項４】
前記複数のアプリケーション・プログラミング・インターフェースへ入力された前記複数のユーザーコマンドは、異なる複数のスレッドによって分離されるコマンドキューとして、前記コアソフトウェアスタックへ送信される、
請求項１に記載の電子機器。
【請求項５】
前記複数のアプリケーション・プログラミング・インターフェースへ入力された前記複数のユーザーコマンドは、異なる複数のスレッドによって分離されるコマンドパイプとして、前記コアソフトウェアスタックへ送信される、
請求項１に記載の電子機器。
【請求項６】
前記コアソフトウェアスタックのデータは、異なる複数のスレッドによって分離されるイベントキューとして、前記複数のアプリケーション・プログラミング・インターフェースへ送信される、
請求項１に記載の電子機器。
【請求項７】
前記コアソフトウェアスタックのデータは、異なる複数のスレッドによって分離されるイベントパイプとして、前記複数のアプリケーション・プログラミング・インターフェースへ送信される、
請求項１に記載の電子機器。
【請求項８】
前記複数のアプリケーション・プログラミング・インターフェースの各アプリケーション・プログラミング・インタフェースは、対応するアプリケーションと前記コアソフトウェアスタックとの間で通信するAndroid・プロセス間通信（ＩＰＣ）機構を使用する、
請求項１に記載の電子機器。
【請求項９】
前記複数のアプリケーションは、前記コアソフトウェアスタックと通信するために、Android・binderを使用する、
請求項１に記載の電子機器。
【請求項１０】
前記Android・binderは、Androidインターフェース定義言語（ＡＩＤＬ）によって定義される、
請求項９に記載の電子機器。
【請求項１１】
コマンド制御用のAndroidインターフェース定義言語（ＡＩＤＬ）で定義され、及びコールバック制御用の他のAndroidインターフェース定義言語によって定義される、コアソフトウェアインタフェースを備える、
請求項１０に記載の電子機器。
【請求項１２】
前記複数のアプリケーション・プログラミング・インターフェースの各アプリケーション・プログラミング・インタフェースは、対応するアプリケーションと前記コアソフトウェアスタックと間で通信する、コアソフトウェアインタフェースを使用する、
請求項１に記載の電子機器。
【請求項１３】
前記複数のアプリケーション・プログラミング・インターフェースの各アプリケーション・プログラミング・インタフェースは、対応するアプリケーションと前記コアソフトウェアスタックとの間で通信する、オペレーションシステム（ＯＳ）に固有の機構を使用する、
請求項１に記載の電子機器。
【請求項１４】
前記オペレーションシステムに固有の機構は、ソケット・システム又は遠隔手続呼出し（ＲＰＣ）システムである、
請求項１３に記載の電子機器。
【請求項１５】
前記複数のアプリケーション・プログラミング・インターフェースの各アプリケーション・プログラミング・インタフェースは、オペレーションシステムに固有の機構を使用することで、別のアプリケーション・プログラミング・インタフェースと、複数のデータを共有する、
請求項１に記載の電子機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２０１４年１０月１７日に出願された米国仮出願６２／０６５，１５の利益を主張する。
【０００２】
本発明は、ＩＰ（インターネットプロトコル）通信のための電子機器、詳しくは、複数のアプリケーションにアクセスするための共通のコアソフトウェアスタックを備える電子機器に関する。
【背景技術】
【０００３】
技術の進歩により、アプリケーション・プログラミング・インタフェース（ＡＰＩ（ｓ））と組み合わせる、多機能なアプリケーションを備える、複数の電子機器が、リッチコミュニケーションサービス（ＲＣＳ）のようなＩＰ（インターネットプロトコル）通信のために採用されている。具体的には、相手先商標製品の製造会社（ＯＥＭ）又はそのパートナーは、開発のために、単一のインターフェース上でいくつかのＡＰＩを統合し、標準化することを望んでいる。対照的に、開発者（つまり、第三者の開発者）向けに、オペレーターが、異なるＡＰＩが必要であることがある。
【０００４】
このように、ＡＰＩのサポート性及び互換性の問題が、アプリケーション開発者、ＯＥＭの電子機器（すなわち、携帯機器）、及びＯＥＭのミドルウェア・サプライヤー間に存在することがある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一般的に、この問題を解決するためのいくつかの典型的なアプローチを以下に示す。
（Ａ）第１のアプローチでは、各ＡＰＩのために独立して夫々のアプリケーションを構築する。異なるＡＰＩは、いくつかの共通のコードを共有することがある。ＯＥＭは、１つずつが各コアスタックのための、複数のアプリケーションのサポート性を備える開発品を製造する必要がある。そうすることで、異なる開発者の努力を必要となり、異なるアプリケーションが非効率になる。
（Ｂ）第２のアプローチでは、ソフトウェアスタックにおける通信の階層を特定した後、一のＡＰＩは、適宜相互に交換することができる。そうすることで、開発は、ＡＰＩの代替的な取り替え動作を使用することで、コアスタックを維持することができる。
（Ｃ）第３のアプローチでは、上位セットのＡＰＩ（すなわち、主要な機能のＡＰＩ）を構築する。このアプローチでは、上位セットのＡＰＩに、各カスタムＡＰＩを変換するために、スリムな層が最上層に構築されている。そうすることで、上位セットのＡＰＩの有用性により、干渉リスク、製造コストを低減することができる。しかし、これだと、ソフトウェアのメモリの設置面積領域が増加してしまう。
【０００６】
そこで、本発明は上記事情に鑑み、簡単かつ効率的な機構で、同時に共通のコアソフトウェアスタックと通信することができる電子機器の提供を目的とする。
【課題を解決するための手段】
【０００７】
本発明の実施形態において、ＩＰ（インターネットプロトコル）通信のための電子機器が開示されている。電子機器は、メモリ、アプリケーション・プログラミング・インターフェースは、複数のコアソフトウェアスタック、及びプロセッサを備える。メモリは、複数のアプリケーションのデータを格納するために使用される。アプリケーション・プログラミング・インターフェースは複数のユーザーコマンドを受信するために使用される。複数のアプリケーション・プログラミング・インターフェースの各アプリケーション・プログラミング・インタフェースは、複数のアプリケーションの１つのアプリケーションに対応する。コアソフトウェアスタックは、メモリに格納されおり、複数のアプリケーション・プログラミング・インターフェースによってアクセス可能である。プロセッサは、メモリに結合されており、複数のユーザーコマンドに応じて、コアソフトウェアスタックと複数のアプリケーション・プログラミング・インターフェースとの間でデータをアクセスするために使用される。
【発明の効果】
【０００８】
一態様によれば、本発明の一実施形態の電子機器は、簡単かつ効率的な機構で、同時に共通のコアソフトウェアスタックと通信することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態に係る電子機器のブロック図を示す。
【図２】図１の電子機器の単一のアプリケーション・アーキテクチャを示す。
【図３】図１の電子機器のマルチヘッドスタックのアプリケーション・アーキテクチャを示す。
【図４】図１の電子機器の単一のアプリケーション・アーキテクチャに適用される第１の通信方式を示す
【図５】図１の電子機器のマルチヘッドスタックのアプリケーション・アーキテクチャに適用される第１の通信方式を示す。
【図６】図１の電子機器の単一のアプリケーション・アーキテクチャに適用される第２の通信方式を示す。
【図７】図１の電子機器のマルチヘッドスタックのアプリケーション・アーキテクチャに適用される第２の通信方式を示す。
【図８】図１の電子機器のAndroid（登録商標）のオペレーションシステム下の第１のマルチヘッドスタックのアプリケーション・アーキテクチャを示す。
【図９】図１の電子機器のAndroidのオペレーションシステム下で第２のマルチヘッドスタックのアプリケーション・アーキテクチャを示す。
【発明を実施するための形態】
【００１０】
図１は、本発明の実施形態に係る電子機器１００のブロック図を示す。図１に示すように、電子機器１００は、メモリ１０、プロセッサ１１、及びインターフェース部１２を備える。
【００１１】
メモリ１０は、複数のアプリケーションのデータを格納するために使用される。
本実施形態では、メモリ１０は任意のタイプのハードウェアとすることができる。例えば、メモリ１０は、ハードディスク、フラッシュメモリ又はランダムアクセスメモリで有り得る。複数のアプリケーションは、Android（登録商標）のオペレーションシステム又はＩＯＳ（登録商標）のように、１つ以上の特定のオペレーションシステムと互換性を有する、１つの機能又は多機能のアプリケーション・プログラムであることができる。
プロセッサ１１は、論理ユニット、ＣＰＵ、ＭＣＵ、又は任意のプログラム可能なチップで有り得る。
【００１２】
インターフェース部１２は、表示する又は複数のユーザーコマンドを受信するための、複数のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を、表示する又は存在させることができる。例えば、インターフェース部１２は、携帯電話のタッチスクリーンで有り得る。具体的には、複数のアプリケーション・プログラミング・インターフェースの各アプリケーション・プログラミング・インタフェースは、複数のアプリケーションの１つのアプリケーションに対応する。本実施形態では、共通のコアソフトウェアスタックに対応する複数のＡＰＩのデータは、メモリ１０に格納される。コアソフトウェアスタックは、複数のＡＰＩによってアクセス可能である。
【００１３】
プロセッサ１１はメモリ１０に結合されており、複数のユーザーコマンドに応じて、コアソフトウェアスタックと複数のＡＰＩとの間で、データをアクセスする（やりとりする）及び通信するために使用される。言い換えると、電子機器１００における複数のアプリケーションは、複数のＡＰＩと通信するために、同じ（共通の）コアソフトウェアスタックを使用することができる。
【００１４】
電子機器１００は、ＩＰ（インターネットプロトコル）通信に適用され得る。
通信のアプリケーション・アーキテクチャ（構成）の定義、データ（即ち、コマンド及びイベント）通信の方式を以下に示す。
【００１５】
図２は、電子機器１００の単一のアプリケーション・アーキテクチャを示す。図２において、４つの階層が、アプリケーション・アーキテクチャ内に示されている。
【００１６】
プロトコル１６の層において、伝送制御プロトコル、インターネットプロトコル、または無線ネットワークプロトコルが、基本的な通信言語として定義される。コアソフトウェアスタック１５の層は、プロトコル１６を管理するためのアプリケーション１３のコアプログラミングソフトウェアとみなすことができる。
【００１７】
アプリケーション・プログラミング・インターフェース（ＡＰＩ（ｓ））１４は、アプリケーション１３の一つ以上の機能に応じて、確立される。具体的には、ＡＰＩ１４は、複数のユーザーコマンドを受信するために使用されることで、コアソフトウェアスタック１５と通信することができる。
【００１８】
アプリケーション１３の層は、アプリケーション・アーキテクチャの最上層である。本実施形態では、アプリケーションとＡＰＩとの間の相関は、単射（即ち、１対１のマッピング）である。上位セット（ｓｕｐｅｒｓｅｔ）のＡＰＩを使用しないようにするには、ユーザーは、異なるアプリケーションに関連付けられている異なるＡＰＩに複数のユーザーコマンドを入力することができ、これが、高い動作利便性と作業効率につながる。
下記、電子機器上で複数のアプリケーションを備えるアーキテクチャを示す。
【００１９】
図３は、電子機器１００のマルチヘッドスタックのアプリケーション・アーキテクチャを示す。表示を簡単にするために、２つのアプリケーションがマルチヘッドスタックアプリケーションを表すために導入されている。
【００２０】
図３では、アプリケーション１３ａはＡＰＩ１４ａに対応し、アプリケーション１３ｂはＡＰＩ１４ｂに対応する。ＡＰＩ１４ａとＡＰＩ１４ｂとは、２つの同一のＡＰＩまたは２つの別個のＡＰＩで有り得る。
【００２１】
具体的には、マルチヘッドスタックのアプリケーション・アーキテクチャの設計思想で、ＡＰＩ１４ａとＡＰＩ１４ｂとの両方が同じ（共通）コアソフトウェアスタック１５と通信できる。言い換えると、アプリケーション１３ａ、１３ｂは、コアソフトウェアスタック１５に、特定の動作を実行するように、対応するＡＰＩを介して、命令することができる。
【００２２】
特定の動作とは、メッセージの送信動作や（特定のアドレスへの）ファイル伝送動作で有り得る。本実施形態では、イベント及びコマンドは、複数のＡＰＩ（１４）と、コアソフトウェアスタック１５との間の２つの通信データの種類とみなされる。
イベント及びコマンドの定義、アプリケーション・アーキテクチャの通信方法を以下に示す。
【００２３】
図４は、電子機器１００の単一のアプリケーション・アーキテクチャに適用される第１の通信方式を示す。ＡＰＩ１４は、ユーザーコマンドを受信し、ユーザーコマンドをコアソフトウェアスタック１５へ送信した後、コアソフトウェアスタック１５がユーザーコマンドを受信し、イベントを（プロセッサ１１によって）ＡＰＩ１４へ適宜出力する。
【００２４】
具体的には、イベントは、任意の、レポート、フィードバックデータ、要求、又は応答データとし得る。例えば、イベントは、アプリケーション動作の状態（即ち、メッセージが配信されたか）、又は、アプリケーション１３のために意図される迷惑イベント（即ち、アドレスから受信したファイル転送のための要求）とすることができる。
【００２５】
ＡＰＩ１４は、コアソフトウェアスタック１５で使用するコマンド及びイベントを、アプリケーション１３によって識別されるインターフェースへ、変換する（翻訳：translate）か、コンパイル（編集する：compile）することができる。
【００２６】
図４では、ＡＰＩ１４によって受信されたユーザーコマンドは、異なる複数のスレッドによって分離されるコマンドキューＣＱとして、コアソフトウェアスタック１５へ送信することができる。多くのコマンドがコマンドキューＣＱにバッファリングされているとき、コマンドキューＣＱは、先入れ先出し（ＦＩＦＯ）処理を実行する。
【００２７】
同様に、コアソフトウェアスタック１５のイベントは、異なる複数のスレッドによって分離されるイベントキューＥＱとして、ＡＰＩ１４へ出力することができる。多くのイベントがイベントキューＥＱにバッファリングされているとき、イベントキューＥＱは、先入れ先出し（ＦＩＦＯ）処理を実行する。具体的に、本実施形態では、コアソフトウェアスタック１５は、アプリケーション１３とは分離したスレッド又はプロセスに属する（常駐する：reside）。
【００２８】
ここで、別のスレッドやプロセスは、電子機器１００のための任意の設計である。しかし、別のスレッド又はプロセスが導入される場合、アプリケーション１３が意図せずに他のアプリケーションと相互作用してしまうリスクを最小にすることができる。
【００２９】
別のスレッド又はプロセスがアプリケーション１３のために使用される場合、２つの本質的な要件が、次のことを満たしている必要がある。
（Ａ）  コアソフトウェアスタック１５は、サポートされている全てのＡＰＩに対する全てのコマンド及びイベントをサポートすることができなければならない。
（Ｂ）  ＡＰＩは、任意のアプリケーションからの簡単かつ容易にアクセスできる通信を容易にする必要がある。
【００３０】
図４で、スレッドベースの通信技術を使用した場合、メッセージキュー（即ち、イベントキューＥＱ及びコマンドキューＣＱ）などの共有メモリ機構を使用することによってと、異なる複数のスレッドが互いに通信することができる。簡単に言えば、コマンドを開始又は受信するために、アプリケーション１３は、ＡＰＩ１４を使用する。
【００３１】
ＡＰＩ１４は、コマンドをメッセージ（即ち、コマンドデータ）へ変換する（コンパイルする）。その後、メッセージ（コマンドデータ）は、コアソフトウェアスタック１５によってコマンドキューＣＱ上に配置され、処理される。
【００３２】
コアソフトウェアスタック１５がコマンドデータを受信した後、イベントがコアソフトウェアスタック１５にトリガーされるとき、メッセージ（イベントデータ）がコマンドキューＣＱ上に配置されることによって、コアソフトウェアスタック１５が、意図したアプリケーションを通知する。
【００３３】
最後に、ＡＰＩ１４は、メッセージ（イベントデータ）を受信し、メッセージ（イベントデータ）を処理し、イベントのアプリケーション１３へ通知する。
【００３４】
図５は、電子機器１００のマルチヘッドスタックのアプリケーション・アーキテクチャに適用される第１の通信方式を示す。表示を簡単にするために、２つのアプリケーション１３ａ及び１３ｂが、マルチヘッドスタックのアプリケーション・アーキテクチャを表すように導入されている。
【００３５】
図５に示すように、アプリケーション１３ａはＡＰＩ１４ａに対応し、アプリケーション１３ｂはＡＰＩ１４ｂに対応する。ＡＰＩ１４ａとＡＰＩ１４ｂとは、２つの同一のＡＰＩまたは２つの別個のＡＰＩで有り得る。
【００３６】
具体的に、各アプリケーションは、イベントキューの独自のセットに対応している。例えば、アプリケーション１３ａはイベントキューＥＱａに対応し、アプリケーション１３ｂはイベントキューＥＱｂに対応している。イベントキューＥＱａ及びＥＱｂのメッセージ処理方法は、図４中のイベントキューＥＱに類似しているため、ここでは説明しない。
【００３７】
通信効率を最適化するために、アプリケーション１３ａ及びアプリケーション１３ｂは、コマンドキューＣＱを共有することができる。
【００３８】
図４で述べたように、アプリケーション１３ａ及びアプリケーション１３ｂから多くのコマンドがコマンドキューＣＱにバッファリングされているとき、２つのアプリケーション１３ａ及びアプリケーション１３ｂによって共有される、コマンドキューＣＱは、先入れ先出し（ＦＩＦＯ）処理を実行する。
【００３９】
図６は、電子機器１００の単一のアプリケーション・アーキテクチャに適用される第２の通信方式を示す。図６に示すアプリケーション・アーキテクチャは、図４のアプリケーション・アーキテクチャに類似している。
【００４０】
違いは、コアソフトウェアスタック１５がアプリケーションから分離したスレッドのプロセスである場合、プロセス間通信（ＩＰＣ）機構を使用することができることである。ここでは、電子機器１００のオペレーションシステムは、遠隔手続呼出し（リモート・プロシージャ・コール：ＲＰＣ）を含むことができる、ＩＰＣ機構の範囲を提供する。ＩＰＣ機構は、パイプやソケットとして実際に適用される。
【００４１】
例えば、図４中のコマンドキューＣＱは、図６のコマンドパイプＣＰで置き換えられる。図４中のイベントキューＥＱは、図６のイベントパイプＥＰに置き換えられる。同様に、コマンドを開始し又は受信するために、アプリケーション１３は、ＡＰＩ１４を使用する。ＡＰＩ１４は、コマンドからメッセージ（即ち、コマンドデータ）へ変換する（コンパイルする）。その後、メッセージ（コマンドデータ）はコアソフトウェアスタック１５によって処理される。
【００４２】
コアソフトウェアスタック１５がコマンドデータを受信した後、イベントが、コアソフトウェアスタック１５においてトリガーされたときに、イベントパイプＥＱにメッセージ（イベントデータ）を配置することで、コアソフトウェアスタック１５は、意図するアプリケーション１３へ通知する。
【００４３】
最後に、ＡＰＩ１４は、メッセージ（イベントデータ）を受信し、メッセージ（イベントデータ）を処理し、イベントのアプリケーション１３へ通知する。
【００４４】
図７は、電子機器１００のマルチヘッドスタックのアプリケーション・アーキテクチャに適用される第２の通信方式を示す。表示を簡単にするため、２つのアプリケーション１３ａ及び１３ｂがマルチヘッドスタックのアプリケーション・アーキテクチャを表すために導入されている。
【００４５】
図７に示すように、アプリケーション１３ａはＡＰＩ１４ａに対応し、アプリケーション１３ｂはＡＰＩ１４ｂに対応している。ＡＰＩ１４ａとＡＰＩ１４ｂとは、２つの同一のＡＰＩまたは２つの別個のＡＰＩで有り得る。具体的には、各アプリケーションは、イベントパイプの独自のセットに対応している。例えば、アプリケーション１３ａはイベントパイプＥＰａに対応し、アプリケーション１３ｂはイベントパイプＥＰｂに対応している。通信効率を最適化するために、アプリケーション１３ａとアプリケーション１３ｂとは、コマンドパイプＣＰを共有することができる。
【００４６】
図６で述べたように、アプリケーション１３ａ及びアプリケーション１３ｂからの多くのコマンドがコマンドパイプＣＰにバッファリングされているとき、２つのアプリケーション１３ａ及び１３ｂで共有されるコマンドパイプＣＰは、データ・パイプ処理を実行する。
【００４７】
図８は、電子機器１００のAndroidのオペレーションシステム下の第１のマルチヘッドスタックのアプリケーション・アーキテクチャを示す。一般性を失うことなく、Androidインテント（intents）及びbinderインターフェース１８が、小さく／低い帯域幅のメッセージ及びイベント下において、データを通信するための機構として使用される。
【００４８】
図８に示すように、コアソフトウェアスタック１５は、Androidサービスとして実装される。アプリケーション１３ａ，アプリケーション１３ｂは、ＡＰＩ１４ａ，ＡＰＩ１４ｂを夫々介して、コア・ソフトウェア・サービス（ソフトウェアスタック１５）と通信するAndroid・binderインターフェース１８を使用する。
【００４９】
具体的には、Androidインターフェース定義言語（Android  Interface  definition  Language:AIDL）１９ａ，１９ｂによって、Android・binderインターフェース１８が、定義される。
【００５０】
コアソフトウェアスタック１５のコアソフトウェアインタフェースは、コマンド制御用のAndroidインターフェース定義言語（ＡＩＤＬ）によって定義されるとともに、コールバック制御用の他のAndroidインターフェース定義言語によって定義される。
【００５１】
特に、複数のスレッドと、ＡＩＤＬ１９ａ及びＡＩＤＬ１９ｂによって定義されるAndroid・binderインターフェース１８との間の通信を最適化するために、及びハードウェアの変更無しで、Android・binderインターフェース１８の通信処理を最適化するために、Android・binderインターフェース１８が、適切に、調整されることができる。
【００５２】
ＡＩＤＬ１９ａとＡＩＤＬ１９ｂとによって定義されるAndroid・binderインターフェース１８を用いることにより、システム設計者は、アプリケーション１３とコアソフトウェアスタック１５との間の通信インターフェースを再定義又は再構築することなく、データ通信のソフトウェア・プロセス・モデルを変更することができる。
【００５３】
図９は、電子機器１００のAndroidのオペレーションシステム下の第２のマルチヘッドスタックのアプリケーション・アーキテクチャを示す。図９において、図９のマルチヘッドスタックのアプリケーション・アーキテクチャは、図８のマルチヘッドスタックのアプリケーション・アーキテクチャに類似している。
【００５４】
違いは、コアソフトウェアスタックＡＰＩ１７ａ及びコアソフトウェアスタックＡＰＩ１７ｂはでデベロッパーＡＰＩに内蔵された２つの関数インターフェースとして導入されていることである。言い換えると、コアソフトウェアスタックＡＰＩ１７ａ，コアソフトウェアスタックＡＰＩ１７ｂは、ＡＩＤＬ１９ａ，ＡＩＤＬ１９ｂによって定義されていない。
【００５５】
上記複数の実施形態では、複数のアプリケーション・プログラミング・インターフェースの各アプリケーション・プログラミング・インタフェースは、オペレーションシステムに固有の機構を使用することで、別のアプリケーション・プログラミング・インターフェースと、複数のデータ又は特徴を共有することができる。例えば、ＩＰ通話、ＩＭ、ファイル転送、ジオロケーション（GeoLocation）、画像の共有、ビデオ共有などの、機能の完全なセットを提供するＡＰＩは、完全な機能を備えたリッチコミュニケーションサービス（ＲＣＳ）を必要とすることがある。
【００５６】
別のＡＰＩ（つまり、第三者のＡＰＩ）だけで、ＩＭやファイル転送などのような、これらの機能のサブセットをサポートする必要があることがある。ビデオゲームのための別のＡＰＩは、画像共有、ビデオ共有をサポートすることがある。特に、技術を共有するデータ又は特徴を使用することによって、これらの全てのアプリケーションが同時にサポートされることができるので、作業効率を高めることができる。
【００５７】
まとめると、上記複数の実施形態は、インターネットプロトコル通信のための、電子機器及び、複数のアプリケーション・アーキテクチャへのアプローチを提案している。設計思想は、共通のコアソフトウェアスタックを導入することである。
異なる複数のＡＰＩを有効（使用可能）にすると、共通のコアソフトウェアスタックは、異なる複数のＡＰＩによって、アクセスされることができる。換言すれば、マルチアプリケーションは、いかなる通信干渉をされることなく、簡単かつ効率的な機構で、同時に共通のコアソフトウェアスタックと通信することができる。
【００５８】
当業者は、本発明の教示を維持しながら、装置及び方法の多くの修正及びの変更がされ得ることを遵守する。したがって、添付の特許請求の範囲の内容（境界及び範囲）によってのみ限定されるものとして、上記の開示は、解釈されるべきである。
【符号の説明】
【００５９】
１０  メモリ
１１  プロセッサ
１２  インターフェースユニット
１３，１３ａ，１３ｂ  アプリケーション
１４，１４ａ，１４ｂ  アプリケーション・プログラミング・インターフェース（ＡＰＩ）
１５  コアソフトウェアスタック
１６  プロコトル
１７ａ，１７ｂ  コアソフトウェアスタックＡＰＩ
１８  Android・binderインターフェース
１９ａ，１９ｂ  Androidインターフェース定義言語（ＡＩＤＬ）
ＣＱ  コマンドキュー
ＥＱ，ＥＱａ，ＥＱｂ  イベントキュー
ＣＰ  コマンドパイプ
ＥＰ，ＥＰａ，ＥＰｂ  イベントパイプ
【図１】
2016081535.tif 000003
【図２】
2016081535.tif 000004
【図３】
2016081535.tif 000005
【図４】
2016081535.tif 000006
【図５】
2016081535.tif 000007
【図６】
2016081535.tif 000008
【図７】
2016081535.tif 000009
【図８】
2016081535.tif 000010
【図９】
2016081535.tif 000011