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

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

Info

Publication number
WO2021221157A1
WO2021221157A1 PCT/JP2021/017184 JP2021017184W WO2021221157A1 WO 2021221157 A1 WO2021221157 A1 WO 2021221157A1 JP 2021017184 W JP2021017184 W JP 2021017184W WO 2021221157 A1 WO2021221157 A1 WO 2021221157A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
estimation
terminal device
executed
information
Prior art date
Application number
PCT/JP2021/017184
Other languages
English (en)
French (fr)
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 CN202180046177.3A priority Critical patent/CN115843274A/zh
Publication of WO2021221157A1 publication Critical patent/WO2021221157A1/ja
Priority to US18/051,741 priority patent/US20230088429A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/50—Controlling the output signals based on the game progress
    • A63F13/53—Controlling the output signals based on the game progress involving additional visual information provided to the game scene, e.g. by overlay to simulate a head-up display [HUD] or displaying a laser sight in a shooting game
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/85—Providing additional services to players
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/329—Power saving characterised by the action undertaken by task scheduling

Definitions

  • the present invention relates to a processing device, a processing method and a program.
  • Non-Patent Document 1 discloses a function of predicting and displaying a graph of the remaining battery level up to several hours ahead, reflecting the habitual behavior of the user.
  • Non-Patent Document 2 the state of the smartphone is classified into five types, and the user is characterized by the time occupied by each state. Specifically, 1) standby, 2) telephone call, 3) data communication using the first method, 4) data communication using the second method, 5) others, and the like. Then, by analyzing the user's log, the difference in usage pattern by the user is analyzed based on the five types of states.
  • Non-Patent Document 3 discloses a technique for modeling battery consumption as a function using measured values of hardware parts having large power consumption such as a CPU and a display as parameters.
  • Non-Patent Document 4 discloses a method of specifying the battery consumption of "in the wild” by learning a model of the battery consumption from a long-time profile in one day or several days. The method can estimate battery consumption on a hardware component basis or application basis.
  • Patent Document 1 discloses a mechanism for promoting save by comparing the remaining battery level with a given threshold value.
  • Patent Document 2 discloses a mechanism for urging charging based on a comparison between the remaining battery level and a threshold value when an electric vehicle finishes running. Specifically, the idea of learning the usage pattern of the vehicle and setting the threshold value based on the learning result has been proposed.
  • Patent Document 3 discloses a mechanism that learns the daily charging location and charging time zone from the charging location, charging start time, and charging time history, and provides charging guidance only when the user is likely to be able to perform charging. There is. Specifically, an idea has been proposed in which the amount of remaining power of the battery is compared with the amount of power consumed during daily driving to determine whether or not charging guidance can be implemented.
  • Patent Document 4 discloses a mechanism for changing game parameters by comparing the remaining battery level with a given threshold value. According to a modification of the embodiment of the patent, an example is presented in which a unit game cannot be selected when the battery falls below a predetermined remaining capacity. That is, in the patent, the game developer designs in advance the corresponding threshold value of the remaining battery level for each content.
  • Patent No. 4033427 Japanese Patent Application Laid-Open No. 2003-209901 US8952223B2 US104344414B2
  • portable terminal devices such as smartphones, tablet terminals, smart watches, mobile phones, portable game machines, laptop computers, etc.
  • Such a portable terminal device is generally charged intermittently.
  • the charging operation is not executed while going out, and the charging operation is executed at an arbitrary timing while at home. Therefore, the user may need to take measures such as limiting the use of the terminal device so that the battery remains until the next charging timing in consideration of the remaining battery level.
  • Non-Patent Document 4 discloses a technique for estimating battery consumption for each application based on the user's habitual usage tendency.
  • an application has multiple functions, and the usage time of the user and the processing load of the hardware may differ depending on which function in the application is used.
  • the estimation of battery consumption in application units based on the user's habitual usage tendency is suitable for estimation in relatively large time units such as daily or monthly, but in smaller time units. Not suitable for estimation.
  • the battery consumption is performed in a relatively large time unit such as a daily unit or a monthly unit. Instead of estimating the quantity, it is necessary to estimate in smaller time units.
  • Non-Patent Document 3 the battery consumption is modeled as a function using the measured value of a hardware component having a large power consumption such as a CPU and a display as a parameter.
  • the battery consumption can be estimated based on the measured value of the hardware component at the time of executing the predetermined process.
  • An object of the present invention is to realize a technique for notifying a user of the battery consumption when a predetermined process using a terminal device is executed before executing the predetermined process.
  • the execution state information indicating the state of the terminal device when the content in the application installed in the terminal device is executed and the battery information indicating the battery consumption when the content is executed are acquired and stored in the storage means.
  • Estimated state information indicating the state of the terminal device is acquired at a predetermined estimation timing, and based on the estimated state information and the estimated model, the content is displayed on the terminal device in the state indicated by the estimated state information.
  • An estimater that estimates battery consumption when executed, and An output unit that outputs the estimation result of the estimation unit and A processing device having the above is provided.
  • the computer The run-time state information indicating the state of the terminal device when the content in the application installed in the terminal device is executed and the battery information indicating the battery consumption when the content is executed are acquired and stored in the storage means. Accumulate and Based on the run-time state information and the battery information stored in the storage means, an estimation model for estimating the battery consumption when the content is executed is generated from the information indicating the state of the terminal device. Estimated state information indicating the state of the terminal device is acquired at a predetermined estimation timing, and based on the estimated state information and the estimated model, the content is displayed on the terminal device in the state indicated by the estimated state information. A processing method for estimating the battery consumption at the time of execution and outputting the estimation result is provided.
  • the execution state information indicating the state of the terminal device when the content in the application installed in the terminal device is executed and the battery information indicating the battery consumption when the content is executed are acquired and stored in the storage means.
  • Information storage means to accumulate An estimation model generation means that generates an estimation model that estimates the battery consumption when the content is executed from the information indicating the state of the terminal device based on the execution time state information and the battery information stored in the storage means.
  • Estimated state information indicating the state of the terminal device is acquired at a predetermined estimation timing, and based on the estimated state information and the estimated model, the content is displayed on the terminal device in the state indicated by the estimated state information.
  • An estimation method for estimating battery consumption when executed An output means that outputs the estimation result of the estimation means, A program is provided that functions as.
  • a technique for notifying a user of the battery consumption when a predetermined process using a terminal device is executed before executing the predetermined process is realized.
  • FIG. 1 It is a figure which shows an example of the hardware composition of the processing apparatus of this embodiment. It is a figure which shows an example of the functional block of the processing apparatus of this embodiment. It is a figure which shows typically an example of the information processed by the processing apparatus of this embodiment. It is a flowchart which shows an example of the processing flow of the processing apparatus of this embodiment. It is a flowchart which shows an example of the processing flow of the processing apparatus of this embodiment. It is a figure which shows typically an example of the screen displayed by the terminal apparatus of this embodiment. It is a figure which shows typically an example of the screen displayed by the terminal apparatus of this embodiment. It is a figure which shows typically an example of the information processed by the processing apparatus of this embodiment. It is a figure which shows typically an example of the information processed by the processing apparatus of this embodiment. It is a figure which shows typically an example of the information processed by the processing apparatus of this embodiment.
  • the processing device of the present embodiment generates an estimation model showing the relationship between the state of the terminal device and the battery consumption when each content in the application is executed in that state. Then, the processing device estimates the battery consumption when each content is executed in the state of the terminal device at the time of estimation based on the estimation model, and notifies the user.
  • the application is, for example, a game application, but is not limited to this.
  • the application provides one or more executable contents.
  • the user selects and executes one of a plurality of contents. For example, in the case of a baseball game application, "match (9 innings)”, “match (7 innings)”, “practice (batting)”, “practice (defense)”, “practice (throw)”, “trade”, Content such as “draft” may be provided.
  • the width of the hardware processing load (the width from the time when the processing load is the largest to the time when the processing load is the smallest) during the execution of one content can selectively execute a plurality of contents in sequence. It is smaller than the range of hardware processing load while executing one application.
  • the width of the time required to execute one content (time from the start of the content to the end) is wider than the width of the time required to execute one application capable of selectively and sequentially executing a plurality of contents. small.
  • the processing device may be a terminal device operated by the user, or may be a server that communicates with the terminal device.
  • the terminal device is, for example, a portable terminal device such as a smartphone, a tablet terminal, a smart watch, a mobile phone, a portable game machine, a laptop computer, etc., but is not limited thereto.
  • Each functional unit of the processing device is stored in the CPU (Central Processing Unit) of an arbitrary computer, memory, a program loaded in the memory, and a storage unit such as a hard disk for storing the program (stored from the stage of shipping the device in advance).
  • a storage unit such as a hard disk for storing the program (stored from the stage of shipping the device in advance).
  • it can also store programs downloaded from storage media such as CDs (Compact Discs) and servers on the Internet), and it is realized by any combination of hardware and software centered on the network connection interface. NS.
  • CDs Compact Discs
  • NS Network connection interface
  • FIG. 1 is a block diagram illustrating a hardware configuration of the processing device.
  • the processing device includes a processor 1A, a memory 2A, an input / output interface 3A, a peripheral circuit 4A, and a bus 5A.
  • the peripheral circuit 4A includes various modules. The processing device does not have to have the peripheral circuit 4A.
  • the processing device may be physically and logically composed of one device.
  • the processing device may be composed of a plurality of physically and / or logically separated devices. In this case, each of the plurality of devices can be provided with the above hardware configuration.
  • the bus 5A is a data transmission path for the processor 1A, the memory 2A, the peripheral circuit 4A, and the input / output interface 3A to send and receive data to and from each other.
  • the processor 1A is, for example, an arithmetic processing unit such as a CPU or a GPU (Graphics Processing Unit).
  • the memory 2A is, for example, a memory such as a RAM (RandomAccessMemory) or a ROM (ReadOnlyMemory).
  • the input / output interface 3A includes an interface for acquiring information from an input device, an external device, an external server, an external sensor, and the like, an interface for outputting information to an output device, an external device, an external server, and the like.
  • the input device is, for example, a keyboard, a mouse, a microphone, or the like.
  • the output device is, for example, a display, a speaker, a printer, a mailer, or the like.
  • the processor 1A can issue commands to each module and perform calculations based on the calculation results thereof.
  • FIG. 2 shows an example of a functional block diagram of the processing device 10.
  • the processing device 10 includes an information storage unit 11, an estimation model generation unit 12, an estimation unit 13, an output unit 14, and a storage unit 15.
  • the information storage unit 11 acquires execution state information indicating the state of the terminal device when the content in the application installed in the terminal device is executed, and battery information indicating the battery consumption when the content is executed. , Stored in the storage unit 15 as history information. When the application provides a plurality of contents, the information storage unit 11 stores the runtime state information and the battery information in the storage unit 15 for each content.
  • the information storage unit 11 acquires run-time state information and battery information related to the own device via sensors and functions provided in the own device.
  • the processing device 10 is a server that communicates with the terminal device
  • the information storage unit 11 transmits the execution state information and the battery information about the terminal device collected by the terminal device from the terminal device via a network such as the Internet. Receive.
  • the run-time state information indicating the state of the terminal device is information that can be acquired and can include arbitrary information that may affect the battery consumption.
  • the execution status information includes the type of OS (operating system) installed in the terminal device, the connection method of the communication network, the brightness of the display, the type of application running in the background, the CPU usage rate, and network communication. Amount (byte / second) and the like are exemplified, but the quantity (byte / second) and the like are not limited thereto.
  • the battery consumption when the content is executed can be calculated based on the remaining battery level at the start of the content and the remaining battery level at the end of the content.
  • FIG. 3 schematically shows an example of history information showing run-time state information and battery information.
  • the content ID the content start date and time (Time start ) which is the date and time when the content execution is started
  • the content end date and time (Time end ) which is the date and time when the content execution is finished
  • the battery at the content start date and time.
  • the remaining amount (Energy start ), the remaining amount of battery at the end date and time of the content (Energy end ), the type of OS at the time of content execution (K 1 (OS)), and the connection method of the communication network at the time of content execution (K 2 (K 2) and Network)), and the type of the terminal device (K n (UA)) is tied to each other.
  • the processing device 10 is a terminal device.
  • the information storage unit 11 monitors the start of execution of the content (S10).
  • the information storage unit 11 detects the start of execution of the content (Yes in S10), the information storage unit 11 acquires the state of the terminal device (runtime state information) at that time and the start state information indicating the remaining battery level (S11). Then, the information storage unit 11 associates the acquired start state information with the content ID of the content to be executed and registers it in the history information (see FIG. 3) stored in the storage unit 15 (S12).
  • the information storage unit 11 monitors the end of execution of the content (S13).
  • the information storage unit 11 detects the end of execution of the content (Yes in S13)
  • the information storage unit 11 acquires the end state information indicating the remaining battery level of the terminal device at that time (S14), and the history information stored in the storage unit 15 (Yes). Register in (see FIG. 3) (S15).
  • the information storage unit 11 repeats the process. As a result, history information as shown in FIG. 3 is accumulated.
  • the processing device 10 is a server
  • the terminal device executes the process shown in the flowchart of FIG. 4 and accumulates the history information in the terminal device. Then, the terminal device transmits the history information accumulated in the own device to the server at an arbitrary timing.
  • the terminal device executes the process shown in the flowchart of FIG. 4 and acquires the start state information and the end state information in S11 and S14
  • the information acquired in the real-time process may be transmitted to the server. Then, the server may register the received start state information and end state information in its own device.
  • the estimation model generation unit 12 changes from "information indicating the state of the terminal device" to "when the content is executed” based on the history information (runtime state information and battery information) stored in the storage unit 15. Generate an estimation model that estimates "battery consumption”.
  • the estimation model collates the information indicating the state of the terminal device with the table showing the relationship between the battery consumption when the content is executed in the state by pattern matching or the like, and the key (information indicating the state of the terminal device). ) May be a model that specifies the battery consumption associated with.
  • the estimation model uses information indicating the state of the terminal device and a table showing the relationship between the remaining battery level (Energy start ) before executing the content and the remaining battery level (Energy end) after executing the content. It may be a model that collates by pattern matching or the like and specifies the battery consumption associated with the key (information indicating the state of the terminal device and the remaining battery level (Energy start) before executing the content).
  • the estimation model may be a model that uses a method such as mapping to a vector for measuring the amount of correlation.
  • the estimation model generation unit 12 can generate an estimation model for each content.
  • the estimation unit 13 acquires the estimation time state information indicating the state of the terminal device at a predetermined estimation timing, and executes the content on the terminal device in the state indicated by the estimation time state information based on the estimation time state information and the estimation model. Estimate the battery consumption when
  • Estimated state information includes information of the same type as run-time state information.
  • Examples of the estimated state information include, but are not limited to, the type of OS installed in the terminal device, the connection method of the communication network, the brightness of the display, the type of the application running in the background, and the like. .. Further, depending on the content of the estimation model, the remaining battery level at the time of estimation is included in the state information at the time of estimation.
  • the estimation unit 13 acquires estimation time state information regarding the own device via sensors and functions provided in the own device.
  • the estimation unit 13 receives the estimated state information about the terminal device collected by the terminal device from the terminal device via a network such as the Internet.
  • the output unit 14 outputs the estimation result of the estimation unit 13.
  • the output unit 14 outputs an estimation result via an output device such as a display or a speaker included in the terminal device.
  • the processing device 10 is a server that communicates with the terminal device
  • the output unit 14 transmits the estimation result to the terminal device.
  • the terminal device outputs the received estimation result via an output device such as a display or a speaker included in the terminal device.
  • the estimation unit 13 monitors the arrival of the estimation timing for estimating the battery consumption (S20). A specific example of the estimation timing will be described later.
  • the estimation unit 13 acquires the content ID of the content to be estimated (S21).
  • the content to be estimated may be one or a plurality. Specific examples of the content to be estimated will be described later.
  • the estimation unit 13 acquires the estimation time state information indicating the state of the terminal device at that time (S22).
  • the estimation unit 13 may acquire the remaining battery level at the time of estimation as the state information at the time of estimation.
  • the processing order of S21 and S22 is not limited to this.
  • the estimation unit 13 is a terminal device in a state indicated by the estimated state information based on the estimation model corresponding to the content ID acquired in S21 and the estimated state information acquired in S22. Estimate the battery consumption when the indicated content is executed (S23).
  • the output unit 14 outputs the estimation result obtained in the estimation process of S23 (S25).
  • the estimated timing is the timing at which the input (user input) for displaying the reception screen for accepting the input for starting the execution of the content is received.
  • the content to be estimated is the content that can accept the input that starts the execution on the reception screen.
  • the estimation unit 13 acquires the estimation time state information in response to the reception of the input for displaying the reception screen, and based on the estimation time state information and the estimation model, the terminal device in the state indicated by the estimation time state information is described above. Estimate the battery consumption when each content to be estimated is executed.
  • FIG. 6 schematically shows an example of the reception screen displayed on the terminal device in the example.
  • the application is a baseball game application.
  • the reception screen starts executing contents such as "match (9 innings)”, “match (7 innings)”, “practice (batting)”, “practice (defense)”, and “practice (throwing)". It is possible to accept the input to be input.
  • the prediction result of the battery consumption when each content is executed at that time is shown in association with each content.
  • the estimated timing is the timing at which an input (user input) for displaying a list of battery consumption of each of the plurality of contents provided by the application is received. Then, in this example, the content to be estimated is all the content provided by the application.
  • the estimation unit 13 acquires the estimation time state information in response to the reception of the input for displaying the list, and based on the estimation time state information and the estimation model, the estimation unit 13 is the terminal device of the state indicated by the estimation time state information. Estimate the battery consumption when executing each of the target contents.
  • FIG. 7 schematically shows an example of a screen displayed on the terminal device in this example. On the screen, the prediction result of the battery consumption when each content is executed at that time is shown in association with each of all the contents provided by the application.
  • the battery consumption is shown in the ratio of the power consumption to the full charge power in FIGS. 6 and 7, the battery consumption may be shown by other methods.
  • the remaining battery level is indicated by the ratio of the remaining power amount to the fully charged power amount. Therefore, it is preferable to show the battery consumption by a method as shown in the figure because it is easy for the user to compare the remaining battery amount with the battery consumption.
  • the output unit 14 shows the battery consumption due to the content execution as the estimation result, but in addition, the predicted value of the battery remaining amount after the content execution may be output as the estimation result. ..
  • ⁇ Modification example 1> the plurality of contents provided by the application are grouped by those having similar battery consumption. Then, as shown in FIG. 8, group information indicating which group each content belongs to is stored in advance in the processing device 10.
  • the estimation model generation unit 12 generates the above-mentioned estimation model for each group based on the history information (runtime state information and battery information) of the contents belonging to the group. That is, in the modified example, the estimation model is generated not for each content but for each group.
  • the estimation unit 13 identifies the group to which the target content for which the battery consumption is estimated belongs, and estimates the battery consumption when the content is executed at that time based on the estimation model corresponding to the specified group. ..
  • the processing device 10 can acquire history information (runtime state information and battery information) from terminal devices of a plurality of users.
  • the processing device 10 may process the history information of each user for each user to generate an estimation model, or collectively process the history information of a plurality of users to generate an estimation model for each of the plurality of users. May be good.
  • attribute information of a plurality of users (gender, age, nationality, application usage history (years, etc.), terminal device information (manufacturer, model number, OS, carrier providing communication service, etc.), etc.) is processed by the processing device 10.
  • the processing device 10 groups users whose attribute information matches or is similar to each other, collectively processes the history information of users belonging to each group for each group, and generates an estimation model for each group. You may.
  • the processing device 10 generates an estimation model based on at least the run-time state information and the battery information, and estimates the battery consumption based on at least the run-time state information and the battery information.
  • the processing device acquires information other than the execution state information and the battery information, which may affect the battery consumption, from, for example, an external device (a device other than the terminal device), and further uses the information. You may generate an estimation model and estimate the battery consumption.
  • an estimation model may be constructed for each component (hardware) used, and the battery consumption may be estimated by combining the estimation model with an estimation model based on run-time state information.
  • the battery consumption when the content displayed selectably on the screen is executed is predicted, and the prediction result is displayed on the screen.
  • the processing device 10 of this embodiment states that "001-NORMAL consumes 0.5% of the battery”.
  • Predict the battery consumption when executed at that time for each content, such as "001-HARD consumes 0.8% of the battery” and display the predicted result together with the button to start the content. do.
  • the system architecture of the processing device 10 of this embodiment is divided into an estimation phase for predicting battery consumption for each content and a learning phase for generating an estimation model for prediction.
  • an estimation phase for predicting battery consumption for each content
  • a learning phase for generating an estimation model for prediction.
  • three modules for realizing the processing device 10 of this embodiment will be described, and then the learning phase and the estimation phase will be described in detail.
  • the processing device 10 of this embodiment includes three modules of [M1] Learning Module, [M2] Model Data, and [M3] Inference Module.
  • the Learning Module inputs the history information (runtime state information and battery information) when the developer or user executes the content, and outputs a model for predicting the battery consumption for each content as M2. It is a function.
  • the history information input to M1 can be defined as time series data as shown in the following equations (1) and (2).
  • Item t is an item of history information for each content.
  • ContentID is a unique identifier set in advance for each content or each group of contents.
  • Time start is the time when the content is started.
  • Time end is the time when the content is finished.
  • Energy start is the remaining battery level at the time when the content is started.
  • Energy end is the remaining battery level at the time when the content is finished.
  • the values of Energy start and Energy end shall be floating point numbers in the range of [0,1]. When the values of Energy start and Energy end are 0, it indicates that the battery is completely discharged (remaining amount is 0). When the values of Energy start and Energy end are 1, it indicates that the battery is in a fully charged state (fully charged state).
  • K i , V i is a pair of a Key indicating the type of hardware component or sensor information and a Value indicating the value.
  • This key-value pair includes, for example, static information such as the type of OS and dynamically changing information such as a network connection method.
  • static information such as the type of OS
  • dynamically changing information such as a network connection method.
  • the developer may have accumulated it for debugging or testing before the release, or the user may have accumulated it when it was previously executed on the same terminal. good.
  • An example of implementing historical information is shown in FIG.
  • ModelData is estimated model data output by M1 and input to M3.
  • the specific implementation of this module is set according to the implementation of M1, and an example is shown in FIG. Details of FIG. 9 will be described later.
  • the Inference Module has a list of contents (content ID list) to be displayed on the screen when the user transitions to the screen for selecting the content to be executed, and the remaining battery level of the smartphone at that time. (Energy start ) and hardware components and sensor information at that time ([(K 1 , V 1 ), ... (K m , V m )]) are received as input, and each received Content ID is received.
  • This is a function that predicts and outputs the remaining battery level (Energy end ) when the content is executed, assuming that the user has executed the content from the time of input.
  • the function is expressed as the following equations (3) and (4).
  • this module is set according to the implementation of M1, but in this embodiment, as the simplest embodiment, a method of estimating by pattern matching using a table is adopted.
  • the feature quantity may be extracted and some machine learning may be performed, or the correlation quantity may be mapped to a vector for measuring the correlation quantity.
  • a table for estimating by pattern matching is generated using the history information (runtime state information and battery information) when the developer or the user executes the contents of the game.
  • the processing device 10 of this embodiment generates a table defined as the following equation (5) based on the history information as shown in FIG.
  • FIG. Table shown in FIG. 9 An example of the table defined by equation (5) is shown in FIG. Table shown in FIG. 9, separate Energy start at intervals of 0.05 for each ContentID, those that associates (K i, V i) and Energy end The.
  • (K i , V i ) may be selected by using only the collected data necessary for estimation and not using the others.
  • Step 1 When a developer or a user starts an application, the processing device 10 creates a table History for storing history information. It is preferable that the processing device 10 creates a history on a medium that can be made persistent in preparation for abnormal termination of the application, but the processing device 10 may be created on the memory according to the implementation requirements.
  • the processing device 10 executes the process of updating the learning model of Step 4, which will be described later, and empties the History.
  • Step 2 When the developer or the user starts executing the content whose identifier is defined by the developer, the processing device 10 adds a new entry Item t to the History created in Step 1, and the following 4 Record species information.
  • Step 3 When the developer or the user finishes the execution of the content whose identifier is defined by the developer, the processing device 10 adds the following two types of information to the History created in Step 1 and updated in Step 2. To record.
  • Step 4" When the developer or the user interrupts or ends the execution of the game, the processing device 10 updates the estimation model using Item t1 ... Item tk recorded in History, and when the update is completed, History. Empty.
  • the processing device 10 updates the table PatternMatchTable shown in FIG. 9 by using Item t1 ... Item tk recorded in History. Specifically, the processing device 10 scans the history and executes Step 4-1 and Step 4-2 shown below for each element Item t.
  • Step 4-1 First, the processing device 10 determines the remaining battery energy start at the start time of the content, such as [0, 0.05, 0.10, ... 0.95, 1.00]. , Multiple index values Energy start index are set. Then, the processing device 10 identifies the Energy start index closest to the Energy start of the Item t to be processed among the plurality of Item t recorded in the History. For example, when the Energy start index is set in increments of 0.05 as described above, when the Energy start of the Item t to be processed is 0.76, 0.75 is specified as the closest Energy start index.
  • the processing device 10 is estimated at the time of estimation from the hardware components and sensor information ([(K 1 , V 1 ), ... (K m , V m )]) of the item t to be processed. Extract the required elements. In the simplest case, the same array may be used.
  • Step 4-2 Next, in the PatternMatchTable shown in FIG. 9, the processing device 10 processes the ContentID and the values in the columns of [(K 1 , V 1 ), ... (K m , V m)]. Find a row that matches the value contained in the target Item t and the value in the Energy start column matches the Energy start index specified in Step 4-1.
  • the processing device 10 sets the Content ID, Energy end , [(K 1 , V 1 ), ... (K m , V m )] and Step 4 included in the Item t to be processed. Add the Energy start index specified in -1 as a new row to the Pattern Match Table shown in FIG.
  • the processing device 10 updates the value of the Energy end of the row based on the value of the Energy end included in the Item t to be processed. For example, in consideration of battery deterioration, the Energy end value in that row may be updated to the latest value ( Energy end value included in the Item t to be processed).
  • Other values for Energy end The of the line, be updated on the statistics of values of Energy end The in a value processed by the Item t of Energy end The of the line (maximum value, minimum value, average value) good.
  • Other values for Energy end The of the line may be updated to the sum of the values obtained by multiplying each of the weight coefficients to the values each Energy end The in the value and the processed Item t of Energy end The of the line ..
  • the estimation phase of this embodiment will be described.
  • the battery consumption is predicted by pattern matching for each content to be displayed on the screen.
  • the pattern matching table (FIG. 9) except for the Energy end column, the remaining battery level of the terminal device at the estimated time and the hardware components and sensor information at that time are displayed. Find a matching line.
  • the processing device 10 matches the Content ID of "001-NORMAL” or "001-HARD” from the Pattern Match Table shown in FIG. 9, and K 1 (OS) is matched to the "OS001", K 2 (Network) is matched to the "NW001", and the value of Energy start is look for the row closest to the "0.76".
  • the processing device 10 estimates that "when 001-NORMAL is executed, the remaining battery level becomes 0.73", and "when playing 001-HARD, the remaining battery level becomes 0.69". presume. When the processing device 10 reflects this result on the screen, "when 001-NORMAL is executed, the remaining battery level becomes 73%” and "when 001-HARD is played, the remaining battery level becomes 69%". It may be converted into a format that is easy for the user to understand and displayed, such as "Naru”.
  • Step 1 When the user inputs a transition to a screen for selecting content, the processing device 10 acquires a list of contents to be displayed on the screen as an array of Content IDs. Further, the processing device 10 uses the OS of the terminal device to determine the remaining battery energy start at the time and the hardware components and sensor information [(K 1 , V 1 ), ... (K m) at the time. , V m )] is received.
  • Step 2 The processing device 10 scans the array of received Content IDs, and predicts the remaining battery level after executing each content for each Content ID. Specifically, the processing device 10 uses the PatternMatchTable shown in FIG. 9 to search for matching rows. In the simplest case, the system predicts the remaining battery level after play as the Energy end included in the line only when there is a line to Exact-Match. Then, if there is no line for Exact-Match, the processing device 10 may output the result "battery consumption is unknown".
  • the processing device 10 may execute Steps 2-1 to 2-3 shown below for each ContentID included in the ContentID array.
  • Step 2-1 The processing device 10 identifies all the rows that match the Content ID to be processed in the PatternMatchTable shown in FIG. If none of the lines exist, the processing device 10 outputs the result that the battery consumption when executing the content identified by the Content ID to be processed is "Unknown". If the line is even 1, the processing device 10 executes the processing of the next step.
  • Step2-2 The processing device 10 identifies the line closest to the remaining battery energy start acquired in Step1 from the lines specified in Step2-1. Specifically, the absolute value of the difference between the remaining battery capacity Energy start acquired in Energy start and Step1 showing each row to identify the smallest line. When there is only one specified line, the processing device 10 outputs the result that the battery consumption when the content identified by the Content ID to be processed is executed is the Energy end indicated by the specified line. On the other hand, when there are a plurality of specified rows, the processing device 10 executes Step2-3.
  • Step2-3 The processing device 10 has hardware components and sensor information [(K 1 , V 1 ), ... (K m) acquired in Step 1 from the lines specified in Step 2-2. , V m )] identifies the closest line.
  • the method for calculating the closeness (similarity) of the m-dimensional information is not particularly limited, and any method can be adopted.
  • the processing device 10 When there is only one specified line, the processing device 10 outputs the result that the battery consumption when the content identified by the Content ID to be processed is executed is the Energy end indicated by the specified line.
  • the processing device 10 specifies one of the plurality of specified rows by an arbitrary method. Then, the processing device 10 outputs the result that the battery consumption when the content identified by the Content ID to be processed is executed is the Energy end indicated by the specified line.
  • Step 3 The processing device 10 passes the estimation result of the battery consumption for each Content ID to the application system.
  • the application system draws a screen that reflects the estimated result received and displays it on the display.
  • the application system may display the result of estimating the remaining battery level after executing the application as it is, or the battery consumption calculated by subtracting the remaining amount of battery after executing the application from the remaining amount of battery before executing the application. The amount may be displayed.
  • the processing device 10 can notify the user of the battery consumption when the predetermined process using the terminal device is executed before executing the predetermined process. According to the technique, the user can determine whether or not to execute the process now, in consideration of the battery consumption when the predetermined process is executed.
  • the processing device 10 estimates the battery consumption for each content and notifies the user of the result.
  • Content is one of the processes that can be performed within an application. Therefore, the width of the hardware processing load (the width from the time when the processing load is the largest to the time when the processing load is the smallest) during the execution of one content can selectively execute a plurality of contents in sequence. It is smaller than the range of hardware processing load while executing one application.
  • the width of the time required to execute one content time from the start of the content to the end
  • the estimation accuracy is higher than for estimating the battery consumption for each application. As a result, useful information with high estimation accuracy can be provided to the user.
  • the processing device 10 estimates the battery consumption by using an estimation model that learns the tendency of the battery consumption for each content, for example, for the orbital content of the application that is assumed to be repeatedly executed many times. When the user selects the content, the estimation result can be notified. This enables the user to independently control the battery.
  • the processing device 10 can naturally consider the execution environment by acquiring data in the form of hardware / software status, it can be applied to various mobile terminals.
  • the processing device 10 since the processing device 10 considers only the content ID and does not consider the specific content content at all, the application developer needs to add a special setting for realizing the processing of the present embodiment. No. Therefore, the existing content can be used as it is, and when the new content is added as in the conventional case, the processing device 10 can automatically estimate the battery consumption. In this way, it can be applied without changing the existing game development pipeline.
  • the processing device 10 may be realized on the terminal device side or on the server side. That is, the data collected by the user's terminal device may be used as it is for learning on the edge side, or may be transmitted to a server and used for learning on the cloud side.
  • the developer selects edge-side learning if the emphasis is on real-time learning and user privacy preservation, and cloud-side learning if the emphasis is on terminal load reduction, depending on the characteristics of the application. be able to.
  • the processing device 10 is highly versatile.
  • the execution state information indicating the state of the terminal device when the content in the application installed in the terminal device is executed and the battery information indicating the battery consumption when the content is executed are acquired and stored in the storage means.
  • the information storage unit stores the run-time state information and the battery information in the storage means for each content.
  • the estimation model generation unit generates the estimation model for estimating the battery consumption when each of the contents is executed for each of the contents.
  • the processing device 1, wherein the estimation unit estimates the battery consumption when each of the contents is executed. 3.
  • Multiple contents can be executed in the application.
  • the information storage unit stores the run-time state information and the battery information in the storage means for each content.
  • the estimation model generation unit generates the estimation model for each group at least based on the runtime state information and the battery information of the contents belonging to the group.
  • the estimation unit identifies the group to which the target content, which is the target content for which the battery consumption is estimated, belongs, and based on the estimation model corresponding to the specified group, the battery consumption when the target content is executed.
  • the processing apparatus for estimating the amount. 4.
  • the estimation unit acquires the estimation time state information indicating the state of the terminal device in response to the reception of the input for displaying the reception screen, and based on the estimation time state information and the estimation model, the estimation time state. Estimate the battery consumption when the content is executed on the terminal device in the state indicated by the information.
  • the processing device displays the estimation result in association with the content on the reception screen.
  • the computer The run-time state information indicating the state of the terminal device when the content in the application installed in the terminal device is executed and the battery information indicating the battery consumption when the content is executed are acquired and stored in the storage means. Accumulate and At least, based on the run-time state information and the battery information stored in the storage means, an estimation model for estimating the battery consumption when the content is executed is generated from the information indicating the state of the terminal device. Estimated state information indicating the state of the terminal device is acquired at a predetermined estimation timing, and based on the estimated state information and the estimated model, the content is displayed on the terminal device in the state indicated by the estimated state information.
  • the execution state information indicating the state of the terminal device when the content in the application installed in the terminal device is executed and the battery information indicating the battery consumption when the content is executed are acquired and stored in the storage means.
  • Information storage means to accumulate An estimation model generation means that generates an estimation model that estimates the battery consumption when the content is executed from the information indicating the state of the terminal device based on the execution time state information and the battery information stored in the storage means.
  • Estimated state information indicating the state of the terminal device is acquired at a predetermined estimation timing, and based on the estimated state information and the estimated model, the content is displayed on the terminal device in the state indicated by the estimated state information.
  • An estimation method for estimating battery consumption when executed An output means that outputs the estimation result of the estimation means, A program that functions as.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Optics & Photonics (AREA)
  • Power Sources (AREA)
  • Telephone Function (AREA)

