WO2022187689A1

WO2022187689A1 - Systems and methods for evaluating battery aging with data analytics

Info

Publication number: WO2022187689A1
Application number: PCT/US2022/018999
Authority: WO
Inventors: Mao-Ter Chen; Pai-Han HUANG; Yen-Liang Kuo
Original assignee: Innopeak Technology, Inc.
Priority date: 2022-03-04
Filing date: 2022-03-04
Publication date: 2022-09-09

Abstract

Systems and methods are provided that improve analysis of battery aging and predictive capabilities based thereon, as well as implementations that can improve current battery usage and prolong the life of the battery. While the description herein focuses on aging of lithium-ion batteries, it will be understood that the description similarly applies to other rechargeable battery types, regardless of chemical or material composition, structure, and so forth.

Description

SYSTEMS AND METHODS FOR EVALUATING BATTERY AGING WITH DATA

ANALYTICS

Technical Field

[0001] The present application relates generally to analyzing aspects of batteries for mobile electronic devices and, more particularly, to better understanding and predicting battery state of health (SOH) and battery aging.

Background

[0002] Energy consumption in mobile devices can critically affect user enjoyment of the device. Extensive research has been conducted in recent years for modeling of mobile devices, and also for various energy management schemes. However, previous work has rarely addressed the issues associated with battery hardware itself, such as the aging phenomenon, which significantly affects the usage time of mobile devices.

[0003] Battery aging is defined as the performance or health of a battery that tends to deteriorate or diminish gradually due to irreversible physical and chemical changes that take place with usage. For example, different batteries of the same type may derive different usage times for the same workload. Battery aging also leads to reduced usage times for mobile devices, which can decrease the usability of the device due to the significance of battery degradation. Frequent recharging may even cause device failure. [0004] The battery aging may also be related to chemical characteristics of the lithium ion (Li-ion) batteries commonly employed in modern devices. For example, batteries may consume more power than what is required by mobile devices due to the effects of heating on batteries. Additionally, the charging and discharging time of the battery may fluctuate due to high density of particles of Li-ion moving slowly at high battery levels. Estimation of battery aging is thus challenging due to the complicated characteristics of batteries used today.

Brief Description of the Drawings

[0005] The present disclosure, in accordance with one or more various embodiments, is described in detail with reference to the following figures. The figures are provided for purposes of illustration only and merely depict typical or example embodiments.

[0006] FIG. 1 depicts an example battery monitoring system configured to collect and analyze battery aging data from a plurality of user equipments (UEs), in accordance with embodiments described in the present disclosure.

[0007] FIG. 2 illustrates quantifying battery life of a plurality of UEs, in accordance with embodiments described in the present disclosure.

[0008] FIG. 3 illustrates trends that may be determined from the data provided by the plurality of UEs, in accordance with embodiments described in the present disclosure.

[0009] FIG. 4 illustrates correlating a cumulative user percentage with a battery SoH metric of a plurality of UEs, in accordance with embodiments described in the present disclosure. [0010] FIG. 5 is an example process flow that may be implemented with various features of embodiments described in the present disclosure.

[0011] FIG. 6 depicts a block diagram of an example computer system in which various of the embodiments described herein may be implemented.

[0012] The figures are not exhaustive and do not limit the present disclosure to the precise form disclosed. These illustrative embodiments are mentioned not to limit or define the disclosure, but to provide examples to aid understanding thereof. Additional embodiments are discussed in the Detailed Description, and further description is provided there.

Detailed Description

[0013] Rechargeable batteries provide power for mobile and stationary electronic devices. The rechargeable nature reduces waste by enabling a user of an electronic device to recharge a discharged rechargeable battery as needed based on use of the electronic device. This cyclical use of the rechargeable battery can cause degradation of the rechargeable battery over time.

[0014] Many electronic devices employ lithium-ion type rechargeable batteries that employ lithium-ions to generate power through a chemical reaction. The lithium-ion batteries are desirable because they provide a high energy density relative to other rechargeable battery types, which provides higher energy capacities in smaller battery packages than the other rechargeable battery types. Additionally, lithium-ion batteries experience lower self-discharge rates and lower maintenance needs as compared to many other rechargeable battery types.

