(57)【要約】【課題】Ａｎｄｒｏｉｄアプリケーション内部にデータを保持しないシステムを提供する。【解決手段】データをＡｎｄｒｏｉｄアプリケーションのデータを外部サーバーや外部のクラウド等の外部ストレージへ格納する。そのため、Ａｎｄｒｏｉｄアプリケーション内部にはデータを保持しない。そして、必要な時に、外部ストレージから直接ダウンロードしたデータをプライベートワーキングセット内部でのみ使用することにより、ゼロデータアプリケーションを実現する。【選択図】図１
2019153261.tif 000002
【特許請求の範囲】
【請求項１】
Ａｎｄｒｏｉｄアプリケーション内部で使用するデータを外部のサーバーやクラウド等の外部のストレージに保存することで、Ａｎｄｒｏｉｄアプリケーション内部に保存するデータをゼロにすることを特徴とするＡｎｄｒｏｉｄアプリケーションの開発方法。
【請求項２】
Ａｎｄｒｏｉｄアプリケーション内で使用するデータを、使用する都度、外部のサーバーやクラウド等の外部のストレージからダウンロードして利用し、Ａｎｄｒｏｉｄアプリケーション内部に保存するデータをゼロにすることを特徴とするＡｎｄｒｏｉｄアプリケーションの開発プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】      本発明は、Ａｎｄｒｏｉｄの開発方法および開発プログラムのデータの扱いに関するものである。
【背景技術】
【０００２】  データとは、コンピュータが記録・処理できる形式になっているもののことを指す。ここで、Ａｎｄｒｏｉｄにおけるデータとは、文字や画像や音声や動画等をファイルとして保存したものを指す。そして、そのＡｎｄｒｏｉｄにおけるデータをＡｎｄｒｏｉｄではリソースファイルと呼ぶ。【０００３】  また、アンドロイドアプリケーションパッケージ（Ａｎｄｒｏｉｄ  ａｐｐｌｉｃａｔｉｏｎ  ｐａｃｋａｇｅ：ＡＰＫ）とは、アンドロイドオペレーティングシステムで活用されるソフトウェアとミドルウェアの配布に使用されるパッケージファイルであって、「．ａｐｋ」拡張子を有する。ＡＰＫファイルは該当するプログラムの全てのコードを含んでおり、ソース、情報、リソースファイル、認証書、およびマニフェストファイルなどを含む。【０００４】  現在、ほとんどのＡｎｄｒｏｉｄアプリケーションは、データをリソースファイルという形でＡＰＫファイル内に保存される。【０００５】  そのため、大量のデータを扱うアプリケーションにおいては、その分大量のデータ領域を確保しなければならず、作成されるＡＰＫファイルは大きく肥大する。よって、スマートフォンの内部ストレージが枯渇するという問題点がある。
⇒「データ保存領域の不足」【０００６】  また、アプリケーション内部の画像データを変更する場合には、新たな画像データをリソースファイルとして保存し、本来のコードに新たなリソースファイルを使用するようにコードを変更した後、変更されたコードに対して、再びコンパイル過程を経てパッケージファイルを新たに生成する。そして、アップデートの処理を行い、ユーザーにアプリケーションがバージョンアップしたことを知らせ、バージョンアップの手続を行ってもらわなければならない。
⇒「更新作業の増加」【０００７】  さらに、リソースファイルの中にコンピュータウィルスを混入されてしまった場合には、本体のアプリケーションとは関係なく、そのアプリケーション全てがウィルスに感染しているアプリケーションであると判断されてしまうという問題点がある。
⇒「リソースファイルへのウィルス混入のリスク」【０００８】  そして、完成したアプリケーションをダウンロードしたユーザーが、逆コンパイルを利用して、ＡＰＫファイルからリソースファイルを抽出し、著作物を不正に所有するという問題点がある。
⇒「ユーザーによる著作物抽出のリスク」
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】データの保存  ｈｔｔｐｓ：／／ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ．ｃｏｍ／ｔｒａｉｎｉｎｇ／ｂａｓｉｃｓ／ｄａｔａ−ｓｔｏｒａｇｅ／ｉｎｄｅｘ．ｈｔｍｌ？ｈｌ＝ｊａ
【発明の概要】
【発明が解決しようとする課題】
【００１０】  「データ保存領域の不足」の解消
⇒スマートフォンの内部ストレージが枯渇するという問題点を解消するためには、データ保存領域をスマートフォン内部ではなく、外部のストレージにする必要がある。【００１１】  「更新作業の増加」の解消
⇒バージョンアップの手続を行わずに内部の画像データ等を変更するためには、画像データ等のようなリソースファイルは、スマートフォンの内部ストレージに保存するのではなく、外部のサーバーやクラウド等の外部ストレージから使用の都度ダウンロードする方法が考えられる。【００１２】  「リソースファイルへのウィルス混入のリスク」の解消
⇒アプリケーションのリソースファイル内へウィルスが混入されていることで、そのアプリケーション全てがウィルスに感染しているアプリケーションであると判断されてしまうという問題点を解消するためには、アプリケーション内にリソースファイルを含めなければよい。【００１３】  「ユーザーによる著作物抽出のリスク」の解消
⇒ユーザーが逆コンパイルを利用して、ＡＰＫファイルからリソースファイルを抽出し、著作物を不正に所有するという問題点を解消するためには、ＡＰＫファイル内にリソースファイルを含めなければよい。【００１４】  本発明は、上記に鑑みてなされたものであって、データを外部のサーバーやクラウド等のストレージに保存し、プログラム側では、データを使用する時に、その都度、サーバーやクラウド等のストレージからダウンロードするアプリケーションを作成することで、上記に挙げた課題を解消することを目的とする。
【課題を解決するための手段】
【００１５】  「データ保存領域の不足」を解決するために、本発明では、データを外部のストレージに保存する。
⇒「データを外部のストレージに保存する方法」【００１６】  そして、アプリケーションの動作時には、外部に保存したデータをアプリケーション内に確保したプライベートワーキングセット内で使用する。
ここで、Ａｎｄｒｏｉｄにおけるプライベートワーキングセットとは、ＣＰＵ内部のレジスタにおいて、データを読み込んで処理を実行する領域のことである。
⇒「外部ストレージから使用の都度、プライベートワーキングセットにデータをダウンロードする方法」【００１７】  「更新作業の増加」を解決するために、本発明では、データをサーバーやクラウド等の外部のストレージから使用の度にダウンロードして使用する。
⇒「データを外部のストレージから使用の度にダウンロードする方法」【００１８】  「リソースファイルへのウィルス混入のリスク」を解決するために、本発明では、リソースファイルをアプリケーションとは切り離し、リソースファイルに関しては外部のサーバーやクラウド等の外部のストレージからダウンロードする。
⇒「リソースファイルとアプリケーションを切り離す方法」【００１９】  「ユーザーによる著作物抽出のリスク」を解決するために、本発明では、フールプルーフとして、ＡＰＫファイル内にリソースファイルを含めない。これにより、ＡＰＫファイルが逆コンパイルされても、ユーザーが不正にリソースファイルの中から著作物を抽出することを防止することができる。
ここでフールプルーフとは、人間が誤った行為をしようとしても出来ないようにする工夫のことである。
⇒「ＡＰＫファイル内にリソースファイルを含めない方法」【００２０】  そして、前述した［００１６］において説明したとおり、リソースファイルを使用の都度、サーバーやクラウド等の外部のストレージから、プライベートワーキングセット内にダウンロードすることにより、内部ストレージにリソースファイルを残すことなくアプリケーションを実行できる。そのため、本発明ではフールプルーフとして、ユーザーが不正にリソースファイルの中から著作物を抽出することを防止することができる。
⇒「ダウンロードデータを内部ストレージに残さない方法」
【発明の効果】
【００２１】  本発明によれば、「データ保存領域の不足」を解決し、保存データの増加に合わせた広大な保存領域を確保することができる。【００２２】  本発明によれば、「更新作業の増加」を解決し、画像の入れ替え等の作業であれば、アプリケーションをアップデートすることなく、サーバーやクラウド側の画像等を入れ替えることで、アプリケーションに表示する画像等のデータを更新することができる。【００２３】  本発明によれば、「リソースファイルへのウィルス混入のリスク」を解決し、アプリケーションがウィルスに感染した時に、ウィルスが図２の２や３のリソースファイル側に含まれていたのか、それとも図２の１のアプリケーションのプログラム側に含まれていたのかを特定することができる。【００２４】  本発明によれば、「ユーザーによる著作物抽出のリスク」を解決し、図３のように、ユーザーが不正にリソースファイルの中から著作物を抽出することを防止し、フールプルーフとして機能することができる。
【図面の簡単な説明】
【００２５】
【図１】ゼロデータアプリケーションと従来のアプリケーションとの比較の図である。
【図２】ゼロデータアプリケーションでのウィルス感染時の切り分けの図である。
【図３】ユーザーによる著作権の侵害の図である。
【図４】サーバーからデータを取得するプログラムの例を示した図である。
【発明を実施するための形態】
【００２６】  以下、図面を参照して、本発明の一実施形態を詳細に説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。
【実施例−開発方法】
【００２７】  以下、実施形態について、添付の図面を参照しながら詳しく説明する。
【００２８】  図１は、本発明の一実施形態における、ネットワーク環境の例を示した図である。図１のネットワーク環境は、Ａｎｄｒｏｉｄ端末１００、１１０、サーバー１２０、クラウド１３０を含む例を示している。このような図１は、発明を説明するための一例に過ぎず、Ａｎｄｒｏｉｄ端末の数やサーバーの数やクラウドの数が図１のように限定されることはない。
【００２９】  Ａｎｄｒｏｉｄ端末１００、１１０は、コンピュータ装置によって実現される固定型端末や移動型端末であってもよい。Ａｎｄｒｏｉｄ端末１００、１１０の例としては、スマートフォン（ｓｍａｒｔ  ｐｈｏｎｅ）、携帯電話、コンピュータ、ノート型パソコン、タブレットＰＣなどがある。一例として、Ａｎｄｒｏｉｄ端末（１１０）は、無線または有線通信方式を利用し、ネットワークを介してサーバー１２０および／またはクラウド１３０と通信してもよい。
【００３０】  通信方式が制限されることはなく、ネットワークが含むことのできる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を活用する通信方式だけではなく、機器間の近距離無線通信が含まれてもよい。例えば、ネットワークは、ＰＡＮ（ｐｅｒｓｏｎａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＬＡＮ（Ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ  ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでもよい。さらに、ネットワークは、パスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、これらを組み合わせたハイブリッドネットワーク、ツリーまたは階層的（ｈｉｅｒａｒｃｈｉｃａｌ）ネットワークなどを含むネットワークとポロジのうちの任意の１つ以上を含んでもよいが、これに制限されることはない。
【００３１】  サーバー１２０、クラウド１３０それぞれは、複数のＡｎｄｒｏｉｄ端末や電子機器とネットワークを介して通信して、データを提供するコンピュータ装置または複数のコンピュータ装置によって実現されてもよい。
【実施例−開発プログラム】
【００３２】  上記実施形態に係るＡｎｄｒｏｉｄ端末が実行するアプリケーションのプログラム例を図４に示す。このやり方によれば、ＨｔｔｐＵＲＬＣｏｎｎｅｃｉｔｏｎのインスタンスを確保してサーバーと通信している。そして、サーバー側に、あらかじめ保存しておいた画像データを、ビットマップイメージとしてサーバーから取得している。
【００３３】  以上のように、実施形態を限定された実施形態と図面に基づいて説明したが、私ならば、上述した記載から多様な修正および変形が可能である。例えば、説明された技術が説明された方法とは異なる順序で実行されたり、および／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。
【００３４】  したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。
【産業上の利用可能性】
【００３５】  本発明は、全てのＡｎｄｒｏｉｄアプリケーションの作成において利用することができる。すなわち、本発明を利用することによって、広大なデータの保存領域を確保し、ウィルスの混入リスクを減少させ、著作物を保護し、更新作業を減らす用途に利用できる。
【符号の説明】
【００３６】１００  Ａｎｄｒｏｉｄ端末
１１０  Ａｎｄｒｏｉｄ端末
１２０  サーバー
１３０  クラウド
２００  Ａｎｄｒｏｉｄ端末
２１０  サーバー
２２０  クラウド
【図１】
2019153261.tif 000003
【図２】
2019153261.tif 000004
【図３】
2019153261.tif 000005
【図４】
2019153261.tif 000006