JP6913791B1 - 処理装置、処理方法及びプログラム - Google Patents

処理装置、処理方法及びプログラム Download PDF

Info

Publication number
JP6913791B1
JP6913791B1 JP2020081051A JP2020081051A JP6913791B1 JP 6913791 B1 JP6913791 B1 JP 6913791B1 JP 2020081051 A JP2020081051 A JP 2020081051A JP 2020081051 A JP2020081051 A JP 2020081051A JP 6913791 B1 JP6913791 B1 JP 6913791B1
Authority
JP
Japan
Prior art keywords
estimation
content
terminal
information
executed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020081051A
Other languages
English (en)
Other versions
JP2021175447A (ja
Inventor
洋輝 花岡
洋輝 花岡
Original Assignee
株式会社Cygames
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社Cygames filed Critical 株式会社Cygames
Priority to JP2020081051A priority Critical patent/JP6913791B1/ja
Application granted granted Critical
Publication of JP6913791B1 publication Critical patent/JP6913791B1/ja
Publication of JP2021175447A publication Critical patent/JP2021175447A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

【課題】端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する。【解決手段】本発明は、端末装置にインストールされたアプリケーション内のコンテンツを実行した時の端末装置の状態を示す実行時状態情報、及び、コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶部15に蓄積する情報蓄積部11と、記憶部15に蓄積された実行時状態情報及びバッテリ情報に基づき、端末装置の状態を示す情報からコンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成部12と、所定の推定タイミングで端末装置の状態を示す推定時状態情報を取得し、推定時状態情報と推定モデルとに基づき、推定時状態情報で示される状態の端末装置でコンテンツを実行したときのバッテリ消費量を推定する推定部13と、推定部13の推定結果を出力する出力部14と、を有する処理装置10を提供する。【選択図】図2

Description

本発明は、処理装置、処理方法及びプログラムに関する。
従来の研究や製品では、CPUやディスプレイといったハードウエアの部品を分析したり、ユーザの習慣的な行動によるアプリケーションの利用傾向を学習したりすることにより、アプリケーションによるバッテリ消費量や、今後のバッテリ消費量の推移を予測する。
非特許文献1は、利用者の習慣的な行動を反映して、数時間先までのバッテリ残量のグラフを予測して表示する機能を開示している。
非特許文献2に開示の技術では、スマートフォンの状態を5種に分類し、それぞれの状態が占める時間を以って、利用者を特徴付けている。具体的には、1)待ち受け、2)通話、3)第1の方式を利用したデータ通信、4)第2の方式を利用したデータ通信、5)その他、である。そして、ユーザのログを分析することにより、5種の状態に基づきユーザによる使用パターンの違いを分析する。
非特許文献3は、CPUやディスプレイといった電力消費量の大きなハードウエア部品の計測値をパラメータとする関数として、バッテリ消費量をモデル化する技術を開示している。
非特許文献4は、1日ないし数日間における長時間のプロファイルから、バッテリ消費量のモデルを学習することにより、"in the wild"のバッテリ消費量を指定する手法を開示している。当該手法は、ハードウエアの部品単位あるいはアプリケーション単位で、バッテリ消費量を推定することができる。
特許文献1は、バッテリ残量と所与の閾値を比較することにより、セーブを促す仕組みを開示している。
特許文献2は、電気自動車が走行を終了した際に、バッテリの残量と閾値との比較に基づいて充電を催促する仕組みを開示している。具体的には、車両の利用形態を学習し、学習結果に基づいて閾値設定するという思想が提案されている。
特許文献3は、充電場所、充電開始時刻及び充電時間の履歴から、日常の充電場所及び充電時間帯を学習し、利用者が充電を実行できそうな時だけ充電案内を行う仕組みを開示している。具体的には、バッテリの残電力量と、日常の走行にかかる消費電力量とを比較し、充電案内の実施可否を判定する思想が提案されている。
特許文献4は、バッテリ残量と所与の閾値を比較することにより、ゲームのパラメータを変更する仕組みを開示している。当該特許の実施形態の変形例によれば、バッテリが所定の残容量を下回った時に単位ゲームを選択できなくするという例が提示されている。すなわち、当該特許は、コンテンツ単位で、対応するバッテリ残量の閾値を、ゲーム開発者があらかじめ設計しておくものである。
特許第4033427号 特開2003−209901号 US8954223B2 US10434414B2
Michelle NYC, Smart battery on Pixel, https://support.google.com/pixelphone/forum/AAAAb4-OgUstyVoEaFNJ1k/?hl=by, retrieved November 25, 2019, Nov. 2017. Joon-Myung Kang, Sin-Seok Seo, and James Won-Ki Hong, "Personalized Battery Lifetime Predic- tion for Mobile Devices based on Usage Patterns," Journal of Computing Science and Engineering, vol. 5, Dec. 2011, 338-345, doi: 10.5626/JCSE.2011.5.4.338. Xia Zhao, Yao Guo, Qing Feng, and Xiangqun Chen, 2011, "A System Context-aware Approach for Battery Lifetime Prediction in Smart Phones," In Proceedings of the 2011 ACM Symposium on Applied Computing, SAC '11, ACM, TaiChung, Taiwan, 641-646, doi: 10.1145/1982185.1982327. http://doi.acm.org/10.1145/1982185.1982327. Andres Munoz Medina, Ashish Sharma, Felix Yu, Paul Eastham, Sergei Vassilvitskii, and Umar Syed, 2016, "Learning mobile phone battery consumptions.", https://research.google/pubs/pub45901/.
近年、スマートフォン、タブレット端末、スマートウォッチ、携帯電話、携帯ゲーム機、ノートパソコン等のような可搬型の端末装置が広く普及している。このような可搬型の端末装置は、一般的には、間欠的に充電操作がなされる。例えば、外出中には充電操作は実行されず、自宅にいる間の任意のタイミングで充電操作が実行されたりする。このため、ユーザは、バッテリ残量を考慮し、次回の充電タイミングまでバッテリが残るように端末装置の使用を制限する等の対応が必要になる場合がある。
そこで、端末装置を用いた所定の処理(例えば、ゲームアプリケーションに含まれるコンテンツの実行)を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する技術が望まれている。当該技術によれば、ユーザは、所定の処理を実行した場合のバッテリ消費量を考慮して、当該処理を実行するか否か等を判断することができる。しかし、アプリケーションの特定の機能を特定の端末で動作させた時の電力消費量を事前に推定することは難しい。例えばゲームのように複合的な機能を有するアプリケーションでは、サウンドやGPUやネットワークを複合的に組み合わせるため、特定の機能を実行する時の電力消費量は、機能×デバイスの数だけ存在することになる。いずれの先行技術も、当該課題を開示していない。
なお、従来技術(例えば非特許文献4)では、ユーザの習慣的な利用傾向に基づきアプリケーション単位でバッテリ消費量を推定する技術を開示している。しかし、一般的に、アプリケーションは多機能であり、アプリケーション内のどの機能を利用するかに応じて、ユーザの利用時間やハードウエアの処理負担などは異なり得る。このため、ユーザの習慣的な利用傾向に基づくアプリケーション単位でのバッテリ消費量の推定は、1日単位や1カ月単位といった比較的大きな時間単位での推定に適しているが、より小さい時間単位での推定には適していない。端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する技術においては、1日単位や1カ月単位といった比較的大きな時間単位でのバッテリ消費量の推定でなく、より小さい時間単位での推定が必要となる。
また、従来技術(例えば非特許文献3)では、CPUやディスプレイといった電力消費量の大きなハードウエア部品の計測値をパラメータとする関数として、バッテリ消費量をモデル化している。この技術の場合、所定の処理を開始した後に、所定の処理実行時のハードウエア部品の計測値に基づきバッテリ消費量を推定できる。しかし、所定の処理を開始する前に推定し、ユーザに通知することはできない。
本発明は、端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する技術を実現することを課題とする。
本発明によれば、
端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積部と、
前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成部と、
所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定部と、
前記推定部の推定結果を出力する出力部と、
を有し、
前記アプリケーションでは複数のコンテンツが実行可能であり、
前記情報蓄積部は、前記コンテンツ毎に、前記実行時状態情報及び前記バッテリ情報を前記記憶手段に蓄積し、
前記推定モデル生成部は、前記コンテンツ毎に、前記コンテンツ各々を実行した時のバッテリ消費量を推定する前記推定モデルを生成し、
前記推定部は、前記コンテンツ各々を実行したときのバッテリ消費量を推定する記載の処理装置が提供される。
また、本発明によれば、
コンピュータが、
端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積し、
少なくとも、前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成し、
所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定し、推定結果を出力し、
前記アプリケーションでは複数のコンテンツが実行可能であり、
前記コンピュータは、
前記コンテンツ毎に、前記実行時状態情報及び前記バッテリ情報を前記記憶手段に蓄積し、
前記コンテンツ毎に、前記コンテンツ各々を実行した時のバッテリ消費量を推定する前記推定モデルを生成し、
前記コンテンツ各々を実行したときのバッテリ消費量を推定する処理方法が提供される。
また、本発明によれば、
コンピュータを、
端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積手段、
前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成手段、
所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定手段、
前記推定手段の推定結果を出力する出力手段、
として機能させ
前記アプリケーションでは複数のコンテンツが実行可能であり、
前記情報蓄積手段は、前記コンテンツ毎に、前記実行時状態情報及び前記バッテリ情報を前記記憶手段に蓄積し、
前記推定モデル生成手段は、前記コンテンツ毎に、前記コンテンツ各々を実行した時のバッテリ消費量を推定する前記推定モデルを生成し、
前記推定手段は、前記コンテンツ各々を実行したときのバッテリ消費量を推定するプログラムが提供される。
本発明によれば、端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する技術が実現される。
本実施形態の処理装置のハードウエア構成の一例を示す図である。 本実施形態の処理装置の機能ブロックの一例を示す図である。 本実施形態の処理装置が処理する情報の一例を模式的に示す図である。 本実施形態の処理装置の処理の流れの一例を示すフローチャートである。 本実施形態の処理装置の処理の流れの一例を示すフローチャートである。 本実施形態の端末装置で表示される画面の一例を模式的に示す図である。 本実施形態の端末装置で表示される画面の一例を模式的に示す図である。 本実施形態の処理装置が処理する情報の一例を模式的に示す図である。 本実施形態の処理装置が処理する情報の一例を模式的に示す図である。
<概要>
本実施形態の処理装置は、端末装置の状態と、その状態でアプリケーション内の各コンテンツを実行した場合のバッテリ消費量との関係を示す推定モデルを生成する。そして、処理装置は、当該推定モデルに基づき、推定時の端末装置の状態で各コンテンツを実行した場合のバッテリ消費量を推定し、ユーザに通知する。
アプリケーションは、例えばゲームアプリケーションであるがこれに限定されない。アプリケーションは、実行可能な1つ又は複数のコンテンツを提供する。ユーザは、複数のコンテンツの中から1つを選択して実行する。例えば、野球に関するゲームアプリケーションの場合、「試合(9イニング)」、「試合(7イニング)」、「練習(打撃)」、「練習(守備)」、「練習(投球)」、「トレード」、「ドラフト」等のコンテンツが提供され得る。
コンテンツは、アプリケーション内で実行可能な処理の1つである。このため、1つのコンテンツを実行している間におけるハードウエア処理負担の幅(最も処理負担が大きい時から最も処理負担が小さい時までの幅)は、複数のコンテンツを選択的に順次実行可能な1つのアプリケーションを実行している間におけるハードウエア処理負担の幅よりも小さい。また、1つのコンテンツの実行に要する時間(コンテンツを開始してから終了するまでの時間)の幅は、複数のコンテンツを選択的に順次実行可能な1つのアプリケーションの実行に要する時間の幅よりも小さい。
端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する技術において、このようなコンテンツ単位でバッテリ消費量を推定する技術を採用し、各コンテンツを実行する前に各コンテンツを実行した場合のバッテリ消費量を推定して通知するように構成することで、より精度が高く、有益な情報をユーザに提供することが可能となる。
<ハードウエア構成>
次に、処理装置のハードウエア構成を説明する。処理装置は、ユーザが操作する端末装置であってもよいし、当該端末装置と通信するサーバであってもよい。端末装置は、例えば、スマートフォン、タブレット端末、スマートウォッチ、携帯電話、携帯ゲーム機、ノートパソコン等のような可搬型の端末装置であるが、これに限定されない。
処理装置が備える各機能部は、任意のコンピュータのCPU(Central Processing Unit)、メモリ、メモリにロードされるプログラム、そのプログラムを格納するハードディスク等の記憶ユニット(あらかじめ装置を出荷する段階から格納されているプログラムのほか、CD(Compact Disc)等の記憶媒体やインターネット上のサーバ等からダウンロードされたプログラムをも格納できる)、ネットワーク接続用インターフェイスを中心にハードウエアとソフトウエアの任意の組合せによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。
図1は、処理装置のハードウエア構成を例示するブロック図である。図1に示すように、処理装置は、プロセッサ1A、メモリ2A、入出力インターフェイス3A、周辺回路4A、バス5Aを有する。周辺回路4Aには、様々なモジュールが含まれる。なお、処理装置は周辺回路4Aを有さなくてもよい。
処理装置は、物理的及び論理的に1つの装置で構成されてもよい。処理装置は、物理的及び/又は論理的に分かれた複数の装置で構成されてもよい。この場合、複数の装置各々が上記ハードウエア構成を備えることができる。
バス5Aは、プロセッサ1A、メモリ2A、周辺回路4A及び入出力インターフェイス3Aが相互にデータを送受信するためのデータ伝送路である。プロセッサ1Aは、例えばCPU、GPU(Graphics Processing Unit)などの演算処理装置である。メモリ2Aは、例えばRAM(Random Access Memory)やROM(Read Only Memory)などのメモリである。入出力インターフェイス3Aは、入力装置、外部装置、外部サーバ、外部センサ等から情報を取得するためのインターフェイスや、出力装置、外部装置、外部サーバ等に情報を出力するためのインターフェイスなどを含む。入力装置は、例えばキーボード、マウス、マイク等である。出力装置は、例えばディスプレイ、スピーカ、プリンター、メーラ等である。プロセッサ1Aは、各モジュールに指令を出し、それらの演算結果をもとに演算を行うことができる。
<機能構成>
次に、処理装置の機能構成を説明する。図2に、処理装置10の機能ブロック図の一例を示す。図示するように、処理装置10は、情報蓄積部11と、推定モデル生成部12と、推定部13と、出力部14と、記憶部15とを有する。
情報蓄積部11は、端末装置にインストールされたアプリケーション内のコンテンツを実行した時の端末装置の状態を示す実行時状態情報、及び、コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、履歴情報として記憶部15に蓄積する。アプリケーションが複数のコンテンツを提供する場合、情報蓄積部11は、コンテンツ毎に、実行時状態情報及びバッテリ情報を記憶部15に蓄積する。
処理装置10が端末装置である場合、情報蓄積部11は、自装置が備えるセンサや機能を介して自装置に関する実行時状態情報及びバッテリ情報を取得する。一方、処理装置10が端末装置と通信するサーバである場合、情報蓄積部11は、端末装置が収集したその端末装置に関する実行時状態情報及びバッテリ情報を、インターネット等のネットワークを介して端末装置から受信する。
端末装置の状態を示す実行時状態情報は、取得可能な情報であって、バッテリ消費量に影響し得る任意の情報を含むことができる。例えば、実行時状態情報としては、端末装置にインストールされているOS(operating system)の種類、通信ネットワークの接続方式、ディスプレイの輝度、バックグラウンドで起動中のアプリケーションの種類、CPU使用率、ネットワーク通信量(byte/second)等が例示されるが、これらに限定されない。
コンテンツを実行した時のバッテリ消費量は、コンテンツ開始時のバッテリ残量とコンテンツ終了時のバッテリ残量とに基づき算出可能である。
図3に、実行時状態情報及びバッテリ情報を示す履歴情報の一例を模式的に示す。図示する例では、コンテンツIDと、コンテンツの実行を開始した日時であるコンテンツ開始日時(Timestart)と、コンテンツの実行を終了した日時であるコンテンツ終了日時(Timeend)と、コンテンツ開始日時におけるバッテリ残量(Energystart)と、コンテンツ終了日時におけるバッテリ残量(Energyend)と、コンテンツ実行時のOSの種類(K(OS))と、コンテンツ実行時の通信ネットワークの接続方式(K(Network))と、端末装置の種類(K(UA))とが互いに紐付けられている。
ここで、図4のフローチャートを用いて、情報蓄積部11が実行する処理の流れの一例を説明する。ここでは、処理装置10が端末装置であるものとする。
情報蓄積部11は、コンテンツの実行開始を監視している(S10)。情報蓄積部11は、コンテンツの実行開始を検出すると(S10のYes)、その時点の端末装置の状態(実行時状態情報)やバッテリ残量を示す開始時状態情報を取得する(S11)。そして、情報蓄積部11は、取得した開始時状態情報を、実行開始されるコンテンツのコンテンツIDに紐付けて記憶部15が記憶する履歴情報(図3参照)に登録する(S12)。
その後、情報蓄積部11は、そのコンテンツの実行終了を監視する(S13)。情報蓄積部11は、コンテンツの実行終了を検出すると(S13のYes)、その時点の端末装置のバッテリ残量を示す終了時状態情報を取得し(S14)、記憶部15が記憶する履歴情報(図3参照)に登録する(S15)。
情報蓄積部11は当該処理を繰り返す。結果、図3に示すような履歴情報が蓄積されていく。なお、処理装置10がサーバである場合、例えば、端末装置が図4のフローチャートで示す処理を実行し、端末装置内に履歴情報を蓄積する。そして、端末装置は、任意のタイミングで、自装置内に蓄積した履歴情報をサーバに送信する。その他、端末装置は図4のフローチャートで示す処理を実行し、S11及びS14で開始時状態情報及び終了時状態情報を取得すると、リアルタイム処理で取得した情報をサーバに送信してもよい。そして、サーバが、受信した開始時状態情報及び終了時状態情報を自装置内に登録してもよい。
図2に戻り、推定モデル生成部12は、記憶部15に蓄積された履歴情報(実行時状態情報及びバッテリ情報)に基づき、「端末装置の状態を示す情報」から「コンテンツを実行したときのバッテリ消費量」を推定する推定モデルを生成する。
推定モデルは、例えば、端末装置の状態を示す情報と、当該状態でコンテンツを実行したときのバッテリ消費量(=(Energystart)−(Energyend))とを紐付けた教師データに基づく任意の機械学習で生成されたモデルであってもよい。この場合、推定モデルの出力は、コンテンツを実行したときのバッテリ消費量となる。その他、推定モデルは、端末装置の状態を示す情報と、コンテンツを実行する前のバッテリ残量(Energystart)と、コンテンツを実行した後のバッテリ残量(Energyend)とを紐付けた教師データに基づく任意の機械学習で生成されたモデルであってもよい。この場合、推定モデルの出力は、コンテンツを実行した後のバッテリ残量となる。なお、いずれの場合も、バッテリ消費量を推定している。
その他、推定モデルは、端末装置の状態を示す情報と、当該状態でコンテンツを実行した場合のバッテリ消費量との関係を示すテーブルをパターンマッチング等で照合し、キー(端末装置の状態を示す情報)に紐付くバッテリ消費量を特定するモデルであってもよい。その他、推定モデルは、端末装置の状態を示す情報と、コンテンツを実行する前のバッテリ残量(Energystart)と、コンテンツを実行した後のバッテリ残量(Energyend)との関係を示すテーブルをパターンマッチング等で照合し、キー(端末装置の状態を示す情報及びコンテンツを実行する前のバッテリ残量(Energystart))に紐付くバッテリ消費量を特定するモデルであってもよい。
その他、推定モデルは、相関量を計量するためのベクトルに写像する等の手法を用いるモデルであってもよい。
なお、アプリケーションが複数のコンテンツを提供する場合、推定モデル生成部12は、コンテンツ毎に推定モデルを生成することができる。
推定部13は、所定の推定タイミングで端末装置の状態を示す推定時状態情報を取得し、推定時状態情報と推定モデルとに基づき、推定時状態情報で示される状態の端末装置でコンテンツを実行したときのバッテリ消費量を推定する。
推定時状態情報は、実行時状態情報と同種の情報を含む。推定時状態情報としては、例えば、端末装置にインストールされているOSの種類、通信ネットワークの接続方式、ディスプレイの輝度、バックグラウンドで起動中のアプリケーションの種類等が例示されるが、これらに限定されない。また、推定モデルの内容によっては、推定時のバッテリ残量が推定時状態情報に含まれる。
処理装置10が端末装置である場合、推定部13は、自装置が備えるセンサや機能を介して自装置に関する推定時状態情報を取得する。一方、処理装置10が端末装置と通信するサーバである場合、推定部13は、端末装置が収集したその端末装置に関する推定時状態情報を、インターネット等のネットワークを介して端末装置から受信する。
出力部14は、推定部13の推定結果を出力する。処理装置10が端末装置である場合、出力部14は、端末装置が備えるディスプレイやスピーカ等の出力装置を介して、推定結果を出力する。一方、処理装置10が端末装置と通信するサーバである場合、出力部14は、推定結果を端末装置に送信する。そして、端末装置は、自装置が備えるディスプレイやスピーカ等の出力装置を介して、受信した推定結果を出力する。
ここで、図5のフローチャートを用いて、推定部13及び出力部14による処理の流れの一例を説明する。
まず、推定部13は、バッテリ消費量を推定する推定タイミングの到来を監視している(S20)。推定タイミングの具体例は後述する。
そして、推定タイミングの到来を検出すると(S20のYes)、推定部13は、推定対象のコンテンツのコンテンツIDを取得する(S21)。推定対象のコンテンツは1つであってもよいし、複数であってもよい。推定対象のコンテンツの具体例は後述する。
また、推定部13は、その時点における端末装置の状態を示す推定時状態情報を取得する(S22)。推定部13は、推定時のバッテリ残量を推定時状態情報として取得してもよい。なお、S21及びS22の処理順はこれに限定されない。
次いで、推定部13は、S21で取得したコンテンツIDに対応する推定モデルと、S22で取得した推定時状態情報とに基づき、当該推定時状態情報で示される状態の端末装置で、当該コンテンツIDで示されるコンテンツを実行した場合のバッテリ消費量を推定する(S23)。
次いで、出力部14は、S23の推定処理で得られた推定結果を出力する(S25)。
ここで、推定タイミング、推定対象のコンテンツ及び推定結果の出力画面の一例を説明する。
「例1」
当該例では、推定タイミングは、コンテンツの実行を開始する入力を受付ける受付画面を表示する入力(ユーザ入力)を受付けたタイミングである。そして、当該例では、推定対象のコンテンツは、当該受付画面で実行を開始する入力を受付可能なコンテンツである。
推定部13は、当該受付画面を表示する入力の受付に応じて推定時状態情報を取得し、推定時状態情報と推定モデルとに基づき、その推定時状態情報で示される状態の端末装置で上記推定対象のコンテンツ各々を実行したときのバッテリ消費量を推定する。
そして、出力部14は、当該受付画面において、各コンテンツに紐づけて推定結果を表示させる。図6に、当該例で端末装置に表示される当該受付画面の一例を模式的に示す。当該例では、アプリケーションは、野球に関するゲームアプリケーションである。そして、当該受付画面は、「試合(9イニング)」、「試合(7イニング)」、「練習(打撃)」、「練習(守備)」、「練習(投球)」等のコンテンツの実行を開始する入力を受付け可能になっている。そして、各コンテンツに紐付けて、その時点で各コンテンツを実行した場合のバッテリ消費量の予測結果が示されている。
「例2」
当該例では、推定タイミングは、アプリケーションが提供する複数のコンテンツ各々のバッテリ消費量の一覧を表示する入力(ユーザ入力)を受付けたタイミングである。そして、当該例では、推定対象のコンテンツは、アプリケーションが提供するすべてのコンテンツである。
推定部13は、当該一覧を表示する入力の受付に応じて推定時状態情報を取得し、推定時状態情報と推定モデルとに基づき、その推定時状態情報で示される状態の端末装置で上記推定対象のコンテンツ各々を実行したときのバッテリ消費量を推定する。
そして、出力部14は、当該一覧を表示する画面において、各コンテンツに紐づけて推定結果を表示させる。図7に、当該例で端末装置に表示される画面の一例を模式的に示す。当該画面では、アプリケーションが提供するすべてのコンテンツ各々に紐付けて、その時点で各コンテンツを実行した場合のバッテリ消費量の予測結果が示されている。
なお、図6及び図7では、満充電電力量に対する消費電力量の割合でバッテリ消費量を示しているが、その他の手法でバッテリ消費量を示してもよい。しかし、一般的な端末装置では、満充電電力量に対する残電力量の割合でバッテリ残量を示す。このため、図示するような手法でバッテリ消費量を示すと、ユーザがバッテリ残量とバッテリ消費量とを対比しやすくなり好ましい。
また、図6及び図7では、出力部14は、推定結果としてコンテンツ実行によるバッテリ消費量を示しているが、その他、コンテンツ実行後のバッテリ残量の予測値を推定結果として出力してもよい。
<変形例1>
当該変形例では、アプリケーションが提供する複数のコンテンツは、バッテリの消費の仕方が類似するもの同士でグループ化される。そして、図8に示すような、各コンテンツがどのグループに属するかを示すグループ情報が処理装置10内に予め記憶されている。
推定モデル生成部12は、グループ毎に、グループに属するコンテンツの履歴情報(実行時状態情報及びバッテリ情報)に基づき上述した推定モデルを生成する。すなわち、変形例では、コンテンツ毎でなく、グループ毎に推定モデルが生成される。
そして、推定部13は、バッテリ消費量を推定する対象のコンテンツが属するグループを特定し、特定したグループに対応する推定モデルに基づき、その時点でそのコンテンツを実行したときのバッテリ消費量を推定する。
<変形例2>
処理装置10がサーバである場合、処理装置10は、複数のユーザの端末装置から履歴情報(実行時状態情報及びバッテリ情報)を取得することができる。処理装置10は、ユーザ毎に各ユーザの履歴情報を処理して推定モデルを生成してもよいし、複数のユーザの履歴情報をまとめて処理して複数のユーザ毎に推定モデルを生成してもよい。また、複数のユーザの属性情報(性別、年令、国籍、アプリケーションの利用歴(年数等)、端末装置の情報(メーカ、型番、OS、通信サービスを提供するキャリア等)等)が処理装置10内に登録されている場合、処理装置10は、属性情報が一致又は類似するユーザ同士でグループ化し、グループ毎に各グループに属するユーザの履歴情報をまとめて処理してグループ毎に推定モデルを生成してもよい。
<変形例3>
処理装置10は、少なくとも実行時状態情報及びバッテリ情報に基づき推定モデルを生成し、少なくとも実行時状態情報及びバッテリ情報に基づきバッテリ消費量を推定する。処理装置は、実行時状態情報及びバッテリ情報以外の情報であって、バッテリ消費量に影響し得るその他の情報を、例えば外部装置(端末装置以外の装置)から取得し、当該情報をさらに利用して推定モデルの生成、及び、バッテリ消費量の推定を行ってもよい。例えば、使用している部品(ハードウエア)ごとに推定モデルを構築しておき、当該推定モデルと、実行時状態情報に基づく推定モデルとを組み合わせてバッテリ消費量を推定してもよい。
<実施例>
次に、本実施形態の処理装置10をより具体化した実施例を説明する。
本実施例は、ユーザがこれから実行するコンテンツを選択するための画面に遷移した時に、その画面に選択可能に表示されるコンテンツを実行した場合のバッテリ消費量を予測し、予測結果をその画面に表示する方式である。例えば、ユーザが2つのコンテンツ(001−NORMALと001−HARD)を選択可能な画面に遷移した時、本実施例の処理装置10は、「001−NORMALはバッテリの0.5%を消費」、「001−HARDはバッテリの0.8%を消費」のように、コンテンツごとにその時に実行した場合のバッテリ消費量を予測し、予測した結果を、コンテンツを開始するためのボタンと合わせて表示する。
本実施例の処理装置10のシステムアーキテクチャは、コンテンツごとのバッテリ消費量を予測するための推定フェーズと、予測のための推定モデルを生成するための学習フェーズとに分けられる。ここでは、本実施例の処理装置10を実現するための3つのモジュールについて説明した後、学習フェーズと推定フェーズについて詳述する。
「モジュール」
本実施例の処理装置10は、[M1]Learning Moduleと、[M2]Model Dataと、[M3]Inference Moduleとの3モジュールを含んで構成される。
[M1]Learning Moduleは、開発者やユーザがコンテンツを実行した時の履歴情報(実行時状態情報及びバッテリ情報)を入力として、コンテンツごとのバッテリ消費量を予測するためのモデルをM2として出力する関数である。M1の入力となる履歴情報は、以下の式(1)及び式(2)に示すような時系列データとして定義できる。
ここで、Itemtは、コンテンツごとの履歴情報の項目である。ContentIDは、コンテンツごと、もしくは、コンテンツのグループごとにあらかじめ設定されたユニークな識別子である。Timestartは、当該コンテンツを開始した時刻である。Timeendは、当該コンテンツを終了した時刻である。Energystartは、当該コンテンツを開始した時刻におけるバッテリ残量である。Energyendは、当該コンテンツを終了した時刻におけるバッテリ残量である。Energystart及びEnergyendの値は、[0,1]の範囲の浮動小数点数とする。Energystart及びEnergyendの値が0のとき、バッテリが完全に放電した状態(残量0)であることを示す。そして、Energystart及びEnergyendの値が1のとき、バッテリが完全に充電された状態(満充電状態)であることを示す。
(Ki,Vi)は、ハードウエアの構成要素やセンサ情報の種類を示すKeyと、その値を示すValueのペアである。このKey-Valueペアは、例えば、OSの種類のような静的な情報や、ネットワーク接続方式のような動的に変化する情報を含む。この履歴情報の実装方法として、開発者が、リリース前に、デバッグやテストのために蓄積したものであっても良いし、ユーザが、以前に同じ端末で実行した時に蓄積したものであっても良い。履歴情報の実装の例は、図3で示される。
[M2]Model Dataは、M1によって出力され、M3の入力となる推定モデルデータである。本モジュールの具体的な実装は、M1の実装に応じて設定されるが、例を図9に示す。図9の詳細は、後述する。
[M3]Inference Moduleは、ユーザがこれから実行するコンテンツを選択するための画面に遷移した時に、その画面に表示される予定のコンテンツのリスト(ContentIDのリスト)と、その時刻におけるスマートフォンのバッテリ残量(Energystart)と、その時刻におけるハードウエアの構成要素やセンサ情報([(K1,V1),・・・・(Km,Vm)])を入力として受け取り、受け取った各ContentIDを対象に、入力の時点からユーザが当該コンテンツを実行したと仮定して、実行し終わった時のバッテリ残量(Energyend)を予測して出力する関数である。当該関数は以下の式(3)及び式(4)のように示される。
本モジュールの具体的な実装は、M1の実装に応じて設定されるが、本実施例では、最も単純な実施例として、テーブルを用いたパターンマッチングによる推定を行う方式を採用する。他の実装例として、特徴量を抽出して何らかの機械学習を行っても良いし、相関量を計量するためのベクトルに写像しても良い。
「学習フェーズ」
次に、本実施例の学習フェーズを説明する。本実施例の学習フェーズでは、開発者やユーザがゲームのコンテンツを実行した時の履歴情報(実行時状態情報及びバッテリ情報)を用いて、パターンマッチングによる推定を行うためのテーブルを生成する。例えば、本実施例の処理装置10は、図3に示すような履歴情報に基づき、以下の式(5)のように定義されるテーブルを生成する。
式(5)で定義されるテーブルの一例は、図9に示される。図9に示すテーブルは、ContentIDごとにEnergystartを0.05刻みで区切り、(Ki,Vi)とEnergyendを対応付けたものである。ここで、(Ki,Vi)は、収集されたデータのうち、推定のために必要なものだけ使用し、その他は使用しないといった選別を行っても良い。
次に、学習フェーズにおける処理の流れを説明する。
「Step1」: 開発者やユーザがアプリケーションを開始した時、処理装置10は、履歴情報を格納するためのテーブルHistoryを作成する。処理装置10は、アプリケーションの異常終了に備えて、永続化できる媒体にHistoryを作成することが好ましいが、実装の要件に応じてメモリ上に作成しても良い。
処理装置10は、過去に作成したHistoryが残っていた時、後述するStep4の学習モデルの更新の処理を実行し、Historyを空にする。
「Step2」:開発者やユーザが、開発者によって識別子を定義されているコンテンツの実行を開始した時、処理装置10は、Step1で作成したHistoryに新たなエントリItemtを追加し、次の4種の情報を記録する。
・開始されたコンテンツのContentID
・当該コンテンツを開始した時刻Timestart
・当該コンテンツを開始した時刻におけるバッテリ残量Energystart
・当該コンテンツを開始した時刻におけるハードウエアの構成要素やセンサ情報[(K,V)・・・・(K,V)]
「Step3」:開発者やユーザが、開発者によって識別子を定義されているコンテンツの実行を終了した時、処理装置10は、Step1で作成し、Step2で更新したHistoryに、次の2種の情報を記録する。
・当該コンテンツを終了した時刻Timeend
・当該コンテンツを終了した時刻におけるバッテリ残量Energyend
「Step4」:開発者やユーザが、ゲームの実行を中断あるいは終了した時、処理装置10は、Historyに記録したItemt1・・・Itemtkを使って推定モデルを更新し、更新が完了したらHistoryを空にする。
本実施例では、処理装置10は、Historyに記録したItemt1・・・Itemtkを使って図9に示すテーブルPatternMatchTableを更新する。具体的には、処理装置10は、Historyを走査し、各要素Itemtについて、以下に示すStep4−1、Step4−2を実行する。
「Step4−1」:まず、処理装置10は、コンテンツの開始時刻におけるバッテリ残量Energystartについて、[0、0.05、0.10、・・・0.95、1.00]のように、複数のインデックス値Energystartindexを設定している。そして、処理装置10は、Historyに記録された複数のItemtの中の処理対象のItemtのEnergystartに最も近いEnergystartindexを特定する。例えば上述のように0.05刻みでEnergystartindexを設定した場合において、処理対象のItemtのEnergystartが0.76である場合、0.75が最も近いEnergystartindexとして特定される。
さらに、処理装置10は、処理対象のItemtのハードウエアの構成要素やセンサ情報([(K1,V1),・・・・(Km,Vm)])の中から、推定時に必要となる要素を取り出す。最も単純には同じ配列を使っても良い。
「Step4−2」:次に、処理装置10は、図9に示すPatternMatchTableにおいて、ContentID及び[(K1,V1),・・・・(Km,Vm)]の列の値が処理対象のItemtに含まれる値と一致し、かつ、Energystartの列の値がStep4−1で特定したEnergystartindexと一致する行を探す。
当該行が存在しない場合、処理装置10は、処理対象のItemtに含まれるContentID、Energyend、[(K1,V1),・・・・(Km,Vm)]、及び、Step4−1で特定したEnergystartindexを新たな行として図9に示すPatternMatchTableに追加する。
一方、当該行が存在する場合、処理装置10は、その行のEnergyendの値を、処理対象のItemtに含まれるEnergyendの値に基づき更新する。例えば、バッテリの劣化を考慮し、その行のEnergyendの値を、最新の値(処理対象のItemtに含まれるEnergyendの値)に更新してもよい。
その他、その行のEnergyendの値を、その行のEnergyendの値と処理対象のItemtに含まれるEnergyendの値の統計値(最大値、最小値、平均値等)に更新してもよい。その他、その行のEnergyendの値を、その行のEnergyendの値及び処理対象のItemtに含まれるEnergyendの値各々に各々の重み係数を掛けた値の合計値に更新してもよい。
「推定フェーズ」
次に、本実施例の推定フェーズを説明する。本実施例は、ユーザがこれから実行するコンテンツを選択するための画面に遷移した時に、その画面に表示される予定のコンテンツごとに、パターンマッチングによってバッテリ消費量を予測する。具体的には、パターンマッチングのためのテーブル(図9)において、Energyendのカラムを除いて、推定時の時刻における端末装置のバッテリ残量と、当該時刻におけるハードウエアの構成要素やセンサ情報がマッチする行を探す。
例えば、OS001の端末装置を利用するユーザが、NW001の接続方式でネットワークに接続している時に、2つのコンテンツ(001−NORMALと001−HARD)が表示される画面に遷移したとする。この時の端末装置のバッテリ残量が0.76であったとすると、処理装置10は、図9に示すPatternMatchTableの中から、ContentIDが「001−NORMAL」又は「001−HARD」にマッチし、K1(OS)が,「OS001」にマッチし、K2(Network)が「NW001」にマッチし、かつ、Energystartの値が「0.76」に最も近い行を探す。
結果、ContentID「001−NORMAL」に対応して上から2番目の行が特定され、ContentID「001−HARD」に対応して上から5番目の行が特定される。結果、処理装置10は、「001−NORMALを実行した場合、バッテリ残量が0.73になる」と推定し、「001−HARDをプレイした場合、バッテリ残量が0.69になる」と推定する。処理装置10は、この結果を画面に反映する際に、「001−NORMALを実行した場合、バッテリ残量が73%になる」、「001−HARDをプレイした場合、バッテリ残量が69%になる」のように、ユーザが理解しやすい形式に変換して表示しても良い。
次に、推論フェーズにおける処理の流れを説明する。
「Step1」:ユーザが、コンテンツを選択する画面に遷移する入力を行うと、処理装置10は、当該画面に表示される予定のコンテンツの一覧を、ContentIDの配列として取得する。また、処理装置10は、端末装置のOSから、当該時刻におけるバッテリ残量Energystartと、当該時刻におけるハードウエアの構成要素やセンサ情報[(K1,V1),・・・・(Km,Vm)]を受け取る。
「Step2」:処理装置10は、受け取ったContentIDの配列を走査し、ContentIDごとに、各コンテンツを実行した後のバッテリ残量を予測する。具体的には、処理装置10は、図9に示すPatternMatchTableを用いて、マッチする行を探す。最も単純には、本システムは、Exact-Matchする行がある場合だけ、プレイ後のバッテリ残量を当該行に含まれるEnergyendであると予測する。そして、Exact-Matchする行がない場合、処理装置10は、「バッテリ消費量が不明」という結果を出力しても良い。
例えば、処理装置10は、ContentIDの配列に含まれるContentIDごとに、以下に示すStep2−1乃至2−3を実行してもよい。
「Step2−1」:処理装置10は、図9に示すPatternMatchTableにおいて、処理対象のContentIDと一致する全ての行を特定する。当該行が1つも存在しない場合、処理装置10は、処理対象のContentIDで識別されるコンテンツを実行した場合のバッテリ消費量は「不明」という結果を出力する。当該行が1でも存在する場合、処理装置10は、次のステップの処理を実行する。
「Step2−2」:処理装置10は、Step2−1で特定した行の中から、Step1で取得したバッテリ残量Energystartが最も近い行を特定する。具体的には、各行が示すEnergystartとStep1で取得したバッテリ残量Energystartとの差の絶対値が最も小さい行を特定する。特定した行が1つである場合、処理装置10は、処理対象のContentIDで識別されるコンテンツを実行した場合のバッテリ消費量はその特定した行が示すEnergyendという結果を出力する。一方、特定した行が複数ある場合、処理装置10は、Step2−3を実行する。
「Step2−3」:処理装置10は、Step2−2で特定した行の中から、Step1で取得したハードウエアの構成要素やセンサ情報[(K1,V1),・・・・(Km,Vm)]が最も近い行を特定する。なお、このm次元の情報の近さ(類似度)を算出する手法は特段制限されず、あらゆる手法を採用できる。特定した行が1つである場合、処理装置10は、処理対象のContentIDで識別されるコンテンツを実行した場合のバッテリ消費量はその特定した行が示すEnergyendという結果を出力する。一方、特定した行が複数ある場合、処理装置10は、任意の手法で特定した複数の行の中から1つを特定する。そして、処理装置10は、処理対象のContentIDで識別されるコンテンツを実行した場合のバッテリ消費量はその特定した行が示すEnergyendという結果を出力する。
「Step3」:処理装置10は、ContentIDごとのバッテリ消費量の推定結果をアプリシステムに渡す。アプリシステムは、受け取った推定結果を反映した画面を描画し、ディスプレイに表示する。この時、アプリシステムは、アプリ実行後のバッテリ残量を見積もった結果をそのまま表示しても良いし、アプリ実行前のバッテリ残量からアプリ実行後のバッテリ残量を引くことで算出したバッテリ消費量を表示してもよい。
<作用効果>
処理装置10は、端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知することができる。当該技術によれば、ユーザは、所定の処理を実行した場合のバッテリ消費量を考慮して、当該処理を今実行するか否か等を判断することができる。
また、処理装置10は、コンテンツ単位でバッテリ消費量を推定し、その結果をユーザに通知する。コンテンツは、アプリケーション内で実行可能な処理の1つである。このため、1つのコンテンツを実行している間におけるハードウエア処理負担の幅(最も処理負担が大きい時から最も処理負担が小さい時までの幅)は、複数のコンテンツを選択的に順次実行可能な1つのアプリケーションを実行している間におけるハードウエア処理負担の幅よりも小さい。また、1つのコンテンツの実行に要する時間(コンテンツを開始してから終了するまでの時間)の幅は、複数のコンテンツを選択的に順次実行可能な1つのアプリケーションの実行に要する時間の幅よりも小さい。よって、コンテンツ単位でバッテリ消費量を推定する場合、アプリケーション単位でバッテリ消費量を推定するよりも、推定精度が高くなる。結果、推定精度の高い有益な情報をユーザに提供することができる。
また、処理装置10は、例えば何度も繰り返し実行することを前提としたアプリケーションの周回コンテンツを対象に、コンテンツ毎にバッテリ消費量の傾向を学習した推定モデルを用いてバッテリ消費量を推定し、ユーザがコンテンツを選択する時にその推定結果を通知することができる。これにより、ユーザの主体的なバッテリ制御が可能となる。
また、処理装置10は、ハードウエア/ソフトウエアの状況という形でデータを取得することにより、自然に実行環境を考慮することができるため、多様な携帯端末に適用することが可能である。
また、処理装置10は、コンテンツIDのみを考慮し、具体的なコンテンツの内容を全く考慮しないので、アプリケーションの開発者は、本実施形態の処理を実現するための特別な設定を追加する必要がない。このため、既存のコンテンツをそのまま利用することができ、かつ、新規コンテンツを従来通りに追加すると、自動的に、処理装置10にバッテリ消費量を推定させることができる。このように、既存のゲーム開発パイプラインを変更せずに適用可能である。
また、処理装置10は、端末装置側で実現されてもよいし、サーバ側で実現されてもよい。すなわち、ユーザの端末装置で集めたデータを、そのままエッジサイドでの学習に利用しても良いし、サーバに送信してクラウドサイドでの学習に利用しても良い。これにより、開発者は、アプリケーションの特性に応じて、学習のリアルタイム性やユーザプライバシーの保全を重視するならエッジサイドの学習を、端末の負荷低減を重視するならクラウドサイドの学習を、それぞれ選択することができる。このように、処理装置10は、汎用性が高い。
以下、参考形態の例を付記する。
1. 端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積部と、
前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成部と、
所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定部と、
前記推定部の推定結果を出力する出力部と、
を有する処理装置。
2. 前記アプリケーションでは複数のコンテンツが実行可能であり、
前記情報蓄積部は、前記コンテンツ毎に、前記実行時状態情報及び前記バッテリ情報を前記記憶手段に蓄積し、
前記推定モデル生成部は、前記コンテンツ毎に、前記コンテンツ各々を実行した時のバッテリ消費量を推定する前記推定モデルを生成し、
前記推定部は、前記コンテンツ各々を実行したときのバッテリ消費量を推定する1に記載の処理装置。
3. 前記アプリケーションでは複数のコンテンツが実行可能であり、
前記情報蓄積部は、前記コンテンツ毎に、前記実行時状態情報及び前記バッテリ情報を前記記憶手段に蓄積し、
前記推定モデル生成部は、グループ毎に、少なくとも、前記グループに属する前記コンテンツの前記実行時状態情報及び前記バッテリ情報に基づき前記推定モデルを生成し、
前記推定部は、バッテリ消費量を推定する対象の前記コンテンツである対象コンテンツが属する前記グループを特定し、特定した前記グループに対応する前記推定モデルに基づき、前記対象コンテンツを実行したときのバッテリ消費量を推定する1に記載の処理装置。
4. 前記端末装置が、前記コンテンツの実行を開始する入力を受付ける受付画面を表示する入力を受付けると、
前記推定部は、前記受付画面を表示する入力の受付に応じて前記端末装置の状態を示す前記推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定し、
前記出力部は、前記受付画面において、前記コンテンツに紐づけて前記推定結果を表示させる1から3のいずれかに記載の処理装置。
5. コンピュータが、
端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積し、
少なくとも、前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成し、
所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定し、推定結果を出力する処理方法。
6. コンピュータを、
端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積手段、
前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成手段、
所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定手段、
前記推定手段の推定結果を出力する出力手段、
として機能させるプログラム。
1A プロセッサ
2A メモリ
3A 入出力I/F
4A 周辺回路
5A バス
10 処理装置
11 情報蓄積部
12 推定モデル生成部
13 推定部
14 出力部
15 記憶部