[0015] However, one disadvantage of lithium-ion batteries is that lithium-ion batteries suffer from aging. This aging can reduce an energy capacity of a lithium-ion battery due to passing of time as well as charge-discharge cycles. Furthermore, various aspects related to the charge-discharge cycles can impact the aging of the lithium-ion battery. For example, quickly charging such that the lithium-ion battery experiences high temperatures may cause the lithium-ion battery to age more quickly than if slowly charged at lower temperatures.

[0016] Various entities have studied the chemical characteristics of lithium-ion batteries and how to combine chemical elements to overcome limitations of lithium-ion batteries, as well as evaluating the battery aging process based on monitoring correlative indexes, such as charging or discharging speed, cycles, and so forth. However, the research on a lifecycle and lifetime of lithium-ion batteries is limited with respect to battery aging in mobile devices and may lack quantities of real-world data that can verify results generated from the research. For example, the research may utilize test cases that employ simulation and simulated results that may be biased to the entity performing the research and may not reflect real-world user experiences. Furthermore, the existing research and evaluative methods may lack consideration of the divergence of lithium-ion batteries at production, for example, due of variance of the production mechanism, user behavior, environmental impacts, and the like. [0017] Embodiments of the application provide distinct systems, apparatuses, and methods for improving analysis of battery aging and predictive capabilities based thereon, as well as implementations that can improve current battery usage and prolong the life of the battery. While the description herein focuses on aging of lithium-ion batteries, it will be understood that the description similarly applies to other rechargeable battery types, regardless of chemical or material composition, structure, and so forth.

[0018] Particularly, the disclosed techniques enable the collection of data from various user equipments that relates to consumption of energy from a battery of the user equipments. For example, the system may receive data from each of a plurality of user equipments (UEs) where the data is regarding one or more factors related to battery aging and state of health of a battery of the UE and the plurality of UEs comprises a number of classes of UE where each UE belongs to at least one class of UE. The system may also generate a model for predicting battery state of health (SOH) metrics based on the received data regarding the one or more factors. The system may also predict battery state of health metrics fora class of UEs of the plurality of UEs. The system may also generate an association between the battery SOH metrics and the class of UEs and determine a user metric based on the association between the battery SOH metrics and the class of UEs.

[0019] Using these and other system features, a value or action associated with the user equipment may be implemented. For example, the system can determine that the user equipment may be operational for a discrete amount of time and adjust the value of the user equipment based on the predicted amount of time it has left to operate. In another example, the battery may be calibrated or otherwise adjusted based on the determined battery SOH.

[0020] Technical improvements are realized throughout the application. For example, quantifying battery aging can help prolong battery life. The system can generate data to help identify how a battery degrades and can generate less charge capacity, especially in comparison to a similar battery that might last longer under the same usage. Additionally, the data may be used as a reference to improve battery use with compromising on the device performance (e.g. display brightness), rendering rate, and/or system-on-a-chip (SOC) scheduling, or as a trade-off between power and performance.

[0021] The system can also help guide future UE designs. For example, the revised UE model can be based on evaluating various UE components, selecting particular component vendors that align with longer battery life, and analyze the battery warranty period in comparison with the battery worn-out rate. With the prediction of battery deterioration, the system can help an entity prepare ahead to accommodate predicted battery degradation. In some examples, by monitoring data analytics that are formulated by the data logging described in the application, the quality of the battery could be tracked and entity may be capable of taking prompt actions before users perceive the degraded battery or user experience (e.g., causing more frequent charging of the battery).

[0022] FIG. 1 depicts an example battery monitoring system configured to collect and analyze battery aging data from a plurality of user equipments (UEs), in accordance with embodiments described in the present disclosure. In this illustration, user equipment (UE)

100 may communicate via network 140 with battery monitoring system 150.

[0023] In the example of FIG. 1, UE 100 is shown as a handheld user device, and more specifically a smartphone. However, UE 100 may be implemented as various other wireless devices that are used directly by an end-user to communicate and equipped with telecommunication functions, such as voice, video, and text. For example, UE 100 may also be implemented as a cellular telephone, a laptop computer equipped with a mobile broadband adapter, or another mobile computing device. Accordingly, UE 100 may be capable of supporting enhanced data services, voice (e.g., voice calls over 5G New Radio (NR), VoNP, VoLTE, etc.), video, and other telecommunication functions that are commonly employed by subscribers to broadband cellular networks, such as network 140.

