WEBVTT 00:00:00.000 --> 00:00:02.819 So picture this. You are sitting in a coffee 00:00:02.819 --> 00:00:06.099 shop right now, totally untethered, just streaming 00:00:06.099 --> 00:00:08.619 video or working on your laptop. Yeah, completely 00:00:08.619 --> 00:00:11.279 relying on those bleeding edge lithium ion batteries. 00:00:11.560 --> 00:00:14.220 Exactly. And you have this incredible freedom 00:00:14.220 --> 00:00:16.480 to just compute anywhere. It feels completely 00:00:16.480 --> 00:00:18.629 normal to us now. Right, you probably don't even 00:00:18.629 --> 00:00:20.570 think about it until, you know, that little battery 00:00:20.570 --> 00:00:23.089 icon turns red. Oh, I panic when it turns red. 00:00:23.489 --> 00:00:25.910 But the real reason your laptop hasn't died yet, 00:00:26.010 --> 00:00:28.949 it actually comes down to a completely forgotten 00:00:28.949 --> 00:00:32.810 microscopic software trick from way back in 1989. 00:00:33.170 --> 00:00:36.030 It really is one of the more obscure yet, I mean, 00:00:36.570 --> 00:00:38.649 highly consequential hidden histories in modern 00:00:38.649 --> 00:00:41.429 computing. Totally. And for our deep deck today, 00:00:41.729 --> 00:00:43.929 we are pulling from a single source, a really 00:00:43.929 --> 00:00:47.030 comprehensive Wikipedia article detailing a technology 00:00:47.030 --> 00:00:50.210 called Battery Max. Yeah, Battery Max, such a 00:00:50.210 --> 00:00:53.149 great 90s name. Oh, the best. So our mission 00:00:53.149 --> 00:00:56.070 today for you, the listener, is to uncover the 00:00:56.070 --> 00:00:58.750 wild trajectory of this specific piece of software. 00:00:58.950 --> 00:01:00.609 We are going to look at how it fundamentally 00:01:00.609 --> 00:01:04.269 changed the math on battery life. And how it 00:01:04.269 --> 00:01:07.900 somehow became a total commercial failure. despite 00:01:07.900 --> 00:01:11.040 being, you know, objectively superior technology 00:01:11.040 --> 00:01:13.260 at the time. Right, and then decades later how 00:01:13.260 --> 00:01:16.099 it miraculously resurrected from the archives 00:01:16.099 --> 00:01:19.480 to basically save the world's biggest tech giants 00:01:19.480 --> 00:01:22.859 in a massive high -stakes lawsuit. It is quite 00:01:22.859 --> 00:01:25.120 the journey. It really is. OK, let's unpack this. 00:01:25.420 --> 00:01:27.560 Because to understand the elegance of battery 00:01:27.560 --> 00:01:30.239 Macs, we really need to understand the architectural 00:01:30.239 --> 00:01:33.859 nightmare of early portable computers in the 00:01:33.859 --> 00:01:36.840 late 1980s. Oh, it was a nightmare. The landscape 00:01:36.840 --> 00:01:39.140 back then was incredibly primitive regarding 00:01:39.140 --> 00:01:41.420 power management. You have to remember, engineers 00:01:41.420 --> 00:01:43.500 were just starting to figure out how to untether 00:01:43.500 --> 00:01:45.620 these machines. Right. Laptops were basically 00:01:45.620 --> 00:01:47.840 like carrying around a cinder block. Exactly. 00:01:48.180 --> 00:01:51.030 The earliest laptops used these heavy, really 00:01:51.030 --> 00:01:53.370 inefficient batteries. And the way they tried 00:01:53.370 --> 00:01:56.290 to conserve that precious power relied entirely 00:01:56.290 --> 00:01:58.810 on hardware. Specifically, they used hardware 00:01:58.810 --> 00:02:01.769 inactivity timers. Which, I mean, it sounds sophisticated, 00:02:01.870 --> 00:02:05.069 but in practice, it was a totally blunt instrument. 00:02:05.329 --> 00:02:06.989 Oh, completely blunt. The motherboard's hardware 00:02:06.989 --> 00:02:08.930 would basically just sit there and monitor physical 00:02:08.930 --> 00:02:11.629 inputs. Like waiting for you to hit a key. Yeah, 00:02:11.629 --> 00:02:13.930 it would check if you were typing on the keyboard. 00:02:14.199 --> 00:02:16.759 Or it would check if the hard drive platters 00:02:16.759 --> 00:02:19.520 were physically spinning or like the serial ports, 00:02:19.539 --> 00:02:21.379 right? If the serial ports were transmitting 00:02:21.379 --> 00:02:24.199 data if it didn't detect any of those physical 00:02:24.199 --> 00:02:27.259 mechanical actions for a set period Usually several 00:02:27.259 --> 00:02:30.139 minutes it would finally assume the computer 00:02:30.139 --> 00:02:32.840 was idle and then it would trigger the switch 00:02:32.840 --> 00:02:36.530 to a lower power consumption state Exactly. It's 00:02:36.530 --> 00:02:39.530 basically like leaving the lights on in a massive 00:02:39.530 --> 00:02:42.729 empty warehouse for five full minutes just in 00:02:42.729 --> 00:02:44.810 case someone decides to walk back in. That is 00:02:44.810 --> 00:02:46.930 a great analogy. And you're doing this in a building 00:02:46.930 --> 00:02:50.270 that runs on a very finite, very quickly draining 00:02:50.270 --> 00:02:53.110 generator. I mean, it is a massive waste of energy. 00:02:53.110 --> 00:02:55.150 It really was. The computer is just sitting there, 00:02:55.250 --> 00:02:58.310 burning power, staring at a blinking DOS prompt, 00:02:58.789 --> 00:03:01.229 waiting for those minutes to tick by before it 00:03:01.229 --> 00:03:03.409 finally decides to turn the lights off. What's 00:03:03.409 --> 00:03:05.620 fascinating here is why the hardware was forced 00:03:05.620 --> 00:03:08.879 to operate that way. The motherboard was fundamentally 00:03:08.879 --> 00:03:11.719 blind to what the software was actually doing. 00:03:11.960 --> 00:03:14.159 Blind how? Like they couldn't talk to each other. 00:03:14.419 --> 00:03:17.400 Basically, yeah. The hardware only understands 00:03:17.400 --> 00:03:21.020 electrical signals and physical inputs. It has 00:03:21.020 --> 00:03:23.680 zero conceptual awareness of the operating system's 00:03:23.680 --> 00:03:26.240 tasks. Oh, I see. It doesn't know if the software 00:03:26.240 --> 00:03:28.520 is intensely calculating a massive spreadsheet 00:03:28.520 --> 00:03:31.819 in the background or if it is literally doing 00:03:31.819 --> 00:03:33.740 nothing but waiting for you to press the space 00:03:33.740 --> 00:03:36.389 bar. So the hardware is basically wearing a blindfold. 00:03:36.729 --> 00:03:38.469 It has to wait those several minutes just to 00:03:38.469 --> 00:03:40.550 be absolutely certain you are actually gone. 00:03:41.069 --> 00:03:43.229 Exactly. Because if the hardware timers were 00:03:43.229 --> 00:03:46.669 set too aggressively, say shutting down after 00:03:46.669 --> 00:03:49.870 10 seconds of no typing, they ran the risk of 00:03:49.870 --> 00:03:52.270 interrupting actual work. Oh, right. Because 00:03:52.270 --> 00:03:54.090 you might not be typing, but the computer is 00:03:54.090 --> 00:03:57.400 thinking. Yes. Imagine you initiate a complex 00:03:57.400 --> 00:03:59.860 database sort that takes 20 seconds to process. 00:04:00.159 --> 00:04:01.939 You aren't typing, so the hardware thinks you 00:04:01.939 --> 00:04:04.039 left. It just powers down the CPU right in the 00:04:04.039 --> 00:04:05.599 middle of the calculation. Right. That would 00:04:05.599 --> 00:04:08.599 be disastrous. So the engineers had to be super 00:04:08.599 --> 00:04:10.759 conservative. They left the timers at five or 00:04:10.759 --> 00:04:13.259 10 minutes, accepting the mass of power drain 00:04:13.259 --> 00:04:15.680 as a necessary evil to prevent system crashes. 00:04:16.040 --> 00:04:17.720 Well, the only way to solve a hardware blind 00:04:17.720 --> 00:04:20.180 spot is to put the intelligence into the software, 00:04:20.180 --> 00:04:22.300 right? Because the operating system actually 00:04:22.300 --> 00:04:24.870 knows what the programs are doing. Exactly. which 00:04:24.870 --> 00:04:28.610 leads us directly to August 1989 and a company 00:04:28.610 --> 00:04:31.350 called Digital Research. Okay, so who are these 00:04:31.350 --> 00:04:34.089 guys? Specifically, we are talking about their 00:04:34.089 --> 00:04:36.449 European Development Center in Hungerford in 00:04:36.449 --> 00:04:39.329 the UK. This is where two British engineers, 00:04:39.689 --> 00:04:42.930 Roger Alan Gross and John P. Constant conceptualized 00:04:42.930 --> 00:04:46.050 battery mags. And this got integrated into Docker 00:04:46.050 --> 00:04:49.550 DOS 5 .0, right? Around 1990? Yep, it was incorporated 00:04:49.550 --> 00:04:52.889 in 1990. And this made it the very first personal 00:04:52.889 --> 00:04:55.589 computer operating system to feature a native 00:04:55.589 --> 00:04:58.410 software -driven idle detection system for power 00:04:58.410 --> 00:05:00.649 management. The performance jump here is what 00:05:00.649 --> 00:05:02.370 really stands out in the source material for 00:05:02.370 --> 00:05:04.430 me. We just established that hardware timers 00:05:04.430 --> 00:05:06.410 took several minutes to figure out if you were 00:05:06.410 --> 00:05:09.709 idle. Right. Agonizingly slow. But battery max 00:05:09.709 --> 00:05:12.709 reduced that idle detection time down to microseconds. 00:05:12.730 --> 00:05:14.569 I mean, it could detect that you weren't actively 00:05:14.569 --> 00:05:16.870 typing, switch the computer into a low power 00:05:16.870 --> 00:05:19.449 state, and then wake it back up entirely seamlessly. 00:05:19.740 --> 00:05:22.680 and it could do this roughly 18 times a second. 00:05:23.000 --> 00:05:25.480 18 times a second, that is mind -blowing. The 00:05:25.480 --> 00:05:28.560 technique was officially named dynamic idle detection. 00:05:29.439 --> 00:05:31.899 Basically, the operating system halts the CPU 00:05:31.899 --> 00:05:34.860 for periods of just a few microseconds, pausing 00:05:34.860 --> 00:05:37.399 the power drain. And then a hardware event wakes 00:05:37.399 --> 00:05:39.319 it up. Yeah, like a keyboard interrupt occurs 00:05:39.319 --> 00:05:41.100 to immediately wake it back up so you don't even 00:05:41.100 --> 00:05:43.639 notice. So it's basically taking microscopic 00:05:43.639 --> 00:05:46.470 power naps. Between every single letter you type, 00:05:46.629 --> 00:05:48.569 the computer is going to sleep and waking back 00:05:48.569 --> 00:05:51.290 up. It's napping between the H and the E and 00:05:51.290 --> 00:05:53.850 hello. That's exactly what's happening. Well, 00:05:53.970 --> 00:05:55.689 logically, I mean, there has to be a hurdle here. 00:05:55.949 --> 00:05:58.769 If the software is shifting power states instantly, 00:05:59.410 --> 00:06:01.569 how does it differentiate between a program that 00:06:01.569 --> 00:06:04.730 is merely waiting for a user input and a program 00:06:04.730 --> 00:06:07.110 that is actively executing a background task? 00:06:07.310 --> 00:06:09.709 That is the big question. Because going to sleep 00:06:09.709 --> 00:06:12.889 while saving a file to the disk is just as disastrous 00:06:12.889 --> 00:06:15.209 as the hardware timer problem we just discussed. 00:06:15.589 --> 00:06:17.829 Right. And that is the core engineering challenge 00:06:17.829 --> 00:06:20.420 they had to solve. And it basically comes down 00:06:20.420 --> 00:06:23.819 to a layered model of detection software encapsulated 00:06:23.819 --> 00:06:26.740 into a DOS device driver. The IDLE driver? Yes. 00:06:26.899 --> 00:06:29.399 They call this driver IDLE. Spelled with dollar 00:06:29.399 --> 00:06:32.000 signs on both ends, which is deeply characteristic 00:06:32.000 --> 00:06:34.680 of 90s computing nomenclature. Oh, absolutely. 00:06:34.879 --> 00:06:38.759 So, 90s. This IDLE driver contained the hardware 00:06:38.759 --> 00:06:41.779 -dependent code acting as an intermediary. OK. 00:06:42.100 --> 00:06:44.480 The core operating system, the Dodor DOS kernel, 00:06:44.879 --> 00:06:47.839 was programmed to constantly monitor API calls. 00:06:48.379 --> 00:06:51.519 An API call is simply a request that a software 00:06:51.519 --> 00:06:53.579 application makes to the operating system to 00:06:53.579 --> 00:06:56.199 access hardware resources. Right, like a program 00:06:56.199 --> 00:06:57.939 asking the computer to do something physical. 00:06:58.120 --> 00:07:01.300 Exactly. By monitoring these requests, the kernel 00:07:01.300 --> 00:07:03.800 builds a real -time behavioral profile of the 00:07:03.800 --> 00:07:05.939 application. So the driver acts kind of like 00:07:05.939 --> 00:07:08.819 a bouncer at a club, checking every single request 00:07:08.819 --> 00:07:11.120 the software makes to the hardware. I like that. 00:07:11.259 --> 00:07:13.639 It's looking for a specific pattern of request 00:07:13.639 --> 00:07:15.699 that gives away the fact that the software is 00:07:15.699 --> 00:07:18.420 doing absolutely nothing. And the specific pattern 00:07:18.420 --> 00:07:20.660 they were looking for is called a tight loop. 00:07:20.899 --> 00:07:23.819 In the DOS era, if a program needed you to press 00:07:23.819 --> 00:07:27.000 a key, It wouldn't just sit patiently. It would 00:07:27.000 --> 00:07:29.740 constantly ask the operating system, over and 00:07:29.740 --> 00:07:32.160 over, is there a key pressed? Is there a key 00:07:32.160 --> 00:07:34.839 pressed? Oh, just relentlessly bothering the 00:07:34.839 --> 00:07:37.720 OS. Relentlessly. It would pull the keyboard 00:07:37.720 --> 00:07:40.740 buffer. Certain combinations of these API calls 00:07:40.740 --> 00:07:43.259 strongly signaled to the kernel that the application 00:07:43.259 --> 00:07:45.379 was stuck in one of these pulling loops. Wait, 00:07:45.519 --> 00:07:47.579 both an idle program and a busy program might 00:07:47.579 --> 00:07:50.060 check the keyboard, right? I mean, a busy program 00:07:50.060 --> 00:07:52.300 calculating math might still occasionally check 00:07:52.300 --> 00:07:54.060 the keyboard just to see if the user pressed 00:07:54.060 --> 00:07:56.199 escape to cancel the calculation. That's a very 00:07:56.199 --> 00:07:57.939 good point. So how does the bouncer tell the 00:07:57.939 --> 00:07:59.680 difference between the two? This is where the 00:07:59.680 --> 00:08:02.620 genius comes in. The driver functions as a highly 00:08:02.620 --> 00:08:05.879 precise stopwatch. It monitors the time elapsed 00:08:05.879 --> 00:08:07.779 between those keyboard polling requests. OK, 00:08:07.800 --> 00:08:09.879 so it's timing the request. Yeah. It relies on 00:08:09.879 --> 00:08:14.560 a dynamic local variable called idlyCNDTDN idleCountdown. 00:08:14.800 --> 00:08:18.540 This variable sets a very specific minuscule 00:08:18.540 --> 00:08:21.879 time limit. A microsecond limit. Exactly. If 00:08:21.879 --> 00:08:24.800 the software circles back to ask is a key pressed 00:08:24.800 --> 00:08:27.660 within that tiny time limit, the driver concludes 00:08:27.660 --> 00:08:29.680 the program hasn't had time to do anything else. 00:08:29.800 --> 00:08:32.259 Because it asked too fast. Right. It hasn't processed 00:08:32.259 --> 00:08:34.759 any math, hasn't written to the screen, it is 00:08:34.759 --> 00:08:38.080 genuinely stuck in an idle tight loop, and when 00:08:38.080 --> 00:08:41.190 it sees that, It confidently halts the CPU and 00:08:41.190 --> 00:08:43.629 saves power. Wow. And if it takes longer than 00:08:43.629 --> 00:08:45.950 that microsecond limit to ask again? Then the 00:08:45.950 --> 00:08:48.490 driver deduces that some actual processing must 00:08:48.490 --> 00:08:50.720 have occurred between the keyboard checks. The 00:08:50.720 --> 00:08:52.799 program is busy doing real work. So it lets it 00:08:52.799 --> 00:08:55.539 run. Yes. In that scenario, the IDEA lead driver 00:08:55.539 --> 00:08:58.159 immediately overrides the power down sequence, 00:08:58.419 --> 00:09:00.980 passes the authorization back up the chain, and 00:09:00.980 --> 00:09:02.960 allows the application to continue running at 00:09:02.960 --> 00:09:05.460 full power. And it does all this math 18 times 00:09:05.460 --> 00:09:08.039 a second. It performs this dynamic calculation, 00:09:08.580 --> 00:09:11.269 checking the interval. deciding to halt or override 00:09:11.269 --> 00:09:14.470 18 times a second. It's an incredibly elegant 00:09:14.470 --> 00:09:17.409 workaround to a severe hardware limitation. I 00:09:17.409 --> 00:09:19.830 mean, they completely bypass the hardware's blindfold 00:09:19.830 --> 00:09:23.330 by putting a hyper -vigilant stopwatch directly 00:09:23.330 --> 00:09:26.129 inside the operating system kernel. It was revolutionary. 00:09:26.450 --> 00:09:29.409 But you'd think an architectural shift, this 00:09:29.409 --> 00:09:32.110 revolutionary, something that fundamentally alters 00:09:32.110 --> 00:09:35.269 the viability of portable computing, would make 00:09:35.269 --> 00:09:38.649 digital research the undisputed king of the 1990s 00:09:38.649 --> 00:09:42.009 laptop boom. You would think so. So why is battery 00:09:42.009 --> 00:09:44.809 max an obscure footnote? Well, the origins of 00:09:44.809 --> 00:09:47.350 the technology provide some crucial context for 00:09:47.350 --> 00:09:50.909 its eventual commercial failure, because initially, 00:09:51.529 --> 00:09:54.110 this idle detection mechanism wasn't engineered 00:09:54.110 --> 00:09:56.710 to save battery life at all. Really? From the 00:09:56.710 --> 00:09:58.649 source material, it looks like battery max was 00:09:58.649 --> 00:10:01.450 actually a byproduct of trying to fix a completely 00:10:01.450 --> 00:10:03.490 different problem involving selfish software. 00:10:03.789 --> 00:10:06.330 Exactly. It was originally developed for an operating 00:10:06.330 --> 00:10:09.690 system called Concurrent DOS 386. OK, what was 00:10:09.690 --> 00:10:12.710 that? This was a multitasking multi -user system, 00:10:13.070 --> 00:10:15.210 meaning it was designed to run several programs 00:10:15.210 --> 00:10:18.340 at once. But the problem was that most software 00:10:18.340 --> 00:10:21.179 at the time was written for single -tasking operating 00:10:21.179 --> 00:10:23.779 systems, like standard MS -DOS. And those single 00:10:23.779 --> 00:10:26.100 -tasking programs were inherently greedy. Oh, 00:10:26.179 --> 00:10:28.919 incredibly greedy. In a single -tasking environment, 00:10:29.080 --> 00:10:31.960 a program assumed it owned the entire computer. 00:10:32.220 --> 00:10:34.299 It didn't need to share the processor with anything 00:10:34.299 --> 00:10:37.019 else. Exactly. When those single -tasking programs 00:10:37.019 --> 00:10:40.220 needed a user input, they would enter those relentless 00:10:40.220 --> 00:10:43.259 polling loops we just discussed, consuming 100 00:10:43.259 --> 00:10:46.450 % of the CPU's processing cycles. simply waiting 00:10:46.450 --> 00:10:48.730 for a keystroke. Which is fine if it's the only 00:10:48.730 --> 00:10:51.750 program running. Right. But in a multitasking 00:10:51.750 --> 00:10:54.590 environment, that greedy behavior brings the 00:10:54.590 --> 00:10:58.309 whole system to a crawl. If one program is monopolizing 00:10:58.309 --> 00:11:01.629 the processor just to wait for a key, the operating 00:11:01.629 --> 00:11:04.769 system can't allocate CPU time to other programs 00:11:04.769 --> 00:11:07.250 that actually have work to do. Ah, so the bouncer 00:11:07.250 --> 00:11:09.470 wasn't originally checking IDs to turn off the 00:11:09.470 --> 00:11:11.889 lights. It was checking IDs to kick the greedy 00:11:11.889 --> 00:11:14.870 programs off the dance floor. That is a great 00:11:14.870 --> 00:11:17.549 way to put it. Digital research deployed idle 00:11:17.549 --> 00:11:20.070 detection to forcefully suspend those greedy 00:11:20.070 --> 00:11:21.990 programs when they were caught in a bowling loop. 00:11:22.629 --> 00:11:24.529 This freed up the processors so the operating 00:11:24.529 --> 00:11:26.789 system could schedule other concurrent processes. 00:11:26.970 --> 00:11:28.669 And the battery saving was just an accident? 00:11:29.049 --> 00:11:31.490 Pretty much. It was only later that they realized 00:11:31.490 --> 00:11:34.490 halting the CPU to manage software could also 00:11:34.490 --> 00:11:36.870 physically stop the CPU from drawing electrical 00:11:36.870 --> 00:11:40.070 current, thereby saving massive amounts of battery 00:11:40.070 --> 00:11:42.620 on these new laptop devices. So what does this 00:11:42.620 --> 00:11:44.679 all mean? I mean, digital research invents this 00:11:44.679 --> 00:11:47.220 brilliant architectural rookery to manage software. 00:11:47.620 --> 00:11:50.179 They realize its profound application for battery 00:11:50.179 --> 00:11:54.620 life. They package it into Docardos 5 .0 in 1990. 00:11:54.940 --> 00:11:57.360 And they later deploy it in novels Palmdose 1 00:11:57.360 --> 00:12:01.200 .0 in 1992 for early palm tops. Right. They even 00:12:01.200 --> 00:12:03.620 secure the intellectual property, filing a patent 00:12:03.620 --> 00:12:07.299 in March 1990, which is granted in 1994. They 00:12:07.299 --> 00:12:09.779 checked every box for a major tech breakthrough. 00:12:09.980 --> 00:12:12.700 Why did it fade away? It succumbed to a classic 00:12:12.700 --> 00:12:15.200 convergence of corporate instability and industry 00:12:15.200 --> 00:12:17.679 standardization. As it always goes. Yeah. In 00:12:17.679 --> 00:12:20.419 1991, digital research was acquired and integrated 00:12:20.419 --> 00:12:23.240 into Novell, Inc. The aftermath of that acquisition 00:12:23.240 --> 00:12:25.500 was highly disruptive. Oh, mergers are always 00:12:25.500 --> 00:12:28.279 a mess. Totally. Internal focus fractured, projects 00:12:28.279 --> 00:12:31.220 were reorganized or sidelined, and momentum just 00:12:31.220 --> 00:12:33.139 stalled. And in the tech industry, a stalled 00:12:33.139 --> 00:12:36.000 momentum of even 12 months can be fatal. Because 00:12:36.000 --> 00:12:38.279 someone else is always building something. Exactly. 00:12:38.740 --> 00:12:42.519 By 1992, Microsoft and Intel jointly launched 00:12:42.519 --> 00:12:46.139 APM, or Advanced Power Management. The two undisputed 00:12:46.139 --> 00:12:49.299 heavyweights of the PC era moving in on the exact 00:12:49.299 --> 00:12:52.080 same territory. Yeah. But APM took a different 00:12:52.080 --> 00:12:54.559 approach. It wasn't just a driver tied to one 00:12:54.559 --> 00:12:57.460 specific operating system, like DaggerDOS. It 00:12:57.460 --> 00:13:00.279 was an industry -wide standard interface that 00:13:00.279 --> 00:13:03.139 connected the hardware BIOS directly to the operating 00:13:03.139 --> 00:13:05.220 system. So a totally different architecture. 00:13:05.440 --> 00:13:08.639 Right. It allowed the OS to communicate power 00:13:08.639 --> 00:13:11.419 management requests to the motherboard in a standardized 00:13:11.419 --> 00:13:13.720 language. Which means every hardware manufacturer 00:13:13.720 --> 00:13:15.799 in the world could adopt it, and it would work 00:13:15.799 --> 00:13:18.539 seamlessly with Microsoft's dominating MS -DOS 00:13:18.539 --> 00:13:20.559 and Windows environments. If we connect this 00:13:20.559 --> 00:13:23.179 to the bigger picture, it illustrates a brutal 00:13:23.179 --> 00:13:26.620 reality of the technology sector. Having a technically 00:13:26.620 --> 00:13:29.440 superior patented methodology does not guarantee 00:13:29.440 --> 00:13:32.279 market survival. It rarely does. Digital research 00:13:32.279 --> 00:13:34.620 had the OS level intelligence figured out first. 00:13:35.100 --> 00:13:37.120 But while they were navigating a chaotic corporate 00:13:37.120 --> 00:13:40.179 merger, Microsoft and Intel created a unified 00:13:40.179 --> 00:13:43.019 hardware ecosystem. Network effect. Exactly. 00:13:43.940 --> 00:13:47.299 Industry standards routinely kill superior proprietary 00:13:47.299 --> 00:13:49.580 tech because manufacturers will always choose 00:13:49.580 --> 00:13:52.379 the path of least resistance and broadest compatibility. 00:13:53.300 --> 00:13:55.879 Battery Max was essentially buried by the sheer 00:13:55.879 --> 00:13:58.399 gravitational pull of the Microsoft and Intel 00:13:58.399 --> 00:14:01.840 standard. It basically became a dead end. A brilliant 00:14:01.840 --> 00:14:04.299 piece of code relegated to the archives while 00:14:04.299 --> 00:14:06.960 APM went on to define portable computing for 00:14:06.960 --> 00:14:10.220 a decade. It was gone. Until it wasn't dead. 00:14:10.500 --> 00:14:13.179 Because nearly 20 years later, the very companies 00:14:13.179 --> 00:14:15.639 that rendered Battery Max obsolete suddenly found 00:14:15.639 --> 00:14:17.440 themselves in desperate need of it. They really 00:14:17.440 --> 00:14:21.309 did. The catalyst was a massive 2009 patent troll 00:14:21.309 --> 00:14:23.470 lawsuit. Here's where it gets really interesting. 00:14:23.769 --> 00:14:26.690 In 2009, an entity called St. Clair Intellectual 00:14:26.690 --> 00:14:29.470 Property Consultants launched a sweeping legal 00:14:29.470 --> 00:14:31.830 offensive. Sweeping is an understatement. Right. 00:14:32.029 --> 00:14:34.549 They filed civil actions against a massive roster 00:14:34.549 --> 00:14:36.629 of hardware manufacturers. We're talking about 00:14:36.629 --> 00:14:39.929 Iser, Dell, Gateway, Lenovo, Apple and Toshiba, 00:14:40.350 --> 00:14:42.570 the entire foundation of the laptop industry. 00:14:42.769 --> 00:14:45.110 St. Clair's legal strategy was extremely aggressive. 00:14:45.389 --> 00:14:47.929 They operated as a non -practicing entity, what 00:14:47.929 --> 00:14:50.330 is colloquially known as a patent troll. So they 00:14:50.330 --> 00:14:52.409 don't make anything, they just sue. Exactly. 00:14:53.129 --> 00:14:55.730 They had acquired a portfolio of U .S. patents 00:14:55.730 --> 00:14:58.730 originally filed by an inventor named Henry Fung. 00:14:59.809 --> 00:15:02.629 These patents broadly cover the concept of software 00:15:02.629 --> 00:15:05.529 power management under operating system control. 00:15:05.830 --> 00:15:08.049 Okay, so the core idea we've been talking about. 00:15:08.309 --> 00:15:11.210 Right. Sinclair asserted that Fung was the definitive 00:15:11.210 --> 00:15:15.240 pioneer of OS -level power management. And therefore, 00:15:15.639 --> 00:15:18.059 every modern laptop utilizing these techniques 00:15:18.059 --> 00:15:20.320 was actively infringing on their intellectual 00:15:20.320 --> 00:15:23.000 property. And they were demanding retroactive 00:15:23.000 --> 00:15:26.019 royalties, which if you extrapolate a royalty 00:15:26.019 --> 00:15:28.519 fee across the sheer volume of laptops sold by 00:15:28.519 --> 00:15:31.279 Dell, Apple and Toshiba over years of production, 00:15:31.679 --> 00:15:34.059 you are looking at an existential financial threat 00:15:34.059 --> 00:15:37.259 to the entire hardware ecosystem. Billions of 00:15:37.259 --> 00:15:39.480 dollars. It escalated to the point where Microsoft 00:15:39.480 --> 00:15:41.740 and Intel, the architects of the APM standard 00:15:41.740 --> 00:15:44.340 that every manufacturer was relying on, legally 00:15:44.340 --> 00:15:46.419 intervened. They had to step into the courtroom 00:15:46.419 --> 00:15:48.820 to defend the hardware makers. Because if St. 00:15:48.860 --> 00:15:51.240 Clair prevailed, the entire A higher standardized 00:15:51.240 --> 00:15:53.919 ecosystem that Microsoft and Intel had cultivated 00:15:53.919 --> 00:15:56.679 would be permanently taxed by a third -party 00:15:56.679 --> 00:15:58.679 holding company. They couldn't let that happen. 00:15:58.899 --> 00:16:01.580 No way. The defense required a silver bullet. 00:16:02.340 --> 00:16:05.059 So the legal team representing the hardware manufacturers, 00:16:05.600 --> 00:16:08.259 a Seattle -based firm named Perkins Coy, went 00:16:08.259 --> 00:16:11.080 on the offensive. Their mandate was to locate 00:16:11.080 --> 00:16:14.320 prior art. Perkins Coy was on a desperate hunt 00:16:14.320 --> 00:16:16.519 for prior art. For you listening, that means 00:16:16.519 --> 00:16:19.860 any documented publicly available proof that 00:16:19.860 --> 00:16:22.240 OS -level power management had been successfully 00:16:22.240 --> 00:16:25.440 invented and deployed before Henry Fung filed 00:16:25.440 --> 00:16:27.500 his patents. Right, because if they could demonstrate 00:16:27.500 --> 00:16:29.620 the concept was already known to the industry, 00:16:30.059 --> 00:16:32.580 Fung's patents would be invalidated. And St. 00:16:32.679 --> 00:16:35.340 Clair's entire multi -billion dollar case would 00:16:35.340 --> 00:16:37.840 just evaporate. Exactly. So the lawyers had to 00:16:37.840 --> 00:16:40.299 dig deep into the architectural history of 90s 00:16:40.299 --> 00:16:42.879 computing. They were scanning through old operating 00:16:42.879 --> 00:16:45.200 system manuals, forgotten technical journals, 00:16:45.720 --> 00:16:48.100 and archived patent filings. Just looking for 00:16:48.100 --> 00:16:50.460 a needle in a haystack. And in that search, they 00:16:50.460 --> 00:16:53.580 unearthed the remnants of battery max. Specifically, 00:16:53.700 --> 00:16:58.659 they found U .S. patent 5 ,345 ,392 for an idle 00:16:58.659 --> 00:17:01.340 detection system, filed by Roger Alan Gross and 00:17:01.340 --> 00:17:03.379 John P. Constant. The British engineers from 00:17:03.379 --> 00:17:05.960 Digital Research's Hungerford lab, the bouncer 00:17:05.960 --> 00:17:09.799 and the stopwatch. Yes. Crucially, the priority 00:17:09.799 --> 00:17:12.799 date on the gross patent predated Fung's patents. 00:17:13.539 --> 00:17:16.420 So in February 2011, Intel took a remarkable 00:17:16.420 --> 00:17:19.099 step. This is my favorite part. The very company 00:17:19.099 --> 00:17:21.900 that had partnered with Microsoft to push APM 00:17:21.900 --> 00:17:25.839 and Sideline Battery Max in 1992 now hired Roger 00:17:25.839 --> 00:17:28.400 Alan Gross as a subject matter expert witness 00:17:28.400 --> 00:17:31.180 to testify on their behalf. That is just incredible. 00:17:31.400 --> 00:17:34.319 Gross submitted a detailed expert report asserting 00:17:34.319 --> 00:17:37.220 that he and Constant had pioneered software power 00:17:37.220 --> 00:17:40.099 management under OS control, utilizing Battery 00:17:40.099 --> 00:17:43.539 Max and his 1994 patent as incontrovertible proof. 00:17:43.940 --> 00:17:46.099 Man, St. Clair's legal team must have seen the 00:17:46.099 --> 00:17:48.380 writing on the wall. Oh, they panicked. They 00:17:48.380 --> 00:17:51.480 reacted with immediate hostility. Sinclair filed 00:17:51.480 --> 00:17:54.140 formal motions to exclude Gross's opinions and 00:17:54.140 --> 00:17:56.380 dismiss his expert report entirely. Because he 00:17:56.380 --> 00:17:59.059 was the silver bullet. Exactly. They understood 00:17:59.059 --> 00:18:01.380 that if the court admitted battery max into evidence 00:18:01.380 --> 00:18:04.259 of legitimate prior art, the foundation of their 00:18:04.259 --> 00:18:06.380 infringement claims would be completely destroyed. 00:18:06.619 --> 00:18:08.460 The court, however, saw through the procedural 00:18:08.460 --> 00:18:11.740 maneuvers. In March 2013, the district court 00:18:11.740 --> 00:18:14.000 delivered a decisive ruling against St. Clair. 00:18:14.420 --> 00:18:16.779 They declared Gross's testimony fully admissible. 00:18:17.180 --> 00:18:19.920 A huge win. Yeah, the judge specifically noted 00:18:19.920 --> 00:18:22.539 that the defense had provided sufficient corroborating 00:18:22.539 --> 00:18:25.099 evidence proving battery max was available to 00:18:25.099 --> 00:18:27.380 the public prior to the priority date of the 00:18:27.380 --> 00:18:29.980 Fung patents. And the ruling went even further. 00:18:30.220 --> 00:18:32.980 The court noted that even if the exact timeline 00:18:32.980 --> 00:18:35.900 of public availability was contested, Gross's 00:18:35.900 --> 00:18:38.140 testimony was highly relevant to demonstrate 00:18:38.140 --> 00:18:41.140 that OS -level power management was obvious to 00:18:41.140 --> 00:18:43.460 persons having ordinary skill in the art at that 00:18:43.460 --> 00:18:46.400 time. Obvious is a legal term, right? Yes. In 00:18:46.400 --> 00:18:48.920 patent law, proving a concept was obvious is 00:18:48.920 --> 00:18:52.420 a primary mechanism for invalidation. So BatteryMax, 00:18:52.559 --> 00:18:54.559 the technology that was abandoned due to corporate 00:18:54.559 --> 00:18:57.460 restructuring, became the definitive legal shield 00:18:57.460 --> 00:18:59.579 that protected the modern computing industry. 00:18:59.940 --> 00:19:02.660 The historical irony is staggering. Intel and 00:19:02.660 --> 00:19:05.259 Microsoft created the unified standard that drove 00:19:05.259 --> 00:19:07.940 BatteryMax into the ground. They functionally 00:19:07.940 --> 00:19:09.759 killed the product. They really did. But two 00:19:09.759 --> 00:19:12.339 decades later, facing potentially ruinous royalty 00:19:12.339 --> 00:19:15.259 litigation, those same giants had to excavate 00:19:15.259 --> 00:19:17.700 the archives, dust off the code they defeated, 00:19:18.180 --> 00:19:20.380 and present it to a federal judge to save their 00:19:20.380 --> 00:19:23.259 own. ecosystem, they survived because of battery 00:19:23.259 --> 00:19:25.920 max. It highlights a fascinating reality about 00:19:25.920 --> 00:19:29.140 technological progress. The timeline of innovation 00:19:29.140 --> 00:19:32.000 is rarely a straight line of continuous improvement. 00:19:32.240 --> 00:19:35.019 No, it's messy. Very messy. It's heavily influenced 00:19:35.019 --> 00:19:38.460 by corporate strategy, legal battles, and shifting 00:19:38.460 --> 00:19:40.759 industry standards. So let's synthesize this 00:19:40.759 --> 00:19:43.279 journey. We started with an intricate software 00:19:43.279 --> 00:19:46.940 mechanism originally designed to referee greedy, 00:19:47.279 --> 00:19:50.079 single -tasking DOS programs that refuse to share 00:19:50.079 --> 00:19:52.839 the processor. Right, the bouncer. That mechanism 00:19:52.839 --> 00:19:56.000 evolved into a microsecond stopwatch, a power 00:19:56.000 --> 00:19:58.440 -saving breakthrough that fundamentally enabled 00:19:58.440 --> 00:20:01.559 the modern laptop. Then it became a casualty 00:20:01.559 --> 00:20:04.900 of the brutal 90s tech wars swallowed by the 00:20:04.900 --> 00:20:07.240 novel merger and steamrolled by the Microsoft 00:20:07.240 --> 00:20:10.559 Intel APM standard. A forgotten relic. And finally, 00:20:10.640 --> 00:20:13.180 it emerges from obscurity as the ultimate trump 00:20:13.180 --> 00:20:15.920 card in a high stakes legal showdown. This raises 00:20:15.920 --> 00:20:17.859 an important question, and it's something I'd 00:20:17.859 --> 00:20:19.720 love for you to consider long after we wrap up 00:20:19.720 --> 00:20:22.539 today. Think about the sheer volume of brilliant, 00:20:22.960 --> 00:20:24.880 fully patented innovations currently sitting 00:20:24.880 --> 00:20:27.059 in the failed bin of corporate history. Oh, there 00:20:27.059 --> 00:20:30.309 must be thousands. Easily. We are conditioned 00:20:30.309 --> 00:20:33.430 to view failed technology as useless ideas that 00:20:33.430 --> 00:20:35.690 simply weren't robust enough to survive the free 00:20:35.690 --> 00:20:39.009 market. But how many other forgotten lines of 00:20:39.009 --> 00:20:42.029 code, born from bankruptcies and abandoned projects, 00:20:42.390 --> 00:20:44.720 are sitting in the dark right now? just waiting, 00:20:44.759 --> 00:20:46.900 waiting for the right moment or the right billion 00:20:46.900 --> 00:20:49.900 dollar lawsuit to suddenly become the most critical 00:20:49.900 --> 00:20:52.519 piece of prior art in the world. It completely 00:20:52.519 --> 00:20:54.460 reframes how you look at the tech graveyard. 00:20:54.539 --> 00:20:56.359 So the next time you are sitting in a coffee 00:20:56.359 --> 00:20:59.180 shop untethered from the wall, watching your 00:20:59.180 --> 00:21:01.880 battery hold steady while you work, just remember, 00:21:01.980 --> 00:21:04.539 remember that you aren't just relying on modern 00:21:04.539 --> 00:21:07.119 chemistry and hardware efficiency. You're coasting 00:21:07.119 --> 00:21:10.160 on the invisible microsecond legacy of an obscure 00:21:10.160 --> 00:21:13.509 1989 software patch that refused to stay. dead. 00:21:14.089 --> 00:21:16.089 Thanks for joining us on this deep dive. We'll 00:21:16.089 --> 00:21:16.650 see you next time.