Claims (4)

  1. 端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積部と、
    前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成部と、
    所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定部と、
    前記推定部の推定結果を出力する出力部と、
    を有し、
    前記アプリケーションでは複数のコンテンツが実行可能であり、
    前記情報蓄積部は、前記コンテンツ毎に、前記実行時状態情報及び前記バッテリ情報を前記記憶手段に蓄積し、
    前記推定モデル生成部は、グループ毎に、少なくとも、前記グループに属する前記コンテンツの前記実行時状態情報及び前記バッテリ情報に基づき前記推定モデルを生成し、
    前記推定部は、バッテリ消費量を推定する対象の前記コンテンツである対象コンテンツが属する前記グループを特定し、特定した前記グループに対応する前記推定モデルに基づき、前記対象コンテンツを実行したときのバッテリ消費量を推定する処理装置。
  2. 前記端末装置が、前記コンテンツの実行を開始する入力を受付ける受付画面を表示する入力を受付けると、
    前記推定部は、前記受付画面を表示する入力の受付に応じて前記端末装置の状態を示す前記推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定し、
    前記出力部は、前記受付画面において、前記コンテンツに紐づけて前記推定結果を表示させる請求項1に記載の処理装置。
  3. コンピュータが、
    端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積工程と
    少なくとも、前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成工程と
    所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定工程と、
    前記推定工程の推定結果を出力する出力工程と、
    を実行し、
    前記アプリケーションでは複数のコンテンツが実行可能であり、
    前記コンピュータは、
    前記情報蓄積工程では、前記コンテンツ毎に、前記実行時状態情報及び前記バッテリ情報を前記記憶手段に蓄積し、
    前記推定モデル生成工程では、グループ毎に、少なくとも、前記グループに属する前記コンテンツの前記実行時状態情報及び前記バッテリ情報に基づき前記推定モデルを生成し、
    前記推定工程では、バッテリ消費量を推定する対象の前記コンテンツである対象コンテンツが属する前記グループを特定し、特定した前記グループに対応する前記推定モデルに基づき、前記対象コンテンツを実行したときのバッテリ消費量を推定する処理方法。
  4. コンピュータを、
    端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積手段、
    前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成手段、
    所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定手段、
    前記推定手段の推定結果を出力する出力手段、
    として機能させ、
    前記アプリケーションでは複数のコンテンツが実行可能であり、
    前記情報蓄積手段は、前記コンテンツ毎に、前記実行時状態情報及び前記バッテリ情報を前記記憶手段に蓄積し、
    前記推定モデル生成手段は、グループ毎に、少なくとも、前記グループに属する前記コンテンツの前記実行時状態情報及び前記バッテリ情報に基づき前記推定モデルを生成し、
    前記推定手段は、バッテリ消費量を推定する対象の前記コンテンツである対象コンテンツが属する前記グループを特定し、特定した前記グループに対応する前記推定モデルに基づき、前記対象コンテンツを実行したときのバッテリ消費量を推定するプログラム。