[0024] UE 100 may comprise various components, including system-on-a-chip (SOC) 102, memory 104, input/output (I/O) 106, wireless transceivers 108, baseband 110, battery 120, and battery logging module 122.

[0025] SOC 102 is an integrated circuit that integrates a central processing unit (CPU), memory, input/output ports, secondary storage, radio modem, wireless networking capabilities, and/or digital camera hardware and firmware, and/or a graphics processing unit (GPU) on a single substrate or microchip. In some examples, SOC 102 may comprise digital, analog, mixed-signal, and often radio frequency signal processing functions. In some examples, memory may be placed separately from SOC 102 (e.g., illustrated as memory 104) and SOC 102 may have no memory or flash storage incorporated within the substrate. [0026] SOC 102 can include an operating system that provides an interface between hardware (e.g., the input/output mechanisms and a processor executing instructions retrieved from computer-readable medium) and software components of UE 100. Example operating systems include ANDROID^®, CHROME^®, IOS^®, MAC^® OS X^®, WINDOWS^® 7^®, WINDOWS^® PHONE 7^®, SYMBIAN^®, BLACKBERRY^®, WEBOS^® (e.g., including a variety of UNIX operating systems), or a proprietary operating system for computerized devices. The operating system may provide a platform for the execution of application programs that facilitate interaction between UE 100 and the user. UE 100 also may include applications, computing sub-systems, and hardware.

[0027] Memory 104 is to store various machine-readable instructions in a random- access memory (RAM), cache, dynamic storage devices, read only memory (ROM) 408, or other static or dynamic storage devices, each of which may be coupled to a bus for storing information and instructions to be executed by SOC 102. Additional detail on memory 104 is provided with FIG. 6.

[0028] I/O 106 may include one or more interfaces for receiving or providing information. In some examples, I/O 106 may include a display for displaying the information to the user, one or more input devices including a mouse or keyboard, or microphone for receiving audio input. Additional detail on I/O 106 is provided with FIG. 6.

[0029] Transceiver 108 is a circuit in a network interface controller (NIC) that may combine transmitter and receiver functionality (e.g., to transmit and/or receive different signals, including Wi-Fi, 5G, etc.). The signals may be processed by SOC 102. For example, transceiver 108 may perform modulation to convert electrical digital signals into either RF or light (e.g., as analog signals) through the transmitter functionality. Amplifiers in transceiver 108 may increase the magnitude of the signals prior to departing an antenna (not shown). As a receiver, transceiver 108 may detect the signals and demodulates them into data types applicable to UE 100.

[0030] Baseband processor 110 (e.g., baseband radio processor, BP, BBP) is a circuit also in the NIC that manages one or more radio functions using its own RAM or firmware. Baseband processor 110 may operate separately from Wi-Fi and Bluetooth radios. In some examples, baseband processor 110 is fabricated using complementary metal-oxide- semiconductor (CMOS) or RF CMOS technology.

[0031] Battery 120 is a lithium-ion battery that is rechargeable. The life of battery 120 may be shortened every time it is allowed to discharge. In some examples, battery 120 is made out of lithium, graphite, or nanowires, and rely on the chemistry of lithium to provide power to operate UE 100.

[0032] Battery logging module 122 is a device-side application that can generate data associated with one or more components of UE 100. For example, the data may comprise one or more factors related to battery aging and state of health of battery 120, including battery full charge capacity (FCC), state-of-health (SoH), and charging cycle-count (CC). The data may be different based from each UE that generates this data based on a corresponding user's usage, divergence of batteries on productions, and impact of environmental conditions and changes. By introducing the logging system on portable device, various conditions of a battery's state may be trackable to reflect the battery health dynamically.

[0033] Battery logging module 122 may receive the data from a battery gas gauge via SOC 102, including the FCC, SoH, and CC. The battery gas gauge may operate like a battery meter. SOC 102 may record relevant battery information and provide the battery information in response to a query from battery logging module 122.

[0034] The battery full charge capacity (FCC) may be determined by the mAh (milliampere-hours) capacity rating, which corresponds with the storage capacity available for battery 120. As an illustrative example, a battery with a capacity rating of 1800 mAh could deliver a current of 1800mA for one hour, which higher mAh ratings for the same battery type corresponding with longer run times for similar operations and tasks.