Abstract

本発明は、端末装置にインストールされたアプリケーション内のコンテンツを実行した時の端末装置の状態を示す実行時状態情報、及び、コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶部（１５）に蓄積する情報蓄積部（１１）と、記憶部（１５）に蓄積された実行時状態情報及びバッテリ情報に基づき、端末装置の状態を示す情報からコンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成部（１２）と、所定の推定タイミングで端末装置の状態を示す推定時状態情報を取得し、推定時状態情報と推定モデルとに基づき、推定時状態情報で示される状態の端末装置でコンテンツを実行したときのバッテリ消費量を推定する推定部（１３）と、推定部（１３）の推定結果を出力する出力部（１４）と、を有する処理装置（１０）を提供する。

Description

処理装置、処理方法及びプログラム
　本発明は、処理装置、処理方法及びプログラムに関する。
　従来の研究や製品では、ＣＰＵやディスプレイといったハードウエアの部品を分析したり、ユーザの習慣的な行動によるアプリケーションの利用傾向を学習したりすることにより、アプリケーションによるバッテリ消費量や、今後のバッテリ消費量の推移を予測する。
　非特許文献１は、利用者の習慣的な行動を反映して、数時間先までのバッテリ残量のグラフを予測して表示する機能を開示している。
　非特許文献２に開示の技術では、スマートフォンの状態を５種に分類し、それぞれの状態が占める時間を以って、利用者を特徴付けている。具体的には、１）待ち受け、２）通話、３）第１の方式を利用したデータ通信、４）第２の方式を利用したデータ通信、５）その他、である。そして、ユーザのログを分析することにより、５種の状態に基づきユーザによる使用パターンの違いを分析する。
　非特許文献３は、ＣＰＵやディスプレイといった電力消費量の大きなハードウエア部品の計測値をパラメータとする関数として、バッテリ消費量をモデル化する技術を開示している。
　非特許文献４は、１日ないし数日間における長時間のプロファイルから、バッテリ消費量のモデルを学習することにより、"ｉｎ ｔｈｅ ｗｉｌｄ"のバッテリ消費量を指定する手法を開示している。当該手法は、ハードウエアの部品単位あるいはアプリケーション単位で、バッテリ消費量を推定することができる。 
　特許文献１は、バッテリ残量と所与の閾値を比較することにより、セーブを促す仕組みを開示している。
　特許文献２は、電気自動車が走行を終了した際に、バッテリの残量と閾値との比較に基づいて充電を催促する仕組みを開示している。具体的には、車両の利用形態を学習し、学習結果に基づいて閾値設定するという思想が提案されている。
　特許文献３は、充電場所、充電開始時刻及び充電時間の履歴から、日常の充電場所及び充電時間帯を学習し、利用者が充電を実行できそうな時だけ充電案内を行う仕組みを開示している。具体的には、バッテリの残電力量と、日常の走行にかかる消費電力量とを比較し、充電案内の実施可否を判定する思想が提案されている。
　特許文献４は、バッテリ残量と所与の閾値を比較することにより、ゲームのパラメータを変更する仕組みを開示している。当該特許の実施形態の変形例によれば、バッテリが所定の残容量を下回った時に単位ゲームを選択できなくするという例が提示されている。すなわち、当該特許は、コンテンツ単位で、対応するバッテリ残量の閾値を、ゲーム開発者があらかじめ設計しておくものである。
特許第４０３３４２７号 特開２００３－２０９９０１号 ＵＳ８９５４２２３Ｂ２ ＵＳ１０４３４４１４Ｂ２
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/.
　近年、スマートフォン、タブレット端末、スマートウォッチ、携帯電話、携帯ゲーム機、ノートパソコン等のような可搬型の端末装置が広く普及している。このような可搬型の端末装置は、一般的には、間欠的に充電操作がなされる。例えば、外出中には充電操作は実行されず、自宅にいる間の任意のタイミングで充電操作が実行されたりする。このため、ユーザは、バッテリ残量を考慮し、次回の充電タイミングまでバッテリが残るように端末装置の使用を制限する等の対応が必要になる場合がある。
　そこで、端末装置を用いた所定の処理（例えば、ゲームアプリケーションに含まれるコンテンツの実行）を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する技術が望まれている。当該技術によれば、ユーザは、所定の処理を実行した場合のバッテリ消費量を考慮して、当該処理を実行するか否か等を判断することができる。しかし、アプリケーションの特定の機能を特定の端末で動作させた時の電力消費量を事前に推定することは難しい。例えばゲームのように複合的な機能を有するアプリケーションでは、サウンドやＧＰＵやネットワークを複合的に組み合わせるため、特定の機能を実行する時の電力消費量は、機能×デバイスの数だけ存在することになる。いずれの先行技術も、当該課題を開示していない。
　なお、従来技術（例えば非特許文献４）では、ユーザの習慣的な利用傾向に基づきアプリケーション単位でバッテリ消費量を推定する技術を開示している。しかし、一般的に、アプリケーションは多機能であり、アプリケーション内のどの機能を利用するかに応じて、ユーザの利用時間やハードウエアの処理負担などは異なり得る。このため、ユーザの習慣的な利用傾向に基づくアプリケーション単位でのバッテリ消費量の推定は、１日単位や１カ月単位といった比較的大きな時間単位での推定に適しているが、より小さい時間単位での推定には適していない。端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する技術においては、１日単位や１カ月単位といった比較的大きな時間単位でのバッテリ消費量の推定でなく、より小さい時間単位での推定が必要となる。
　また、従来技術（例えば非特許文献３）では、ＣＰＵやディスプレイといった電力消費量の大きなハードウエア部品の計測値をパラメータとする関数として、バッテリ消費量をモデル化している。この技術の場合、所定の処理を開始した後に、所定の処理実行時のハードウエア部品の計測値に基づきバッテリ消費量を推定できる。しかし、所定の処理を開始する前に推定し、ユーザに通知することはできない。
　本発明は、端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する技術を実現することを課題とする。
　本発明によれば、
　端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積部と、
　前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成部と、
　所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定部と、
　前記推定部の推定結果を出力する出力部と、
を有する処理装置が提供される。
　また、本発明によれば、
　コンピュータが、
　　端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積し、
　前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成し、
　所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定し、推定結果を出力する処理方法が提供される。
　また、本発明によれば、
　コンピュータを、
　　端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積手段、
　前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成手段、
　所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定手段、
　前記推定手段の推定結果を出力する出力手段、
として機能させるプログラムが提供される。
　本発明によれば、端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する技術が実現される。
本実施形態の処理装置のハードウエア構成の一例を示す図である。 本実施形態の処理装置の機能ブロックの一例を示す図である。 本実施形態の処理装置が処理する情報の一例を模式的に示す図である。 本実施形態の処理装置の処理の流れの一例を示すフローチャートである。 本実施形態の処理装置の処理の流れの一例を示すフローチャートである。 本実施形態の端末装置で表示される画面の一例を模式的に示す図である。 本実施形態の端末装置で表示される画面の一例を模式的に示す図である。 本実施形態の処理装置が処理する情報の一例を模式的に示す図である。 本実施形態の処理装置が処理する情報の一例を模式的に示す図である。
＜概要＞
　本実施形態の処理装置は、端末装置の状態と、その状態でアプリケーション内の各コンテンツを実行した場合のバッテリ消費量との関係を示す推定モデルを生成する。そして、処理装置は、当該推定モデルに基づき、推定時の端末装置の状態で各コンテンツを実行した場合のバッテリ消費量を推定し、ユーザに通知する。
　アプリケーションは、例えばゲームアプリケーションであるがこれに限定されない。アプリケーションは、実行可能な１つ又は複数のコンテンツを提供する。ユーザは、複数のコンテンツの中から１つを選択して実行する。例えば、野球に関するゲームアプリケーションの場合、「試合（９イニング）」、「試合（７イニング）」、「練習（打撃）」、「練習（守備）」、「練習（投球）」、「トレード」、「ドラフト」等のコンテンツが提供され得る。
　コンテンツは、アプリケーション内で実行可能な処理の１つである。このため、１つのコンテンツを実行している間におけるハードウエア処理負担の幅（最も処理負担が大きい時から最も処理負担が小さい時までの幅）は、複数のコンテンツを選択的に順次実行可能な１つのアプリケーションを実行している間におけるハードウエア処理負担の幅よりも小さい。また、１つのコンテンツの実行に要する時間（コンテンツを開始してから終了するまでの時間）の幅は、複数のコンテンツを選択的に順次実行可能な１つのアプリケーションの実行に要する時間の幅よりも小さい。
　端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知する技術において、このようなコンテンツ単位でバッテリ消費量を推定する技術を採用し、各コンテンツを実行する前に各コンテンツを実行した場合のバッテリ消費量を推定して通知するように構成することで、より精度が高く、有益な情報をユーザに提供することが可能となる。
＜ハードウエア構成＞
　次に、処理装置のハードウエア構成を説明する。処理装置は、ユーザが操作する端末装置であってもよいし、当該端末装置と通信するサーバであってもよい。端末装置は、例えば、スマートフォン、タブレット端末、スマートウォッチ、携帯電話、携帯ゲーム機、ノートパソコン等のような可搬型の端末装置であるが、これに限定されない。
　処理装置が備える各機能部は、任意のコンピュータのＣＰＵ（Central Processing Unit）、メモリ、メモリにロードされるプログラム、そのプログラムを格納するハードディスク等の記憶ユニット（あらかじめ装置を出荷する段階から格納されているプログラムのほか、ＣＤ（Compact Disc）等の記憶媒体やインターネット上のサーバ等からダウンロードされたプログラムをも格納できる）、ネットワーク接続用インターフェイスを中心にハードウエアとソフトウエアの任意の組合せによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。
　図１は、処理装置のハードウエア構成を例示するブロック図である。図１に示すように、処理装置は、プロセッサ１Ａ、メモリ２Ａ、入出力インターフェイス３Ａ、周辺回路４Ａ、バス５Ａを有する。周辺回路４Ａには、様々なモジュールが含まれる。なお、処理装置は周辺回路４Ａを有さなくてもよい。
　処理装置は、物理的及び論理的に１つの装置で構成されてもよい。処理装置は、物理的及び／又は論理的に分かれた複数の装置で構成されてもよい。この場合、複数の装置各々が上記ハードウエア構成を備えることができる。
　バス５Ａは、プロセッサ１Ａ、メモリ２Ａ、周辺回路４Ａ及び入出力インターフェイス３Ａが相互にデータを送受信するためのデータ伝送路である。プロセッサ１Ａは、例えばＣＰＵ、ＧＰＵ（Graphics Processing Unit）などの演算処理装置である。メモリ２Ａは、例えばＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などのメモリである。入出力インターフェイス３Ａは、入力装置、外部装置、外部サーバ、外部センサ等から情報を取得するためのインターフェイスや、出力装置、外部装置、外部サーバ等に情報を出力するためのインターフェイスなどを含む。入力装置は、例えばキーボード、マウス、マイク等である。出力装置は、例えばディスプレイ、スピーカ、プリンター、メーラ等である。プロセッサ１Ａは、各モジュールに指令を出し、それらの演算結果をもとに演算を行うことができる。
＜機能構成＞
　次に、処理装置の機能構成を説明する。図２に、処理装置１０の機能ブロック図の一例を示す。図示するように、処理装置１０は、情報蓄積部１１と、推定モデル生成部１２と、推定部１３と、出力部１４と、記憶部１５とを有する。
　情報蓄積部１１は、端末装置にインストールされたアプリケーション内のコンテンツを実行した時の端末装置の状態を示す実行時状態情報、及び、コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、履歴情報として記憶部１５に蓄積する。アプリケーションが複数のコンテンツを提供する場合、情報蓄積部１１は、コンテンツ毎に、実行時状態情報及びバッテリ情報を記憶部１５に蓄積する。
　処理装置１０が端末装置である場合、情報蓄積部１１は、自装置が備えるセンサや機能を介して自装置に関する実行時状態情報及びバッテリ情報を取得する。一方、処理装置１０が端末装置と通信するサーバである場合、情報蓄積部１１は、端末装置が収集したその端末装置に関する実行時状態情報及びバッテリ情報を、インターネット等のネットワークを介して端末装置から受信する。
　端末装置の状態を示す実行時状態情報は、取得可能な情報であって、バッテリ消費量に影響し得る任意の情報を含むことができる。例えば、実行時状態情報としては、端末装置にインストールされているＯＳ（operating system）の種類、通信ネットワークの接続方式、ディスプレイの輝度、バックグラウンドで起動中のアプリケーションの種類、ＣＰＵ使用率、ネットワーク通信量（byte/second）等が例示されるが、これらに限定されない。
　コンテンツを実行した時のバッテリ消費量は、コンテンツ開始時のバッテリ残量とコンテンツ終了時のバッテリ残量とに基づき算出可能である。
　図３に、実行時状態情報及びバッテリ情報を示す履歴情報の一例を模式的に示す。図示する例では、コンテンツＩＤと、コンテンツの実行を開始した日時であるコンテンツ開始日時（Timestart）と、コンテンツの実行を終了した日時であるコンテンツ終了日時（Timeend）と、コンテンツ開始日時におけるバッテリ残量（Energystart）と、コンテンツ終了日時におけるバッテリ残量（Energyend）と、コンテンツ実行時のＯＳの種類（Ｋ１（ＯＳ））と、コンテンツ実行時の通信ネットワークの接続方式（Ｋ２（Network））と、端末装置の種類（Ｋｎ（UA））とが互いに紐付けられている。
　ここで、図４のフローチャートを用いて、情報蓄積部１１が実行する処理の流れの一例を説明する。ここでは、処理装置１０が端末装置であるものとする。
　情報蓄積部１１は、コンテンツの実行開始を監視している（Ｓ１０）。情報蓄積部１１は、コンテンツの実行開始を検出すると（Ｓ１０のＹｅｓ）、その時点の端末装置の状態（実行時状態情報）やバッテリ残量を示す開始時状態情報を取得する（Ｓ１１）。そして、情報蓄積部１１は、取得した開始時状態情報を、実行開始されるコンテンツのコンテンツＩＤに紐付けて記憶部１５が記憶する履歴情報（図３参照）に登録する（Ｓ１２）。
　その後、情報蓄積部１１は、そのコンテンツの実行終了を監視する（Ｓ１３）。情報蓄積部１１は、コンテンツの実行終了を検出すると（Ｓ１３のＹｅｓ）、その時点の端末装置のバッテリ残量を示す終了時状態情報を取得し（Ｓ１４）、記憶部１５が記憶する履歴情報（図３参照）に登録する（Ｓ１５）。
　情報蓄積部１１は当該処理を繰り返す。結果、図３に示すような履歴情報が蓄積されていく。なお、処理装置１０がサーバである場合、例えば、端末装置が図４のフローチャートで示す処理を実行し、端末装置内に履歴情報を蓄積する。そして、端末装置は、任意のタイミングで、自装置内に蓄積した履歴情報をサーバに送信する。その他、端末装置は図４のフローチャートで示す処理を実行し、Ｓ１１及びＳ１４で開始時状態情報及び終了時状態情報を取得すると、リアルタイム処理で取得した情報をサーバに送信してもよい。そして、サーバが、受信した開始時状態情報及び終了時状態情報を自装置内に登録してもよい。
　図２に戻り、推定モデル生成部１２は、記憶部１５に蓄積された履歴情報（実行時状態情報及びバッテリ情報）に基づき、「端末装置の状態を示す情報」から「コンテンツを実行したときのバッテリ消費量」を推定する推定モデルを生成する。
　推定モデルは、例えば、端末装置の状態を示す情報と、当該状態でコンテンツを実行したときのバッテリ消費量（＝（Energystart）－（Energyend））とを紐付けた教師データに基づく任意の機械学習で生成されたモデルであってもよい。この場合、推定モデルの出力は、コンテンツを実行したときのバッテリ消費量となる。その他、推定モデルは、端末装置の状態を示す情報と、コンテンツを実行する前のバッテリ残量（Energystart）と、コンテンツを実行した後のバッテリ残量（Energyend）とを紐付けた教師データに基づく任意の機械学習で生成されたモデルであってもよい。この場合、推定モデルの出力は、コンテンツを実行した後のバッテリ残量となる。なお、いずれの場合も、バッテリ消費量を推定している。
　その他、推定モデルは、端末装置の状態を示す情報と、当該状態でコンテンツを実行した場合のバッテリ消費量との関係を示すテーブルをパターンマッチング等で照合し、キー（端末装置の状態を示す情報）に紐付くバッテリ消費量を特定するモデルであってもよい。その他、推定モデルは、端末装置の状態を示す情報と、コンテンツを実行する前のバッテリ残量（Energystart）と、コンテンツを実行した後のバッテリ残量（Energyend）との関係を示すテーブルをパターンマッチング等で照合し、キー（端末装置の状態を示す情報及びコンテンツを実行する前のバッテリ残量（Energystart））に紐付くバッテリ消費量を特定するモデルであってもよい。
　その他、推定モデルは、相関量を計量するためのベクトルに写像する等の手法を用いるモデルであってもよい。
　なお、アプリケーションが複数のコンテンツを提供する場合、推定モデル生成部１２は、コンテンツ毎に推定モデルを生成することができる。
　推定部１３は、所定の推定タイミングで端末装置の状態を示す推定時状態情報を取得し、推定時状態情報と推定モデルとに基づき、推定時状態情報で示される状態の端末装置でコンテンツを実行したときのバッテリ消費量を推定する。
　推定時状態情報は、実行時状態情報と同種の情報を含む。推定時状態情報としては、例えば、端末装置にインストールされているＯＳの種類、通信ネットワークの接続方式、ディスプレイの輝度、バックグラウンドで起動中のアプリケーションの種類等が例示されるが、これらに限定されない。また、推定モデルの内容によっては、推定時のバッテリ残量が推定時状態情報に含まれる。
　処理装置１０が端末装置である場合、推定部１３は、自装置が備えるセンサや機能を介して自装置に関する推定時状態情報を取得する。一方、処理装置１０が端末装置と通信するサーバである場合、推定部１３は、端末装置が収集したその端末装置に関する推定時状態情報を、インターネット等のネットワークを介して端末装置から受信する。
　出力部１４は、推定部１３の推定結果を出力する。処理装置１０が端末装置である場合、出力部１４は、端末装置が備えるディスプレイやスピーカ等の出力装置を介して、推定結果を出力する。一方、処理装置１０が端末装置と通信するサーバである場合、出力部１４は、推定結果を端末装置に送信する。そして、端末装置は、自装置が備えるディスプレイやスピーカ等の出力装置を介して、受信した推定結果を出力する。
　ここで、図５のフローチャートを用いて、推定部１３及び出力部１４による処理の流れの一例を説明する。
　まず、推定部１３は、バッテリ消費量を推定する推定タイミングの到来を監視している（Ｓ２０）。推定タイミングの具体例は後述する。
　そして、推定タイミングの到来を検出すると（Ｓ２０のＹｅｓ）、推定部１３は、推定対象のコンテンツのコンテンツＩＤを取得する（Ｓ２１）。推定対象のコンテンツは１つであってもよいし、複数であってもよい。推定対象のコンテンツの具体例は後述する。
　また、推定部１３は、その時点における端末装置の状態を示す推定時状態情報を取得する（Ｓ２２）。推定部１３は、推定時のバッテリ残量を推定時状態情報として取得してもよい。なお、Ｓ２１及びＳ２２の処理順はこれに限定されない。
　次いで、推定部１３は、Ｓ２１で取得したコンテンツＩＤに対応する推定モデルと、Ｓ２２で取得した推定時状態情報とに基づき、当該推定時状態情報で示される状態の端末装置で、当該コンテンツＩＤで示されるコンテンツを実行した場合のバッテリ消費量を推定する（Ｓ２３）。
　次いで、出力部１４は、Ｓ２３の推定処理で得られた推定結果を出力する（Ｓ２５）。
　ここで、推定タイミング、推定対象のコンテンツ及び推定結果の出力画面の一例を説明する。
「例１」
　当該例では、推定タイミングは、コンテンツの実行を開始する入力を受付ける受付画面を表示する入力（ユーザ入力）を受付けたタイミングである。そして、当該例では、推定対象のコンテンツは、当該受付画面で実行を開始する入力を受付可能なコンテンツである。
　推定部１３は、当該受付画面を表示する入力の受付に応じて推定時状態情報を取得し、推定時状態情報と推定モデルとに基づき、その推定時状態情報で示される状態の端末装置で上記推定対象のコンテンツ各々を実行したときのバッテリ消費量を推定する。
　そして、出力部１４は、当該受付画面において、各コンテンツに紐づけて推定結果を表示させる。図６に、当該例で端末装置に表示される当該受付画面の一例を模式的に示す。当該例では、アプリケーションは、野球に関するゲームアプリケーションである。そして、当該受付画面は、「試合（９イニング）」、「試合（７イニング）」、「練習（打撃）」、「練習（守備）」、「練習（投球）」等のコンテンツの実行を開始する入力を受付け可能になっている。そして、各コンテンツに紐付けて、その時点で各コンテンツを実行した場合のバッテリ消費量の予測結果が示されている。
「例２」
　当該例では、推定タイミングは、アプリケーションが提供する複数のコンテンツ各々のバッテリ消費量の一覧を表示する入力（ユーザ入力）を受付けたタイミングである。そして、当該例では、推定対象のコンテンツは、アプリケーションが提供するすべてのコンテンツである。
　推定部１３は、当該一覧を表示する入力の受付に応じて推定時状態情報を取得し、推定時状態情報と推定モデルとに基づき、その推定時状態情報で示される状態の端末装置で上記推定対象のコンテンツ各々を実行したときのバッテリ消費量を推定する。
　そして、出力部１４は、当該一覧を表示する画面において、各コンテンツに紐づけて推定結果を表示させる。図７に、当該例で端末装置に表示される画面の一例を模式的に示す。当該画面では、アプリケーションが提供するすべてのコンテンツ各々に紐付けて、その時点で各コンテンツを実行した場合のバッテリ消費量の予測結果が示されている。
　なお、図６及び図７では、満充電電力量に対する消費電力量の割合でバッテリ消費量を示しているが、その他の手法でバッテリ消費量を示してもよい。しかし、一般的な端末装置では、満充電電力量に対する残電力量の割合でバッテリ残量を示す。このため、図示するような手法でバッテリ消費量を示すと、ユーザがバッテリ残量とバッテリ消費量とを対比しやすくなり好ましい。
　また、図６及び図７では、出力部１４は、推定結果としてコンテンツ実行によるバッテリ消費量を示しているが、その他、コンテンツ実行後のバッテリ残量の予測値を推定結果として出力してもよい。
＜変形例１＞
　当該変形例では、アプリケーションが提供する複数のコンテンツは、バッテリの消費の仕方が類似するもの同士でグループ化される。そして、図８に示すような、各コンテンツがどのグループに属するかを示すグループ情報が処理装置１０内に予め記憶されている。
　推定モデル生成部１２は、グループ毎に、グループに属するコンテンツの履歴情報（実行時状態情報及びバッテリ情報）に基づき上述した推定モデルを生成する。すなわち、変形例では、コンテンツ毎でなく、グループ毎に推定モデルが生成される。
　そして、推定部１３は、バッテリ消費量を推定する対象のコンテンツが属するグループを特定し、特定したグループに対応する推定モデルに基づき、その時点でそのコンテンツを実行したときのバッテリ消費量を推定する。
＜変形例２＞
　処理装置１０がサーバである場合、処理装置１０は、複数のユーザの端末装置から履歴情報（実行時状態情報及びバッテリ情報）を取得することができる。処理装置１０は、ユーザ毎に各ユーザの履歴情報を処理して推定モデルを生成してもよいし、複数のユーザの履歴情報をまとめて処理して複数のユーザ毎に推定モデルを生成してもよい。また、複数のユーザの属性情報（性別、年令、国籍、アプリケーションの利用歴（年数等）、端末装置の情報（メーカ、型番、ＯＳ、通信サービスを提供するキャリア等）等）が処理装置１０内に登録されている場合、処理装置１０は、属性情報が一致又は類似するユーザ同士でグループ化し、グループ毎に各グループに属するユーザの履歴情報をまとめて処理してグループ毎に推定モデルを生成してもよい。
＜変形例３＞
　処理装置１０は、少なくとも実行時状態情報及びバッテリ情報に基づき推定モデルを生成し、少なくとも実行時状態情報及びバッテリ情報に基づきバッテリ消費量を推定する。処理装置は、実行時状態情報及びバッテリ情報以外の情報であって、バッテリ消費量に影響し得るその他の情報を、例えば外部装置（端末装置以外の装置）から取得し、当該情報をさらに利用して推定モデルの生成、及び、バッテリ消費量の推定を行ってもよい。例えば、使用している部品（ハードウエア）ごとに推定モデルを構築しておき、当該推定モデルと、実行時状態情報に基づく推定モデルとを組み合わせてバッテリ消費量を推定してもよい。
＜実施例＞
　次に、本実施形態の処理装置１０をより具体化した実施例を説明する。
　本実施例は、ユーザがこれから実行するコンテンツを選択するための画面に遷移した時に、その画面に選択可能に表示されるコンテンツを実行した場合のバッテリ消費量を予測し、予測結果をその画面に表示する方式である。例えば、ユーザが２つのコンテンツ（００１－ＮＯＲＭＡＬと００１－ＨＡＲＤ）を選択可能な画面に遷移した時、本実施例の処理装置１０は、「００１－ＮＯＲＭＡＬはバッテリの０．５％を消費」、「００１－ＨＡＲＤはバッテリの０．８％を消費」のように、コンテンツごとにその時に実行した場合のバッテリ消費量を予測し、予測した結果を、コンテンツを開始するためのボタンと合わせて表示する。
　本実施例の処理装置１０のシステムアーキテクチャは、コンテンツごとのバッテリ消費量を予測するための推定フェーズと、予測のための推定モデルを生成するための学習フェーズとに分けられる。ここでは、本実施例の処理装置１０を実現するための３つのモジュールについて説明した後、学習フェーズと推定フェーズについて詳述する。
「モジュール」
　本実施例の処理装置１０は、［Ｍ１］Learning Moduleと、［Ｍ２］Model Dataと、［Ｍ３］Inference Moduleとの３モジュールを含んで構成される。
　［Ｍ１］Learning Moduleは、開発者やユーザがコンテンツを実行した時の履歴情報（実行時状態情報及びバッテリ情報）を入力として、コンテンツごとのバッテリ消費量を予測するためのモデルをＭ２として出力する関数である。Ｍ１の入力となる履歴情報は、以下の式（１）及び式（２）に示すような時系列データとして定義できる。
Figure JPOXMLDOC01-appb-M000001
Figure JPOXMLDOC01-appb-M000002
　ここで、Itemtは、コンテンツごとの履歴情報の項目である。ContentIDは、コンテンツごと、もしくは、コンテンツのグループごとにあらかじめ設定されたユニークな識別子である。Timestartは、当該コンテンツを開始した時刻である。Timeendは、当該コンテンツを終了した時刻である。Energystartは、当該コンテンツを開始した時刻におけるバッテリ残量である。Energyendは、当該コンテンツを終了した時刻におけるバッテリ残量である。Energystart及びEnergyendの値は、［０，１］の範囲の浮動小数点数とする。Energystart及びEnergyendの値が０のとき、バッテリが完全に放電した状態（残量０）であることを示す。そして、Energystart及びEnergyendの値が１のとき、バッテリが完全に充電された状態（満充電状態）であることを示す。
　(Ki,Vi)は、ハードウエアの構成要素やセンサ情報の種類を示すKeyと、その値を示すValueのペアである。このKey-Valueペアは、例えば、ＯＳの種類のような静的な情報や、ネットワーク接続方式のような動的に変化する情報を含む。この履歴情報の実装方法として、開発者が、リリース前に、デバッグやテストのために蓄積したものであっても良いし、ユーザが、以前に同じ端末で実行した時に蓄積したものであっても良い。履歴情報の実装の例は、図３で示される。
　［Ｍ２］Model Dataは、Ｍ１によって出力され、Ｍ３の入力となる推定モデルデータである。本モジュールの具体的な実装は、Ｍ１の実装に応じて設定されるが、例を図９に示す。図９の詳細は、後述する。
　［Ｍ３］Inference Moduleは、ユーザがこれから実行するコンテンツを選択するための画面に遷移した時に、その画面に表示される予定のコンテンツのリスト（ContentIDのリスト）と、その時刻におけるスマートフォンのバッテリ残量（Energystart）と、その時刻におけるハードウエアの構成要素やセンサ情報（［(K1,V1)，・・・・(Km,Vm)］）を入力として受け取り、受け取った各ContentIDを対象に、入力の時点からユーザが当該コンテンツを実行したと仮定して、実行し終わった時のバッテリ残量（Energyend）を予測して出力する関数である。当該関数は以下の式（３）及び式（４）のように示される。
Figure JPOXMLDOC01-appb-M000003
Figure JPOXMLDOC01-appb-M000004
　本モジュールの具体的な実装は、Ｍ１の実装に応じて設定されるが、本実施例では、最も単純な実施例として、テーブルを用いたパターンマッチングによる推定を行う方式を採用する。他の実装例として、特徴量を抽出して何らかの機械学習を行っても良いし、相関量を計量するためのベクトルに写像しても良い。
「学習フェーズ」
　次に、本実施例の学習フェーズを説明する。本実施例の学習フェーズでは、開発者やユーザがゲームのコンテンツを実行した時の履歴情報（実行時状態情報及びバッテリ情報）を用いて、パターンマッチングによる推定を行うためのテーブルを生成する。例えば、本実施例の処理装置１０は、図３に示すような履歴情報に基づき、以下の式（５）のように定義されるテーブルを生成する。
Figure JPOXMLDOC01-appb-M000005
　式（５）で定義されるテーブルの一例は、図９に示される。図９に示すテーブルは、ContentIDごとにEnergystartを０．０５刻みで区切り、(Ki,Vi)とEnergyendを対応付けたものである。ここで、(Ki,Vi)は、収集されたデータのうち、推定のために必要なものだけ使用し、その他は使用しないといった選別を行っても良い。
　次に、学習フェーズにおける処理の流れを説明する。
「Ｓｔｅｐ１」: 開発者やユーザがアプリケーションを開始した時、処理装置１０は、履歴情報を格納するためのテーブルHistoryを作成する。処理装置１０は、アプリケーションの異常終了に備えて、永続化できる媒体にHistoryを作成することが好ましいが、実装の要件に応じてメモリ上に作成しても良い。
　処理装置１０は、過去に作成したHistoryが残っていた時、後述するＳｔｅｐ４の学習モデルの更新の処理を実行し、Historyを空にする。
「Ｓｔｅｐ２」:開発者やユーザが、開発者によって識別子を定義されているコンテンツの実行を開始した時、処理装置１０は、Ｓｔｅｐ１で作成したHistoryに新たなエントリItemtを追加し、次の４種の情報を記録する。
・開始されたコンテンツのContentID
・当該コンテンツを開始した時刻Timestart
・当該コンテンツを開始した時刻におけるバッテリ残量Energystart
・当該コンテンツを開始した時刻におけるハードウエアの構成要素やセンサ情報［(K１,V１)・・・・(Kｎ,Vｎ)］
「Ｓｔｅｐ３」：開発者やユーザが、開発者によって識別子を定義されているコンテンツの実行を終了した時、処理装置１０は、Ｓｔｅｐ１で作成し、Ｓｔｅｐ２で更新したHistoryに、次の２種の情報を記録する。
・当該コンテンツを終了した時刻Timeend
・当該コンテンツを終了した時刻におけるバッテリ残量Energyend
「Ｓｔｅｐ４」:開発者やユーザが、ゲームの実行を中断あるいは終了した時、処理装置１０は、Historyに記録したItemt１・・・Itemtkを使って推定モデルを更新し、更新が完了したらHistoryを空にする。
　本実施例では、処理装置１０は、Historyに記録したItemt１・・・Itemtkを使って図９に示すテーブルPatternMatchTableを更新する。具体的には、処理装置１０は、Historyを走査し、各要素Itemtについて、以下に示すＳｔｅｐ４－１、Ｓｔｅｐ４－２を実行する。
「Ｓｔｅｐ４－１」:まず、処理装置１０は、コンテンツの開始時刻におけるバッテリ残量Energystartについて、［０、０．０５、０．１０、・・・０．９５、１．００］のように、複数のインデックス値Energystartindexを設定している。そして、処理装置１０は、Historyに記録された複数のItemtの中の処理対象のItemtのEnergystartに最も近いEnergystartindexを特定する。例えば上述のように０．０５刻みでEnergystartindexを設定した場合において、処理対象のItemtのEnergystartが０．７６である場合、０．７５が最も近いEnergystartindexとして特定される。
　さらに、処理装置１０は、処理対象のItemtのハードウエアの構成要素やセンサ情報（［(K1,V1)，・・・・(Km,Vm)］）の中から、推定時に必要となる要素を取り出す。最も単純には同じ配列を使っても良い。
「Ｓｔｅｐ４－２」：次に、処理装置１０は、図９に示すPatternMatchTableにおいて、ContentID及び［(K1,V1)，・・・・(Km,Vm)］の列の値が処理対象のItemtに含まれる値と一致し、かつ、Energystartの列の値がＳｔｅｐ４－１で特定したEnergystartindexと一致する行を探す。
　当該行が存在しない場合、処理装置１０は、処理対象のItemtに含まれるContentID、Energyend、［(K1,V1)，・・・・(Km,Vm)］、及び、Ｓｔｅｐ４－１で特定したEnergystartindexを新たな行として図９に示すPatternMatchTableに追加する。
　一方、当該行が存在する場合、処理装置１０は、その行のEnergyendの値を、処理対象のItemtに含まれるEnergyendの値に基づき更新する。例えば、バッテリの劣化を考慮し、その行のEnergyendの値を、最新の値（処理対象のItemtに含まれるEnergyendの値）に更新してもよい。
　その他、その行のEnergyendの値を、その行のEnergyendの値と処理対象のItemtに含まれるEnergyendの値の統計値（最大値、最小値、平均値等）に更新してもよい。その他、その行のEnergyendの値を、その行のEnergyendの値及び処理対象のItemtに含まれるEnergyendの値各々に各々の重み係数を掛けた値の合計値に更新してもよい。
「推定フェーズ」
　次に、本実施例の推定フェーズを説明する。本実施例は、ユーザがこれから実行するコンテンツを選択するための画面に遷移した時に、その画面に表示される予定のコンテンツごとに、パターンマッチングによってバッテリ消費量を予測する。具体的には、パターンマッチングのためのテーブル（図９）において、Energyendのカラムを除いて、推定時の時刻における端末装置のバッテリ残量と、当該時刻におけるハードウエアの構成要素やセンサ情報がマッチする行を探す。
　例えば、ＯＳ００１の端末装置を利用するユーザが、ＮＷ００１の接続方式でネットワークに接続している時に、２つのコンテンツ（００１－ＮＯＲＭＡＬと００１－ＨＡＲＤ）が表示される画面に遷移したとする。この時の端末装置のバッテリ残量が０．７６であったとすると、処理装置１０は、図９に示すPatternMatchTableの中から、ContentIDが「００１－ＮＯＲＭＡＬ」又は「００１－ＨＡＲＤ」にマッチし、K1（OS）が,「ＯＳ００１」にマッチし、K2（Network）が「ＮＷ００１」にマッチし、かつ、Energystartの値が「０．７６」に最も近い行を探す。
　結果、ContentID「００１－ＮＯＲＭＡＬ」に対応して上から２番目の行が特定され、ContentID「００１－ＨＡＲＤ」に対応して上から５番目の行が特定される。結果、処理装置１０は、「００１－ＮＯＲＭＡＬを実行した場合、バッテリ残量が０．７３になる」と推定し、「００１－ＨＡＲＤをプレイした場合、バッテリ残量が０．６９になる」と推定する。処理装置１０は、この結果を画面に反映する際に、「００１－ＮＯＲＭＡＬを実行した場合、バッテリ残量が７３％になる」、「００１－ＨＡＲＤをプレイした場合、バッテリ残量が６９％になる」のように、ユーザが理解しやすい形式に変換して表示しても良い。
　次に、推論フェーズにおける処理の流れを説明する。
「Ｓｔｅｐ１」：ユーザが、コンテンツを選択する画面に遷移する入力を行うと、処理装置１０は、当該画面に表示される予定のコンテンツの一覧を、ContentIDの配列として取得する。また、処理装置１０は、端末装置のＯＳから、当該時刻におけるバッテリ残量Energystartと、当該時刻におけるハードウエアの構成要素やセンサ情報［(K1,V1)，・・・・(Km,Vm)］を受け取る。
「Ｓｔｅｐ２」：処理装置１０は、受け取ったContentIDの配列を走査し、ContentIDごとに、各コンテンツを実行した後のバッテリ残量を予測する。具体的には、処理装置１０は、図９に示すPatternMatchTableを用いて、マッチする行を探す。最も単純には、本システムは、Exact-Matchする行がある場合だけ、プレイ後のバッテリ残量を当該行に含まれるEnergyendであると予測する。そして、Exact-Matchする行がない場合、処理装置１０は、「バッテリ消費量が不明」という結果を出力しても良い。
　例えば、処理装置１０は、ContentIDの配列に含まれるContentIDごとに、以下に示すＳｔｅｐ２－１乃至２－３を実行してもよい。
「Ｓｔｅｐ２－１」：処理装置１０は、図９に示すPatternMatchTableにおいて、処理対象のContentIDと一致する全ての行を特定する。当該行が１つも存在しない場合、処理装置１０は、処理対象のContentIDで識別されるコンテンツを実行した場合のバッテリ消費量は「不明」という結果を出力する。当該行が１でも存在する場合、処理装置１０は、次のステップの処理を実行する。
「Ｓｔｅｐ２－２」：処理装置１０は、Ｓｔｅｐ２－１で特定した行の中から、Ｓｔｅｐ１で取得したバッテリ残量Energystartが最も近い行を特定する。具体的には、各行が示すEnergystartとＳｔｅｐ１で取得したバッテリ残量Energystartとの差の絶対値が最も小さい行を特定する。特定した行が１つである場合、処理装置１０は、処理対象のContentIDで識別されるコンテンツを実行した場合のバッテリ消費量はその特定した行が示すEnergyendという結果を出力する。一方、特定した行が複数ある場合、処理装置１０は、Ｓｔｅｐ２－３を実行する。
「Ｓｔｅｐ２－３」：処理装置１０は、Ｓｔｅｐ２－２で特定した行の中から、Ｓｔｅｐ１で取得したハードウエアの構成要素やセンサ情報［(K1,V1)，・・・・(Km,Vm)］が最も近い行を特定する。なお、このｍ次元の情報の近さ（類似度）を算出する手法は特段制限されず、あらゆる手法を採用できる。特定した行が１つである場合、処理装置１０は、処理対象のContentIDで識別されるコンテンツを実行した場合のバッテリ消費量はその特定した行が示すEnergyendという結果を出力する。一方、特定した行が複数ある場合、処理装置１０は、任意の手法で特定した複数の行の中から１つを特定する。そして、処理装置１０は、処理対象のContentIDで識別されるコンテンツを実行した場合のバッテリ消費量はその特定した行が示すEnergyendという結果を出力する。
「Ｓｔｅｐ３」：処理装置１０は、ContentIDごとのバッテリ消費量の推定結果をアプリシステムに渡す。アプリシステムは、受け取った推定結果を反映した画面を描画し、ディスプレイに表示する。この時、アプリシステムは、アプリ実行後のバッテリ残量を見積もった結果をそのまま表示しても良いし、アプリ実行前のバッテリ残量からアプリ実行後のバッテリ残量を引くことで算出したバッテリ消費量を表示してもよい。
＜作用効果＞
　処理装置１０は、端末装置を用いた所定の処理を実行した場合のバッテリ消費量を所定の処理を実行する前にユーザに通知することができる。当該技術によれば、ユーザは、所定の処理を実行した場合のバッテリ消費量を考慮して、当該処理を今実行するか否か等を判断することができる。
　また、処理装置１０は、コンテンツ単位でバッテリ消費量を推定し、その結果をユーザに通知する。コンテンツは、アプリケーション内で実行可能な処理の１つである。このため、１つのコンテンツを実行している間におけるハードウエア処理負担の幅（最も処理負担が大きい時から最も処理負担が小さい時までの幅）は、複数のコンテンツを選択的に順次実行可能な１つのアプリケーションを実行している間におけるハードウエア処理負担の幅よりも小さい。また、１つのコンテンツの実行に要する時間（コンテンツを開始してから終了するまでの時間）の幅は、複数のコンテンツを選択的に順次実行可能な１つのアプリケーションの実行に要する時間の幅よりも小さい。よって、コンテンツ単位でバッテリ消費量を推定する場合、アプリケーション単位でバッテリ消費量を推定するよりも、推定精度が高くなる。結果、推定精度の高い有益な情報をユーザに提供することができる。
　また、処理装置１０は、例えば何度も繰り返し実行することを前提としたアプリケーションの周回コンテンツを対象に、コンテンツ毎にバッテリ消費量の傾向を学習した推定モデルを用いてバッテリ消費量を推定し、ユーザがコンテンツを選択する時にその推定結果を通知することができる。これにより、ユーザの主体的なバッテリ制御が可能となる。
　また、処理装置１０は、ハードウエア/ソフトウエアの状況という形でデータを取得することにより、自然に実行環境を考慮することができるため、多様な携帯端末に適用することが可能である。
　また、処理装置１０は、コンテンツＩＤのみを考慮し、具体的なコンテンツの内容を全く考慮しないので、アプリケーションの開発者は、本実施形態の処理を実現するための特別な設定を追加する必要がない。このため、既存のコンテンツをそのまま利用することができ、かつ、新規コンテンツを従来通りに追加すると、自動的に、処理装置１０にバッテリ消費量を推定させることができる。このように、既存のゲーム開発パイプラインを変更せずに適用可能である。
　また、処理装置１０は、端末装置側で実現されてもよいし、サーバ側で実現されてもよい。すなわち、ユーザの端末装置で集めたデータを、そのままエッジサイドでの学習に利用しても良いし、サーバに送信してクラウドサイドでの学習に利用しても良い。これにより、開発者は、アプリケーションの特性に応じて、学習のリアルタイム性やユーザプライバシーの保全を重視するならエッジサイドの学習を、端末の負荷低減を重視するならクラウドサイドの学習を、それぞれ選択することができる。このように、処理装置１０は、汎用性が高い。
　以下、参考形態の例を付記する。
１．　端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積部と、
　前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成部と、
　所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定部と、
　前記推定部の推定結果を出力する出力部と、
を有する処理装置。
２．　前記アプリケーションでは複数のコンテンツが実行可能であり、
　前記情報蓄積部は、前記コンテンツ毎に、前記実行時状態情報及び前記バッテリ情報を前記記憶手段に蓄積し、
　前記推定モデル生成部は、前記コンテンツ毎に、前記コンテンツ各々を実行した時のバッテリ消費量を推定する前記推定モデルを生成し、
　前記推定部は、前記コンテンツ各々を実行したときのバッテリ消費量を推定する１に記載の処理装置。
３．　前記アプリケーションでは複数のコンテンツが実行可能であり、
　前記情報蓄積部は、前記コンテンツ毎に、前記実行時状態情報及び前記バッテリ情報を前記記憶手段に蓄積し、
　前記推定モデル生成部は、グループ毎に、少なくとも、前記グループに属する前記コンテンツの前記実行時状態情報及び前記バッテリ情報に基づき前記推定モデルを生成し、
　前記推定部は、バッテリ消費量を推定する対象の前記コンテンツである対象コンテンツが属する前記グループを特定し、特定した前記グループに対応する前記推定モデルに基づき、前記対象コンテンツを実行したときのバッテリ消費量を推定する１に記載の処理装置。
４．　前記端末装置が、前記コンテンツの実行を開始する入力を受付ける受付画面を表示する入力を受付けると、
　前記推定部は、前記受付画面を表示する入力の受付に応じて前記端末装置の状態を示す前記推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定し、
　前記出力部は、前記受付画面において、前記コンテンツに紐づけて前記推定結果を表示させる１から３のいずれかに記載の処理装置。
５．　コンピュータが、
　　端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積し、
　少なくとも、前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成し、
　所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定し、推定結果を出力する処理方法。
６．　コンピュータを、
　　端末装置にインストールされたアプリケーション内のコンテンツを実行した時の前記端末装置の状態を示す実行時状態情報、及び、前記コンテンツを実行したときのバッテリ消費量を示すバッテリ情報を取得し、記憶手段に蓄積する情報蓄積手段、
　前記記憶手段に蓄積された前記実行時状態情報及び前記バッテリ情報に基づき、前記端末装置の状態を示す情報から前記コンテンツを実行したときのバッテリ消費量を推定する推定モデルを生成する推定モデル生成手段、
　所定の推定タイミングで前記端末装置の状態を示す推定時状態情報を取得し、前記推定時状態情報と前記推定モデルとに基づき、前記推定時状態情報で示される状態の前記端末装置で前記コンテンツを実行したときのバッテリ消費量を推定する推定手段、
　前記推定手段の推定結果を出力する出力手段、
として機能させるプログラム。
　この出願は、２０２０年５月１日に出願された日本出願特願２０２０－０８１０５１号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　１Ａ　　プロセッサ
　２Ａ　　メモリ
　３Ａ　　入出力Ｉ／Ｆ
　４Ａ　　周辺回路
　５Ａ　　バス
　１０　　処理装置
　１１　　情報蓄積部
　１２　　推定モデル生成部
　１３　　推定部
　１４　　出力部
　１５　　記憶部

