It's been about eight months since I reported on K.Mizra v. Samsung, a patent infringement case pending with the Landgericht Düsseldorf (Dusseldorf Regional Court) over a patent on a method to predict the remaining battery runtime of a mobile device.
I've checked on the status of that litigation again, and a spokeswoman for the Dusseldorf court has meanwhile confirmed that the trial (case no. 4c O 27/22; Presiding Judge: Sabine Klepsch) will be held on June 29, 2023. I would recommend to Samsung's competitors--other Android device makers--to dispatch lawyers and keep an eye on this case. Samsung may be the first company that has to defend itself against this patent, but my research indicates that Google requires all Android device makers to implement that kind of power consumption analysis.
The patent licensing firm that is asserting EP2174201 on a "method and system for predicting the power consumption of a mobile terminal" means business: last summer they won an infringement ruling in Munich against Niantic, the Google-Nintendo joint venture behind the popular Pokémon GO mobile game, over another patent that equally resulted from the research efforts of a reputable and sizeable Dutch organization named TNO (Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek; Netherlands Organisation for Applied Scientific Research).
What I find particularly interesting here is that Google contractually obligates Android device makers to take certain technical measures that--according to my understanding of the patent--likely result in acts of infringement. Google's Android compatibility rules have drawn regulatory scrutiny, particularly in the EU and India. The Competition Commission of India put it bluntly: device makers choose "between signing a non-negotiable [contract] and commercial failure." This blog is critical of Google's abuse of market power in various ways, but with respect to compatibility rules, I've consistently advocated distinguishing between specifications that clearly are in the interest of consumers and/or app developers, and those that use "(anti-)fragmentation" or other pretexts for exclusionary practices, such as by disadvantaging rival app stores, search engines, or map services.
The compatibility rule at issue here is non-abusive: no exclusion, self-preferencing, tying, or other market distortion. Apart from the infringement problem I'll discuss below, its effects are purely positive:
Users want to plan when and where to recharge their phones.
Device makers strives to provide the best user experience (UX) possible.
Google's Android competes with Apple's iOS on UX.
App makers like me know that if our software is a "power hog" (a term also used by Qualcomm in an interesting paper on the subject), some users may find out about it or read or hear about it, and delete our apps for that reason. In the worst case we face a stern warning from the gatekeeper--Google--that an app will be ejected from the Google Play Store unless a problem of excessive power consumption is addressed.
When we make apps, we obviously take a look at power consumption as we test pre-release versions of our software. It's pretty normal that an app is a power hog during the early stages of development, but energy efficiency is one of the most important aspects of optimization. As developers we know that our own usage pattern may differ greatly from real-world usage. That's why it's important that what the actual end users do is analyzed locally by Android. Google's Android Compatibility Definition (ACD) says:
A more accurate accounting and reporting of the power consumption provides the app developer both the incentives and the tools to optimize the power usage pattern of the application.
Google ensures that Android device makers measure and provide data points relating to power consumption. It's about the power drain (per unit of time) of what in the claim language of the patent-in-suit is called a "terminal activity", such as WiFi data transfers, cellular data transfers, CPU usage for certain computations, or using a display in ambient mode. Device makers presumably perform such measurement under laboratory conditions and generate a "per-component power profile" as Google calls this in its Android Compatibility Definition (ACD).
Those data points are then used on a device for the purpose of predicting the remaining battery runtime based on a user's particular usage pattern, which naturally evolves as a given user's preferences change and new apps (or new version of existing apps) may drain more or less battery power. Android keeps track of what in the claim language is called "user activities" such as watching a video, downloading a document, placing a voice call, or playing a particular game. Android also knows what terminal activities a given user activity involves. Based on
the terminal activities that different user activities entail,
a given user's usage pattern, which will trigger a particular mix of terminal activities, and
the power consumption of the various hardware components (found in the per-component power profile I mentioned before),
Android can then estimate the per-time power consumption during the remainder of the current battery cycle and, ultimately by a simple division, derive the remaining battery runtime.
Those non-negotiable Android compatibility rules are publicly accessible:
Handheld device implementations:
[8.4/H-0-1] MUST provide a per-component power profile that defines the current consumption value for each hardware component and the approximate battery drain caused by the components over time as documented in the Android Open Source Project site.
[8.4/H-0-2] MUST report all power consumption values in milliampere hours (mAh).
[8.4/H-0-3] MUST report CPU power consumption per each process's UID. The Android Open Source Project meets the requirement through the uid_cputime kernel module implementation.
[8.4/H-0-4] MUST make this power usage available via the adb shell dumpsys batterystats shell command to the app developer.
[8.4/H] SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.
If Handheld device implementations include a screen or video output, they:
[8.4/H-1-1] MUST honor the android.intent.action.POWER_USAGE_SUMMARY intent and display a settings menu that shows this power usage.
A section of the Android documentation is dedicated to Power Profiles for Android. Among other things, it says:
"Resource consumption is associated with the application using the resource. When multiple applications simultaneously use a resource (such as wakelocks that prevent the system from suspending), the framework spreads consumption across those applications, although not necessarily equally."
Further above I mentioned last year's Pokémon GO (Niantic) patent infringement ruling. That game is a good example of an app that uses multiple hardware components: data transfers (sometimes WiFi, sometimes cellular), camera, display, sound. Augmented reality is a resource-intensive type of application, so the makers of such an app must to make a significant optimization effort to prevent it from becoming a power hog. They need the kind of data that Android can provide by virtue of apparently implementing what the patent-in-suit covers.
While Samsung and Niantic are not affiliated, there are some interesting parallels. Both cases were brought by K.Mizra, both patents were originally obtained by TNO, and Google makes the allegedly infringing software (Android in the Samsung case, the cloud components at issue in the Niantic case). The relationship between Google and either defendant is different, however: Google is a major shareholder in Niantic, while it has imposed its compatibility rules on Samsung, including the mandate of power consumption profiles that has apparently given rise to the Dusseldorf patent enforcement action.