[0035] The state-of-health (SoH) may be determined by identifying a difference between a battery being degraded with cell aging and a fresh battery. The SoH describes the maximum storage capacity available for battery under the certain fixed load current and temperature (e.g., 25 C). It is defined as the ratio of the maximum battery charge to its rated capacity. The SoH may be calculated and characterized by the battery gas gauge and, in some examples, adjusted with calibrations.

[0036] Specific actions may be correlated to SoH. For example, a user may operate a resource-intensive application at UE 100 that degrades the battery more rapidly than a less resource-intensive application. Consistent use of the resource-intensive application may degrade the battery faster than non-use. [0037] The charging cycle-count (CC) may be determined by identifying the number of times that UE 100 is charged and discharged with the full cycle (e.g., 0% to 100% and vice versa). In some examples, if the charging takes multiple times to completely reach to 100%, the CC measurement may only consider a single charge cycle. The CC may be determined using the battery gas gauge data (e.g., by aggregating and/or accumulating the data).

[0038] Other information may be determined and provided to battery monitoring system 150 as well. For example, the data may comprise a battery level at the beginning of charging and a battery level at the end of charging, an amount of time that the battery is charged (e.g., at one time, averaged over multiple times, etc.), a duration that the UE is not in use, a duration that the display of the UE is active, and/or environmental factors surrounding the UE (e.g., temperature). This and other data may be determined using one or more sensors embedded or in communication with UE 100.

[0039] Battery logging module 122 may utilize a relatively small amount of processing power and memory to execute its operations relative to other applications implemented at UE 100. For example, battery logging module 122 may conduct as low as less than 0.1% CPU loading. As such, battery related information, such as SOH, CC, and FCC may be capable to be assembled and utilized for further aging modeling in an efficient way.

[0040] In some examples, the data may be aggregated, filtered, reduced, or otherwise decreased. For example, the data may be limited based on a maximum threshold value of allowable data size. This data limitation may be implemented by limiting the times with which the data is determined by the system (e.g., once per hour, once per day, etc.) to create an effective time cadence. The limit on the allowable data size may allow for the data to still be captured while considering the availability of system resources at UE 100. In other words, data may be limited to limit resource consumption and maintain operability of other system functions at UE 100 (e.g., other software applications).

[0041] In some examples, the data may be uploaded to battery monitoring system 150 (or similar cloud repository) as a batch file on a predetermined time interval. This process may reduce the complexity and capacity of the collected information from the plurality of UEs, including UE 100.

[0042] In accordance with some embodiments, battery logging module 122 may also be used to remedy battery issues and perform actions on UE 100, as described in more detail below. This can help prevent negative user experiences by a user that operates UE 100.

[0043] Network 140 is part of the radio access network (RAN) deployment that provides voice, data, and/or messaging services to mobile subscribers, such as the user of UE 100. Network 140 can also serve as a gateway to other networks, such as the public switched telephone network or a public cloud that supports voice services. Various technology deployments can provide connectivity between UE 100 and battery monitoring system 150 via the network 140, such 2G/3G, 4G, 4G LTE, 5G, Wi-Fi and similar technologies. For example, UE 100 may be used by a user to upload photos via the network 140 to battery monitoring system 150. Thus, UE 100 may comprise hardware, software applications, and the like, which allows UE 100 to be configured for multimedia telephone services including audio, video, and text, and voice calls via any of these technologies. [0044] Battery monitoring system 150 may comprise various components, including processor 152, memory 154, I/O 156, and computer readable media 160 that communicate via a bus or other communication mechanism. One or more modules or engines may be implemented with computer readable media, including user equipment (UE) classification module 162, prediction engine 164, battery metrics module 166, and action engine 168.

[0045] Processor 152 may be one or more general purpose microprocessors for processing and executing information. Memory 154 may be main memory, such as a random- access memory (RAM), cache and/or other dynamic storage devices, for storing information and instructions to be executed by processor 152, and/or read only memory (ROM) or other static storage device for storing static information and instructions for processor 152. Memory 154 may also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 152. Such instructions, when stored in storage media accessible to processor 152, render battery monitoring system 150 into a special-purpose machine that is customized to perform the operations specified in the instructions.