JP2020081051A 2020-05-01 2020-05-01 処理装置、処理方法及びプログラム Active JP6913791B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2020081051A JP6913791B1 (ja) 2020-05-01 2020-05-01 処理装置、処理方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020081051A JP6913791B1 (ja) 2020-05-01 2020-05-01 処理装置、処理方法及びプログラム

Publications (2)

Publication Number Publication Date
JP6913791B1 true JP6913791B1 (ja) 2021-08-04
JP2021175447A JP2021175447A (ja) 2021-11-04

Family

ID=77057515

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020081051A Active JP6913791B1 (ja) 2020-05-01 2020-05-01 処理装置、処理方法及びプログラム

Country Status (1)

Country Link
JP (1) JP6913791B1 (ja)

Also Published As

Publication number Publication date
JP2021175447A (ja) 2021-11-04

Similar Documents

Publication Publication Date Title
EP3198429B1 (en) Heterogeneous thread scheduling
EP3259825B1 (en) Heterogeneous battery cell switching
CN107735766B (zh) 用于向计算设备的用户前摄性地提供推荐的系统和方法
TW201644140A (zh) 異種電池細胞格充電
US10903665B2 (en) Usage data based battery charge or discharge time determination
CN107728874A (zh) 提供用户快捷操作的方法、装置及设备
US10565525B2 (en) Collaborative filtering method, apparatus, server and storage medium in combination with time factor
US20200019560A1 (en) Systems and methods for providing predictions to applications executing on a computing device
US10488905B2 (en) Dynamic energy storage device discharging
CN106104626B (zh) 基于分析的数字内容的更新
TW201706833A (zh) 判定用於軟體開發之經推薦之最佳化策略
US20190340521A1 (en) Intelligent Recommendation Method and Terminal
CN109937392A (zh) 动态外部功率资源选择
US10956976B2 (en) Recommending shared products
JPWO2012023625A1 (ja) 拡張性評価装置、拡張性評価方法および拡張性評価プログラム
CN107608778B (zh) 应用程序管控方法、装置、存储介质及电子设备
WO2019062413A1 (zh) 应用程序管控方法、装置、存储介质及电子设备
CN107885545B (zh) 应用管理方法、装置、存储介质及电子设备
JP6913791B1 (ja) 処理装置、処理方法及びプログラム
WO2019119985A1 (en) Method for preloading application, storage medium, and terminal device
WO2021221157A1 (ja) 処理装置、処理方法及びプログラム
Kwon et al. Tensor casting: Co-designing algorithm-architecture for personalized recommendation training
CN108319444B (zh) 基于音乐鼓点控制终端震动方法、存储设备及计算机设备
CN105607970A (zh) 一种信息处理方法及电子设备
US20180218415A1 (en) Data center and information processing device

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200819

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20200819

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20201130

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20201202

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20201208

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210115

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20210224

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210507

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20210507

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20210518

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20210525

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210615

R150 Certificate of patent or registration of utility model

Ref document number: 6913791

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210712