Claims (6)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202180046177.3A CN115843274A (zh) 2020-05-01 2021-04-30 处理装置、处理方法和程序
US18/051,741 US20230088429A1 (en) 2020-05-01 2022-11-01 Processing device, processing method, and program

Applications Claiming Priority (2)

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

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/051,741 Continuation US20230088429A1 (en) 2020-05-01 2022-11-01 Processing device, processing method, and program

Publications (1)

Publication Number Publication Date
WO2021221157A1 true WO2021221157A1 (ja) 2021-11-04

Family

ID=77057515

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/017184 WO2021221157A1 (ja) 2020-05-01 2021-04-30 処理装置、処理方法及びプログラム

Country Status (4)

Country Link
US (1) US20230088429A1 (ja)
JP (1) JP6913791B1 (ja)
CN (1) CN115843274A (ja)
WO (1) WO2021221157A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012068803A (ja) * 2010-09-22 2012-04-05 Nec Personal Computers Ltd 消費電力推定システム、情報処理装置、消費電力推定方法、プログラム
JP2013228902A (ja) * 2012-04-26 2013-11-07 Sony Corp 情報処理装置及び方法、プログラム、並びに情報処理システム
US20170279697A1 (en) * 2016-03-22 2017-09-28 Intel Corporation Control device for estimation of power consumption and energy efficiency of application containers
JP2020028196A (ja) * 2018-08-13 2020-02-20 三菱ロジスネクスト株式会社 判定装置および判定方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012068803A (ja) * 2010-09-22 2012-04-05 Nec Personal Computers Ltd 消費電力推定システム、情報処理装置、消費電力推定方法、プログラム
JP2013228902A (ja) * 2012-04-26 2013-11-07 Sony Corp 情報処理装置及び方法、プログラム、並びに情報処理システム
US20170279697A1 (en) * 2016-03-22 2017-09-28 Intel Corporation Control device for estimation of power consumption and energy efficiency of application containers
JP2020028196A (ja) * 2018-08-13 2020-02-20 三菱ロジスネクスト株式会社 判定装置および判定方法