[0046] I/O 156 may include one or more interfaces for receiving or providing information with UE 100. In some examples, I/O 156 may include a display for displaying the information to an administrative user or one or more engines incorporated with CRM 160. Additional detail on I/O 156 is provided with FIG. 6.

[0047] UE classification module 162 is configured to receive data from each of a plurality of user equipments (UEs), including UE 100, from battery logging module 122 on each device. The data may include, for example, including battery full charge capacity (FCC), state-of-health (SoH), and charging cycle-count (CC). The data may be transmitted via network 140 and received at battery monitoring system 150. The data may comprise one or more factors related to battery aging and state of health of a battery of the UE.

[0048] Each of the plurality of UEs may correspond with a number of classes of UEs, where each UE belongs to at least one class of UE. In some examples, the classification may be determined by hardware or software variants of the user equipment, including the SoC model, memory, storage size, screen size, and the like. The configuration of the subcomponents may help define whether the data from its battery logging module 122 belong to the same class as other devices. The variants and configurations may also be collected by battery logging module 122 and saved as metadata for the usage of reference to the classifications.

[0049] Prediction engine 164 is configured to generate a model for predicting battery state of health (SOH) metrics based on the received data regarding the one or more factors. For example, the model may be based on a statistical distribution on one or more indicators instead of a constant factor (e.g., FCC, SOH, CC, etc.). This distribution may illustrate a SoH or other factor for the plurality of UEs grouped by the classification of each of the UEs.

[0050] The parameters to define the distribution of the model (e.g., mean and variance) may be expected to shift over the time. In some examples, a minimum amount of data and granularity of the data may be received prior to generating the model. This may correspond with the theoretical assumption that more associated information with fine granularity and frequent updates can provide a better understanding of modeling. However, the data may be limited to not restrict operability of other system functions at UE 100, which can create a trade-off between the log quality and availability of system resources.

[0051] An illustrative example of quantifying battery life of battery 120 of a plurality of UEs is illustrated in FIG. 2. For example, prediction engine 164 can help quantify the battery life by using the data provided by the UEs as impacting battery aging and determine the distribution of each data factor among a plurality of UEs, including UE 100.

[0052] In some examples, a statistical analysis may be implemented to quantify the behavior of battery aging. FIG. 2 illustrates modeling and predicting battery life to a threshold precision level over different platforms. Each of the platforms may correspond with classes of similar devices, including a first class 210, second class 220, and third class 230. The distribution of key factors (e.g., SoH) among all classifications of UEs is illustrated as gradually shifting downward. The shift downward could be described by mean and variance at any point over the time. In this modeling examples, the mean battery health (e.g., the value while the battery of one class of the plurality of UEs is fully charged) for the third class 230 is 85.23% at day 400. Further, a spread variance is also expected and disperse more over the time.

[0053] In some examples, a machine learning (ML) model may be implemented to quantify the behavior of battery aging. For example, the data provided by each UE, including battery full charge capacity (FCC), state-of-health (SoH), charging cycle-count (CC), or other information, may be provided as input to a trained ML model and the output may identify a confidence value that a particular data factor corresponds with the battery degradation. The ML model may be based on various implementations, including a linear regression model.

When training the ML model, pairs of training data may be provided to the ML model to correlate the weights and biases of the model with particular factors that have more determination on the speed of battery degradation over time.

[0054] FIG. 3 illustrates additional trends that may be determined from the data provided by the plurality of UEs, in accordance with embodiments described in the present disclosure. For example, a first modeling 310 illustrates a SoH mean over time and a second modeling 320 illustrates a SoH variance over time.

[0055] Battery metrics module 166 also configured to determine a user metric based on the association between the battery SOH metrics and the user satisfaction in terms of the power.

[0056] An illustrative example of correlating a cumulative user percentage with a battery consumption metric of a plurality of UEs is illustrated in FIG. 4. In this illustration, the energy consumption of the portable device per day by each user is illustrated as a cumulative distribution function (CDF). For example, the maximum data shown at 15000mAh and 100% means this user consumes the most energy, 15000mAh a day, among all UEs. Assuming a brand new battery with 100% SOH in the device is 5000mAh nominally, the vertical red line represents how many users' devices can operate a full day without a second charging. In this illustration, it is 70% and this number can be interpreted to the satisfaction rate of all users. As the SoH degrades to 90%, the available battery capacity becomes 4500mAh (5000 * 0.9).

The percentage of UEs that are able to perform all of their desired operations with the UE in a single day drops to 63%, leading to 7% degradation of the user satisfaction. In other words, one-hundred percent battery charge or 1.0 battery SoH may satisfy a decreasing percentage of cumulative UEs as the battery degrades over time and more and more UEs will need to recharge during each day to perform their desired operations.

[0057] Returning to FIG. 1, action engine 168 is configured to a determine a value or action associated with the user equipment that may be implemented. For example, action engine 168 can determine that UE 100 may be operational for a discrete amount of time and adjust the value of UE 100 based on the predicted amount of time it has left to operate. CPU frequency scheduling, display auto-brightness, or rendering strategy of the animation can be the potential actions to take in the UEs accordingly.

[0058] In another example, the battery of UE 100 may be calibrated or otherwise adjusted based on the determined battery SOH. For example, if the calibrations or other strategic actions are introduced to handle the degradation of battery SoH after the UE is released, they can be done by over-the-air (OTA) programming to implement the changes while the device is in use and/or without turning in the device one-by-one to the manufacturer (e.g., to prevent a poor user experience). In some examples, the construction of future batteries provided with UEs may be adjusted based on the predicted and measured use by previous users and related battery degrading.

[0059] FIG. 5 is a flow diagram illustrating a method 500 of detecting and improving a battery life for a class of UEs that can be performed by one or more components of UE 100 and/or battery monitoring system 150, such as a SOC 102 of UE 100, processor 152 of battery monitoring system 150, or other hardware or software component illustrated in FIG. 6 and described herein.

[0060] For example, the processor 152 can fetch, decode, and/or execute one or more instructions for performing various steps of the method 500. Various instructions (e.g., for performing one or more steps described herein) can be stored in non-transitory storage medium and/or corresponding control logic circuitry, where the term "non-transitory" does not encompass transitory propagating signals. "Non-transitory" as used herein refers to any media that store data and/or instructions that cause a machine to operate in a specific fashion. Such non-transitory media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks. Volatile media includes dynamic memory. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip orcartridge, and networked versions of the same. As described in detail below, machine- readable storage medium of the main memory 606, the ROM 608, and/or the storge 610 may be encoded with executable instructions, for example, instructions for executing steps of the method 500. Non-transitory media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between non-transitory media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 602 between the processor 404 and other components of the computer system 600. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

[0061] The method 500 may comprise a method of evaluating battery aging with data analytics in a plurality of UEs, including UE 100. Operations that make up the method 500 may be performed by battery monitoring system 150.

[0062] At block 510 of the method 500 comprises receiving data from each of a plurality of user equipments (UEs). As introduced above, the data may comprise data regarding one or more factors related to battery aging and state of health (SoH) of a battery of the UE and the plurality of UEs comprises a number of classes of UE where each UE belongs to at least one class of UE.

[0063] At block 520 the method 500 comprises generating a model for predicting battery state of health (SOH) metrics based on the received data regarding the one or more factors.

[0064] At block 530 the method 500 comprises predicting battery state of health metrics for a class of UEs of the plurality of UEs.

[0065] At block 540 the method 500 comprises generating an association between the battery SOH metrics and the class of UEs.

[0066] At block 550 the method 500 comprises determining a user metric based on the association between the battery SOH metrics and the class of UEs. [0067] At block 560 the method 500 comprises performing an action based on the user metric.

[0068] FIG. 6 depicts a block diagram of an example computer system 600 in which various features described herein may be implemented. The computer system 600 includes a bus 602 or other communication mechanism for communicating information, one or more hardware processors 604 coupled with bus 602 for processing information. Hardware processor(s) 604 may be, for example, one or more general purpose microprocessors.

[0069] The computer system 600 also includes a main memory 606, such as a random- access memory (RAM), cache and/or other dynamic storage devices, coupled to bus 602 for storing information and instructions to be executed by processor 604. Main memory 606 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 604. Such instructions, when stored in storage media accessible to processor 604, render computer system 600 into a special- purpose machine that is customized to perform the operations specified in the instructions.