Also Published As

Publication number Publication date
JP2021175447A (ja) 2021-11-04
US20230088429A1 (en) 2023-03-23
JP6913791B1 (ja) 2021-08-04
CN115843274A (zh) 2023-03-24

Similar Documents

Publication Publication Date Title
EP3502880B1 (en) Method for preloading application, storage medium, and terminal device
EP3502889B1 (en) Method and device for preloading application, storage medium, and terminal device
US20230409349A1 (en) Systems and methods for proactively providing recommendations to a user of a computing device
EP3198429B1 (en) Heterogeneous thread scheduling
WO2019119969A1 (en) Method for preloading application and terminal device
US10903665B2 (en) Usage data based battery charge or discharge time determination
EP3542243B1 (en) Dynamic energy storage device discharging
US20160248125A1 (en) Heterogeneous Battery Cell Switching
CN107885545B (zh) 应用管理方法、装置、存储介质及电子设备
US20170270433A1 (en) Information processing apparatus, information processing system, information processing method, and computer-readable recording medium
CN107608778B (zh) 应用程序管控方法、装置、存储介质及电子设备
CN113590199A (zh) 指令调度方法、人工智能芯片、计算机设备和存储介质
JP6913791B1 (ja) 処理装置、処理方法及びプログラム
WO2023129340A1 (en) Automated generation of agent configurations for reinforcement learning
CN111913759A (zh) 控制应用程序执行的方法、装置、计算设备和介质
CN113064660A (zh) 设备控制方法、装置、电子设备及存储介质
US20220245447A1 (en) Systems and methods for quantization aware training of a neural network for heterogeneous hardware platform
CN113439263A (zh) 应用清理方法、装置、存储介质及电子设备
US10789548B1 (en) Automatic re-training of offline machine learning models
CN112997150B (zh) 应用程序的管理方法、装置、存储介质及电子设备
US20240004737A1 (en) Evaluation and adaptive sampling of agent configurations
Draa et al. Machine learning for improving mobile user satisfaction
US11816134B1 (en) System and method for reduction of data transmission in dynamic systems using causal graphs
US20240177023A1 (en) System and method for managing inference model distributions in dynamic system
CN113127159B (zh) 应用程序处理方法、装置、电子设备以及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21797721

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21797721

Country of ref document: EP

Kind code of ref document: A1