[0070] The computer system 600 further includes a read only memory (ROM) 608 or other static storage device coupled to bus 602 for storing static information and instructions for processor 604. A storage device 610, such as a magnetic disk, optical disk, or USB thumb drive (Flash drive), etc., is provided and coupled to bus 602 for storing information and instructions.

[0071] The computer system 600 may be coupled via bus 602 to a display 612, such as a liquid crystal display (LCD) (or touch screen), for displaying information to a computer user. An input device 614, including alphanumeric and other keys, is coupled to bus 602 for communicating information and command selections to processor 604. Another type of user input device is cursor control 616, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 604 and for controlling cursor movement on display 612. In some embodiments, the same direction information and command selections as cursor control may be implemented via receiving touches on a touch screen without a cursor.

[0072] The computing system 600 may include a user interface module to implement a GUI that may be stored in a mass storage device as executable software codes that are executed by the computing device(s). This and other modules may include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.

[0073] In general, the word "component," "engine," "system," "database," data store," and the like, as used herein, can refer to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, C or C++. A software component may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python.

It will be appreciated that software components may be callable from other components or from themselves, and/or may be invoked in response to detected events or interrupts.

Software components configured for execution on computing devices may be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, magnetic disc, or any other tangible medium, or as a digital download (and may be originally stored in a compressed or installable format that requires installation, decompression or decryption prior to execution). Such software code may be stored, partially or fully, on a memory device of the executing computing device, for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM. It will be further appreciated that hardware components may be comprised of connected logic units, such as gates and flip- flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors.

[0074] The computer system 600 may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system 600 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 600 in response to processor(s) 604 executing one or more sequences of one or more instructions contained in main memory 606. Such instructions may be read into main memory 606 from another storage medium, such as storage device 610. Execution of the sequences of instructions contained in main memory

606 causes processor(s) 604 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

[0075] The term "non-transitory media," and similar terms, as used herein refers to any media that store data and/or instructions that cause a machine to operate in a specific fashion. Such non-transitory media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 610. Volatile media includes dynamic memory, such as main memory 606. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge, and networked versions of the same.

[0076] Non-transitory media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between non-transitory media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 602. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

[0077] The computer system 600 also includes a communication interface 618 coupled to bus 602. Communication interface 618 provides a two-way data communication coupling to one or more network links that are connected to one or more local networks. For example, communication interface 618 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 618 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or WAN component to communicated with a WAN). Wireless links may also be implemented. In any such implementation, communication interface 618 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0078] A network link typically provides data communication through one or more networks to other data devices. For example, a network link may provide a connection through local network to a host computer or to data equipment operated by an Internet Service Provider (ISP). The ISP in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet." Local network and Internet both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link and through communication interface 618, which carry the digital data to and from computer system 600, are example forms of transmission media.

[0079] The computer system 600 can send messages and receive data, including program code, through the network(s), network link and communication interface 618. In the Internet example, a server might transmit a requested code for an application program through the Internet, the ISP, the local network and the communication interface 618. [0080] The received code may be executed by processor 604 as it is received, and/or stored in storage device 610, or other non-volatile storage for later execution.

[0081] Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code components executed by one or more computer systems or computer processors comprising computer hardware. The one or more computer systems or computer processors may also operate to support performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS). The processes and algorithms may be implemented partially or wholly in application-specific circuitry. The various features and processes described above may be used independently of one another or may be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of this disclosure, and certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate, or may be performed in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The performance of certain of the operations or processes may be distributed among computer systems or computers processors, not only residing within a single machine, but deployed across a number of machines.

[0082] As used herein, a circuit might be implemented utilizing any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logical components, software routines or other mechanisms might be implemented to make up a circuit. In implementation, the various circuits described herein might be implemented as discrete circuits or the functions and features described can be shared in part or in total among one or more circuits. Even though various features or elements of functionality may be individually described or claimed as separate circuits, these features and functionality can be shared among one or more common circuits, and such description shall not require or imply that separate circuits are required to implement such features or functionality. Where a circuit is implemented in whole or in part using software, such software can be implemented to operate with a computing or processing system capable of carrying out the functionality described with respect thereto, such as computer system 00.

[0083] As used herein, the term "or" may be construed in either an inclusive or exclusive sense. Moreover, the description of resources, operations, or structures in the singular shall not be read to exclude the plural. Conditional language, such as, among others, "can," "could," "might," or "may," unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps.

[0084] Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. The presence of broadening words and phrases such as "one or more," "at least," "but not limited to" or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent.

Claims

Claims What is claimed is:

1. A battery monitoring system, comprising: a processor; and a memory operatively connected to the processor and including instructions that, when executed, cause the processor to: receive data from each of a plurality of user equipments (UEs), the data regarding one or more factors related to battery aging and state of health of a battery of the UE and the plurality of UEs comprises a number of classes of UE where each UE belongs to at least one class of UE; generate a model for predicting battery state of health (SOH) metrics based on the received data regarding the one or more factors; predict battery state of health metrics for a class of UEs of the plurality of UEs; generate an association between the battery SOH metrics and the class of UEs; determine a user metric based on the association between the battery SOH metrics and the class of UEs; and perform an action based on the user metric.

2. The battery monitoring system of claim 1, wherein the data regarding the one or more factors related to battery aging and state of health of the battery of the UE comprising a battery full charge capacity (FCC).

3. The battery monitoring system of claim 1, wherein the data regarding the one or more factors related to battery aging and state of health of the battery of the UE comprising a state- of-health (SoH).

4. The battery monitoring system of claim 1, wherein the data regarding the one or more factors related to battery aging and state of health of the battery of the UE comprising a charging cycle-count (CC).

5. The battery monitoring system of claim 1, wherein the instructions further cause the processor to generate an alert to provide to a display of each of the class of UEs, wherein the alert instructs the user to perform the action for improving battery performance of the UE.

6. A method comprising: receiving data from each of a plurality of user equipments (UEs), the data regarding one or more factors related to battery aging and state of health of a battery of the UE and the plurality of UEs comprises a number of classes of UE where each UE belongs to at least one class of UE; generating a model for predicting battery state of health (SOH) metrics based on the received data regarding the one or more factors; predicting battery state of health metrics for a class of UEs of the plurality of UEs; generating an association between the battery SOH metrics and the class of UEs; determining a user metric based on the association between the battery SOH metrics and the class of UEs; and performing an action based on the user metric.

7. The method of claim 6, wherein the data regarding the one or more factors related to battery aging and state of health of the battery of the UE comprising a battery full charge capacity (FCC).

8. The method of claim 6, wherein the data regarding the one or more factors related to battery aging and state of health of the battery of the UE comprising a state-of-health (SoH).

9. The method of claim 6, wherein the data regarding the one or more factors related to battery aging and state of health of the battery of the UE comprising a charging cycle-count

(CC).

BO

10. The method of claim 6, wherein the instructions further cause the processor to generate an alert to provide to a display of each of the class of UEs, wherein the alert instructs the user to perform the action for improving battery performance of the UE.

11. A non-transitory computer-readable storage medium storing a plurality of instructions executable by one or more processors, the plurality of instructions when executed by the one or more processors cause the one or more processors to: receive data from each of a plurality of user equipments (UEs), the data regarding one or more factors related to battery aging and state of health of a battery of the UE and the plurality of UEs comprises a number of classes of UE where each UE belongs to at least one class of UE; generate a model for predicting battery state of health (SOH) metrics based on the received data regarding the one or more factors; predict battery state of health metrics for a class of UEs of the plurality of UEs; generate an association between the battery SOH metrics and the class of UEs; determine a user metric based on the association between the battery SOH metrics and the class of UEs; and perform an action based on the user metric.

SI

12. The computer-readable storage medium of claim 11, wherein the data regarding the one or more factors related to battery aging and state of health of the battery of the UE comprising a battery full charge capacity (FCC).

13. The computer-readable storage medium of claim 11, wherein the data regarding the one or more factors related to battery aging and state of health of the battery of the UE comprising a state-of-health (SoH).

14. The computer-readable storage medium of claim 11, wherein the data regarding the one or more factors related to battery aging and state of health of the battery of the UE comprising a charging cycle-count (CC).

15. The computer-readable storage medium of claim 11, wherein the instructions further cause the processor to generate an alert to provide to a display of each of the class of UEs, wherein the alert instructs the user to perform the action for improving battery performance of the UE.