Well... there's a little more to it than that. A "phone" environment is fundamentally different in the sense that an incoming phone call usually will (and should) stop whatever else you're doing dead in its tracks until the call is dealt with. A scheduling and notification strategy optimized for realtime multiplayer games is going to be completely dysfunctional when your real-world use case involves being able to freeze the action mid-shot and take an incoming phone call, then gracefully ease back into the action when it's finished. That's why Android makes such a big deal about differentiating between "service" and "activity" -- a service can keep running when another activity has the activity focus.
If Android apps weren't forced to divide up the workflow and separate out the parts into "things that can (and should) run in the background without a user interface", and "things that only make sense when the application has focus and the user's exclusive attention", we'd have the same problems that IOS does. Where things in Android's world become confusing is the ambiguity at the "service" end, between "things that happen occasionally on a schedule" (like polling a server), "things that happen in response to something else" (incoming communication, arrival at location, change of sensor state, etc), and "things that should happen, and keep happening, until something else gives them a reason to stop" (like music playback). Complicating things more is the fact that you can sort of *get away* with doing things in background services using threads and traditional Java sleep/wait strategies, but Android will break things that insist on doing things that way in increasingly aggressive ways (particularly Gingerbread and beyond), even when they do it in ways that are considered to be perfectly legitimate and polite in mainstream Java.
Starting with Gingerbread, Android has started becoming downright mean & aggressive towards apps that use TimerTask to schedule periodic tasks in background services instead of using alarms & intents... not quite breaking apps outright, but getting VERY aggressive about killing background services that use TimerTask with partial wakelocks in ways that even a year ago would have been considered mainstream and exceptionally well-behaved (like grabbing a partial wakelock ONLY during actual network activity, to at least ensure that the phone didn't get put to sleep halfway through a http request, even if the service itself ended up suspended until the phone was awakened by something). Now, Android will kill background services after about an hour simply because it decides they've been running for "too long", even if they've been asleep in a TimerTask for most of it. I never even noticed this until I got my Photon last month, because my previous phone (Samsung Galaxy S/Epic 4G) was stuck in Froyo-land, and my app worked flawlessly on it. I knew it didn't reliably poll when the phone was asleep, but it still managed to make it work often enough to not be a big deal. Once I got the Photon, I noticed that it was just silently dying outright after about an hour, and not coming back to life after the phone was awakened.
I can see Google's logic, but I don't think they've done a particularly good job of reaching out to developers (many of whom are still stuck in Froyo-land, if only because American carriers suck & most users are still stuck with it, often including the developers themselves). Yes, the emulator exists for newer versions, but frankly, it's so slow, even on a fast quadcore PC, I'd rather tear off my fingernails one by one than suffer its slowness (and the fact that it seems to either die, or spontaneously lose contact with Eclipse, once or twice per hour, necessitating even more delay and interruption). After I bought my new Photon, my old Epic turned into my "permanently tethered to the computer development phone".
It was "digital", but not in the formal sense the FCC meant when they elsewhere talked about "digital modes".
My quoting of 5wpm/13wpm was just to clarify that I was talking about the Technician-class license back when 5wpm was required to get it, and the General-class license back when 13wpm was required to get it. I wasn't implying that they were speed limits.
I was wrong about the official designation. It's A1A, not 1A0.
I can't quote the exact rule, but apparently the FCC did manage to finally close up another loophole. Apparently, there IS now a rule buried somewhere in the regulations that formally specifies the maximum amount of bandwidth you can use within the novice/technician portion of the "CW-only" bands, and defines it in terms of effective radiated power. It's a rule that would be irrelevant if you're using CW to transmit international morse code with a straight key (or even sending it at halfway normal speeds using a computer to toggle a relay), but would become very applicable if you were broadcasting a de-facto bitbanged AM-like signal with substantial footprint via PWM by rapidly keying the transmitter on and off, regardless of intent or technicality.
Regardless of how non-edgy or non-blackhat it might have been, it was fun;)
> In short, HDDs recognize only two states, up or down.
That hasn't been true for at least 10-15 years. Modern hard drives use variable signal strength to record multiple bits into each spot. I believe the official term someone came up with was "vertical recording". In vastly simplified terms, it boils down to this: instead of storing nothing (0) or a magnetic field (1), you store nothing, weak, moderate, or strong. 4 levels = 2 bits. Increase the sensitivity and analog-digital resolution, add some DSP magic, and the number of bits per magnetic area goes way up beyond my example with 2 bits and 4 levels to 8, 16, and more. It makes the drives cheaper to make, because instead of storing single bits at precise spots, you can store clumps of bits in slightly more loosely-defined areas.
> There is an international network of packet and pactor based systems that do this on a regular basis
The point is that we're talking about a de-facto high(er) speed quasi-digital mode being used by someone with a 1990 5wpm-code Technician-Class license who's officially authorized to do "CW", relying on a very questionable and loose interpretation of CW's old definition (turning a single carrier on and off) to achieve it in ways the original rulemakers never would have thought possible, let alone anticipated.
In contrast, Pactor by someone with what used to be a General class license with 13wpm code was never controversial, because FSK-based digital modes were always unambiguously allowed for General and above.
As for 200wpm... well, that pretty much the absolute experimental frontier of what you can make meaningfully work if you're transmitting by opening and closing a relay pretending to be a straight key connected to a HF rig, and even 200wpm is seriously pushing your luck. If you go by the "PARIS" standard, and loosely count it as the timing equivalent of 27 bits (3 per dash, 1 per dot, 1 per inter-character pause), you're looking at the equivalent of ~500 baud. At that rate, I'm kind of amazed in retrospect that it was even possible to get meaningful reception, and that the transmitter key-down distortion didn't turn sequential dots into meaningless noisy buzz.
> The FCC should have mandated GSM for the entire U.S. at the outset, as Europe and many other countries did.
You're forgetting that in the early 90s (when Sprint and Primeco-later-Verizon settled on CDMA), GSM sucked donkey balls. It was old-fashioned TDMA, with some automatic network provisioning stapled on top to make interoperability a little less painful. CDMA utterly and completely blows away pre-UMTS GSM in pure technical merit. Need proof? UMTS *is* CDMA (just wider channels and some evolutionary refinements).
Before its merger with Cingular, AT&T was contemplating a switch to CDMA back in the early 2000s. The only thing that stopped it was the fact that Cingular had already committed to GSM, and had already started building out its new network.
There's absolutely NO engineering reason why Sprint and Verizon phones can't be as fully and transparently interoperable as GSM phones in Europe. In countries like India, they *are*. CDMA even has its own superset of the SIM card standard, called "R-UIM" (which is officially now an optional subset of the USIM standard used on modern GSM phones). American phones are balkanized because that's how the carriers like it. With proper firmware and cooperation from Sprint, a Galaxy S2 intended for T-Mobile could work flawlessly on Sprint or Verizon with nothing more than updated firmware (well, ok, it would probably need official FCC certification to make it 100% legal, but the point is that all the hardware the phone needs to be physically capable of EVDO is already soldered to the motherboard, and it's purely a matter of firmware, regulatory approval, and business cooperation. The engineering problems are solved.)
Actually, UMTS (3G GSM) and CDMA2000 aren't nearly as mutually alien as you'd think. Thanks to new chipsets like the Qualcomm MDM6600 (used in roughly half the new high-end Android phones sold worldwide), the only thing you really need to do to make a "CDMA" phone design work with UMTS is add a socket for the SIM card and support it in the firmware.
If Sprint were smart, and quietly made a point of making sure that all of their new high-end Android phones were physically capable of UMTS going forward (like the Photon, and like both the Evo3D and Galaxy S2 COULD have been if they'd bothered to include a SIM card), they could easily finish building out T-Mobile's UMTS network (using their own backhaul and tower sites in places where T-Mobile doesn't already exist natively) and update the PRL rules so that those same phones started using UMTS instead of EVDO in markets where Sprint's EVDO service was getting crowded compared to the wide open spaces of T-Mobile's UMTS service.
Search my history. About 3 months ago, I posted a mini-essay explaining how Sprint could merge with T-Mobile, continue to support both legacy GSM and CDMA voice/2G data indefinitely, become the only carrier in America physically capable of offering 1900/2100MHz UMTS service on international frequencies (using T-Mobile's 2100 spectrum, and repurposing a bit of Sprint's 1900MHz spectrum), and repurpose 1700MHz and their 800MHz Nextel spectrum for LTE.
Trust me on this... if push came to shove, Verizon is more afraid of Sprint + T-Mobile than it is of competing with a larger AT&T. Verizon would prefer to keep the status quo indefinitely and keep acquiring regional carriers of its own, but it would MUCH rather see AT&T get T-Mobile than Sprint. To Verizon's world view, AT&T is a well-behaved adversary. Sprint is a dangerous, disruptive, raging barbarian determined to overturn the neat, orderly Bell vision of society. Verizon might think AT&T's fetish with wireless over fiber is counter-productive in the long run, but it's not worried about AT&T encouraging consumers to think unlimited wireless broadband is a viable business model.
Actually, I messed up... you can use the scheme with 2 bits per code and variable-length symbols to encode uppercase and lowercase...
00 = "dot" 01 = "dash" 10 (preceded by one or more 00 and 01 codes): lowercase endmark 11 (preceded by one or more 00 and 01 codes): uppercase endmark one or more 10 codes, without any buffered 00 or 01 ahead of them since the last 10 or 11: space 1100, 1101, and 1110: three more codes to use for things like newline, backspace, and ??? 1111---- = escaped-out nirvana. I think you get the idea by now. We've got a way to represent dots, dashes, a way to mark the ends of characters in a way that indicates uppercase or lowercase, and gives alternate meanings to codes like numbers that have no meaningful concept of "uppercase".
Don't forget the deliciously geeky potential of morse(-ish) code as an alternate input method for Android phones, so you can smile attentively at everyone in the vicinity while holding the phone in your lap under the table and sending text messages;-)
Strictly speaking, if you're willing to treat the fourth ("01") state as "space" when used once and "escape" when used twice in a row, you can meaningfully do Morse with 2-bit encoding and variable-length symbols:
"dot" = 10 "dash" = 11 "end of character" = 00 "end of word" (defaulting to "space") = 01
Some older approaches add extra states, like "inter-dash/dot pause", but when you really boil it down to the raw essence, 2 bits per dot/dash will do the job just fine.
Hell, I remember the good 'ol days circa 1992, before the FCC officially tightened up the definition of "CW", and there was a de-facto loophole in the definition big enough to drive a truck through if you were an uppity teen/twentysomething ham (like I was) with a computer, just itching to use 200wpm morse to do UUencoded file transfers between the US and Europe;)
Back then, the official rules literally just said you were restricted to "CW", without ever really getting specific about what "CW" actually *was*. I guess they just assumed that everyone knew from tradition, and I suspect the FCC regulators were horrified to find out what guys like me were up to in the final dark days before widespread worldwide internet connectivity.
NOW, the rule explicitly defines the "mode" as "1A0", and explicitly says it has to be "plain text". It doesn't quite go as far as stipulating morse code, but I think I read a non-binding FCC opinion someplace where they basically said occasional adhoc prosigns are OK as long as they're published SOMEWHERE and your intent isn't to conceal what you're sending, but hex-encoded UTF8 and any kind of binary-encoded file is absolutely beyond the pale.
In a way, I can see why they clamped down a bit. At the time I didn't have the RF or digital electronics background to know it, but I now know that turning a carrier on and off is neither instantaneous nor consequence-free, and when you do it fast enough, you're basically bit-banging de-facto AM via PWM and square-wave artifacts that's going to splatter over a MUCH wider chunk of spectrum than a carrier being slowly turned on and off by a straight key.
The problem is that Android's permissions, like most of the API, does a good job of offering general-purpose ways to do things, but does a piss poor job of bundling things into neatly-packaged convenience methods that make it easy to just Do The Right Thing.
Nobody (at Google) has ever really sat down and said, "How can we provide a system-level library that can support the needs of a service like AdMob (without being specific to AdMob itself), then create a specific set of permissions that grant exactly what's needed and nothing more to achieve the specific task of serving location-targeted ads to anonymous users who can be tracked in the aggregate.
It has to be system-level, and have specific requirements for hardcoding things like the adserver's base URL and app id in the manifest, because otherwise a cloaked malware app could use it to leak information to the outside world without being obvious about it. For example:
* The app can request a new ad, but Android introduces a random delay whose maximum value increases as the number of refresh requests does. This is necessary to make time-based attacks (where you modulate leaked information into the request rate itself, treating the request rate like a form of morse code) more difficult. You can't eliminate them completely, but you can make it very hard to convey more than a few bits per minute.
* The location comes straight from Android's location services (GPS, network, or both) and gets automatically rounded down to the desired level of accuracy (say, quarter-degree, tenth-degree, or hundredth-degree). This prevents apps from trying to encode data into the lower bits of the location.
* The URL of the web service that gets queried for the image and click-target URL is hardcoded into the manifest, with the ability to specify multiple in either failover or round-robin style.
* The user ID passed to that web service is handled directly by Android, and the app never gets to touch it. It's randomly generated by Android, and comes in two flavors that are specified by the permissions itself: global to a physical phone, but not associated with a specific identity (ie, if you buy a new phone, your ID changes; it's not associated with your Google ID), or anonymously associated with a specific user and a specific application. In other words, if you're logged on to your phone and tablet with the same Google ID, you'd have the same anonymized ad id when requesting ads in the same app on both devices, but different apps would have different IDs. Any attempt to correlate the two, or to correlate ad ids with real-world identities, would be forbidden by EULA with staggeringly huge liquidated damages payable to both Google and the end user.
The format of the image URL is problematic, because there's a very fine line between flexibility and giving malware the opportunity to leak user information via the URL itself. On one hand, you need an address space large enough to accommodate different images for different advertisers and campaigns, but you don't want to give too many extra bits to tempt companies into trying to encode extra information about the user himself into them. I'd propose something like the following:
Baseurl: rigidly specified in the manifest, with provisions to specify multiple for failover and loadbalancing purposes.
Density: automatically substituted in by Android based upon LDPI/MDPI/HDPI/XDPI
Width: alternative to Density, equal to number of horizontal pixels in current orientation. Mainly, for people like me who hate the way Android deals with 540x960 qHD (I despise scaling and prefer to serve images at native resolution), and the coming trainwreck differentiating between 720x1280 on a 4.5" screen and 1280x800 on a 10" screen.
App ID: hardcoded in manifest
Target-intent and Notification-intent: ooh. These are rough. On one hand, you need flexibility to deliver clicks to the appropriate destination... but too much, and it's another information-leakage nightmare. My current hunch is that you'd
Actually, it does. When the opportunity cost of collecting and analyzing data is high, it doesn't really matter whether it's being collected. When anybody can turn around and do data mining on it with trivial ease, it becomes quite important. Nobody cared about social security numbers being printed in recorded court documents until they became available online, and people didn't become *neurotic* about retroactively redacting them until thirdparties started scraping, OCR'ing, and data-mining those same documents.
What I want to know is why, to this day, it's still legal for municipalities in Florida to sell liens, then record literally a semi-truck of liens recorded against "John Doe" at the courthouse ~2 years later, instead of being required to electronically associate those same liens with the property's globally-unique folio number, so somebody who goes to BUY the property can conveniently find them all in 12 seconds. Instead, cities like Miami can shrug and say, "We sold a lien to somebody 3 years ago, but we didn't keep track of who we sold it to, and we filed it with 300,000 other liens on the same day at the courthouse under "John Doe", so you're just going to have to wait 4 years until the person officially redeems it, or literally spend 3 months looking for a needle in a haystack one record at a time until you manage to trip over it. Assuming we didn't make a typo." It's positively *insane* how easy it is for municipalities in Florida to pile on fines without making even the most trivial effort to notify property owners, and record liens that could end with a property being sold for literally pennies on the thousand-dollar with breathtaking recklessness that seems almost inconceivable. You read in papers about how careless mortgage companies were with paperwork (their excuse for just making up replacement paperwork with robo-signers as they go along), but it's *nothing* compared to how simultaneously careless Florida municipalities are allowed to be, and how ruthless they're allowed to be in spite of their carelessness.
He's not talking about HDMI. He's talking about wireless. Unless you're talking about a $800+ wireless HDMI system, that basically means broadcast 8VSB or COFDM, which means 19.2mbit/sec MPEG-2.
Because you'd have to transform the display into a MPEG-2 data stream with maximum bitrate of 19.2mbit/sec, then modulate it onto an 8-VSB carrier (to work in the US) and COFDM (to work in most other places). It's nontrivial. 8-VSB, in particular, is a bitch to do. The wireless video modulator ALONE would have added a MINIMUM of $50 to the manufacturing cost, and THAT'S if they dusted off the Zenith chipset DirecTV was planning to use before the MAFIAA killed their plans for using 8VSB for whole-house HD video distribution over existing 75-ohm cable to keep the development costs down to a minimum.
Furthermore, 19.2mbit/sec MPEG-2 would utterly suck for high-contrast "computer-type" applications where you're displaying things like windows and rendered text at high resolution and framerates. If you buffered it to take advantage of predictive frames to increase the effective bandwidth, you'd end up with annoying lag. If you tried to do the whole thing with I-frames, your text would be a fuzzy macroblock-ridden mess.
I think it's partly speed. Costs have decreased, but even under the best conditions, backing up a few terrabytes of data takes a relative eternity. It's kind of OK via USB3, but USB2? Hours and hours and hours per terrabyte.
There's also a nasty bug with an entire generation of "green" Seagate drives where you can create a gigantic tarball, but when you try to read it back, the drive's firmware doesn't count "read time" as "activity", and will shut down the drive after a few hours (before it finishes copying). Last I checked, the official fix required reformatting the drive after applying the firmware patch, which won't do you much good if your first discovery of the power-save bug is when you're trying to restore the backup. You CAN get the tarball back, but you'll have to buy ANOTHER drive, then use something like dd_rescue to rip the raw sectors off in two chunks and recombine them on the new drive so you can read the tarball and get the files out of it. I spent almost a week recovering a ~1.7-terrabyte tarball from a Seagate USB2 drive for this exact reason.
> What a load of shit, there is no conceivable reason they would not allow secureboot to be turned off in the bios, > if they wanted to stop you from booting other OSes they could have locked down BIOS features decades ago, but they didn't.
Until someone decides to sell subsidized, ad-supported computers locked down to stop you from installing a different, non-adlocked OS, they slowly come to dominate the market (because normal users don't value an ad-free experience, or at least don't value being able to do things beyond what the creators of the ad-supported environment felt like supporting), and eventually a computer that's unlocked becomes an exotic niche specialty item that's nearly impossible to buy at a store like Best Buy and literally costs 10-20 times as much, partly because it's such an exotic niche item with so little demand. Sure, they'll exist... but you won't just be paying the difference between the cost of the subsidized model and whatever the subsidy is. You'll be getting completely buttfsck'ed and pay *dearly* for the privilege.
Wait, it gets better. A little while later, you'll discover that Windows no longer exists as a standalone retail product, and the only way to officially get it is to buy it with a locked-down factory-built PC. Well, OK... in theory, Windows will still exist as something you can install yourself... if you're an enterprise customer. So, you hunt down a friend who has the benefit of corporate MSDN membership from work, get him to slip you a license and a copy of Windows 17, then go home and install it. And discover that it won't play sound or 97% of the videos you have, because the DRM won't allow it since you're running in an "untrusted" environment. You get mad, successfully re-encode all your media to strip out the DRM, and chalk up a victory against The Man... then realize that Youtube still doesn't work.
It won't happen tomorrow. It won't even happen next year. But rest assured, the pot is full of water, the frog is happily swimming around, and nearly-invisible blue flames are gently caressing the bottom. The day somebody decides to start selling ad-supported PC hardware, pray to ${deity} that Microsoft firmly says, "No", Linus & Stallman have a rare moment of agreement and categorically say it's a GPL violation, and Apple recoils in horror and says "no", too.
Try asking somebody who matters, like a developer. I can see a lawyer being too clueless to know the difference between a pair of rectangular tablets. I can't fathom an Apple or Android developer with 3 functioning brain cells *ever* mistaking an iPad for a Galaxy Tab, even from 10 feet away. Hell, even the lawyer could probably tell the difference between them if they were actually TURNED ON.
Lots of things look "alike" if you don't know what to look for. People who use Android and Apple products daily know exactly what to look for (big center button, thin, and light? iPad. No big center button, thin, and light? Galaxy Tab. Fake center button on an inch-thick tablet that weighs 2 pounds and has a display that'll make your eyes bleed? Generic Rockchip-based Android tablet from Shenzhen. Badly-positioned antenna that drops 40% of its signal strength unless you hold it like a Pop Tart horizontally in front of your face, gripped in a pincer-like manner between your thumb and middle finger at the optimal location? iPhone 4. Dysfunctional GPS? Samsung Galaxy S.
> When has Apple attempted to stop someone from using something covered under one of their patents without the other party first bringing litigation against Apple?
IANAL, and I haven't read the entire patent, but it looks like Apple's new patent is specific to location services that are correlated via some fixed beacon. In other words, wireless access points broadcasting their SSIDs.
GPS satellites aren't fixed beacons, because they aren't in geostationary orbit.
Strictly speaking, cell towers could be considered beacons, but only if phones used their broadcasts to make the location decision for themselves. If you turn it around, and move the location-triangulation logic to the carrier side, it bypasses the patent because end users might meet the definition of "beacon", but they definitely don't meet any definition of "fixed".
Where Apple could really use this to fight dirty is the realm of non-GPS-based fine location (IE, more precision than cell tower based location, but not as much as someone getting a GPS fix under clear sky in an open field). In other words, the location service relied upon for services like Foursquare (where it HAS to work dependably indoors, under conditions where tower-based location isn't good enough because it might be a mile off, and GPS won't work well enough to be useful).
My prediction: Apple will try to use it to make Google quit using wifi SSID data to improve the accuracy of network-based location service, and will bully Skyhook into dropping support for Android.
> If Apple didn't hold this patent someone else would use it against them.
They might use it to extort money against Apple, but it's still an improvement over Apple's likely behavior (attempting to use it to prevent anybody else from implementing anything that looks remotely similar, period). Part of the reason why the entire mobile industry is rapidly coming to despise Apple is because they're *worse* than the worst patent troll. At least shameless patent trolls can be paid off. Patent trolls just want to steal your money. Apple wants to own your body and soul.
It's more like bureaucracy and legal liability. If the owner of an old, mothballed mall signed a lease with an "Occupy" group that explicitly allowed them to camp out, the city/county would be issuing code violations to the owner within a matter of minutes for allowing a use not in conformance with zoning codes. And if somebody got hurt (possibly by leftist instigators, possibly by over-aggressive police action, or some combination of the two), the mall's owner would be on the hook for the inevitable lawsuit (which no insurance company would EVER issue a policy against).
It's also contrary to city/county zoning/health/municipal codes for them to camp out in parks, but due to free-speech matters and their nature as public places slightly muddying the issue, enforcement isn't straightforward or necessarily legal either. In other words, it's a big legal game of chess where everybody's hands are somewhat tied and (to some extent) unclean. In effect, it's a living demonstration of "Never give a bureaucrat a chance to say no." It's rare for a bureaucrat to lose his job in a scenario where he says 'no' when he could have said 'yes', but it's easy for a bureaucrat to get fired for saying 'yes' when he had an excuse to say 'no'. When edge cases show up, it's usually in everyone's best interest to just make a token effort to not egregiously violate the spirit of a law & give enforcers an excuse to look the other way for a little while. The complication in THIS case is that the "occupy" protestors (or at least, their leaders) *want* confrontation with authority to make a political point. They don't necessarily want people getting shot in the streets, but let's face it... OWS got more free public relations and media coverage by getting forcibly evicted from the park than they would have *ever* gotten if they did nothing but peacefully smoke pot in tents out of public view, and occasionally smile at the cameras & wave signs. The tent cities made news for a few days, then faded into the background noise and ceased to matter to (or even exist in the consciousness of) 99.999% of Americans.
The problem is that due to the way patent law works in America, someone would have to be sued for infringement, then fight it in court, and win. You (generally) can't preemptively sue for an ironclad declaration of non-infringement. AFAIK, there IS a process for seeking a judgment that your use is non-infringing, but the barrier and risk is VERY high; if you lose, it's considered authoritative proof of intentional infringement if you do it anyway (and thus subject to treble damages), and if you win, you can STILL lose a later lawsuit for infringement... it just demonstrates that you made a good-faith effort to not infringe, and therefore should not be subject to treble damages. In other words, heads they win, tails you probably still lose anyway.
Another thing to remember is that you can patent a specific novel implementation of something covered by a broader patent, but it doesn't invalidate the broader patent. It just means that if somebody does the patented thing the specific way YOU patented, you can get in line behind the original patent owner and sue for infringement as well. However, a license from you would not recursively grant a license to the broader patent. In an ideal universe, there would be a fair, objective, tech-savvy arbiter who could look at the broader patent, your patent, and say, "The broader patent has merit, but your patent is what really gives it 99% of its value, so we'll allow you to license your patent, then mail a check for 1% of the amount to the owner of the broader patent & tell him to have a nice day." Unfortunately, the way it works in the real world is that the holder of the broader patent has veto power over the whole transaction, and by the time everything is said and done, you'lll be lucky to end up with the table scraps and crumbs. It's a serious shortcoming of American patent law, and unfortunately it's something that nobody has ever really come up with a good, objective, and fair way to fix.
> The BIGGEST complaint/problem with smartphones today is the lower battery life.
And it's a problem that could be 100% solved if the damn manufacturers would just make the phones a millimeter or so thicker, and give them 3000mAH+ batteries instead of wimpy 1500-1800mAH batteries.The whole reason Android phones with extended batteries end up with a pregnant hump on the back is because the battery's volume has to fit within the footprint of the OEM battery. If they went back to circuit board designs that fit together like a Chinese puzzle (daughterboards stacked onto mainboards) the way PDA phones USED to get built ~8 years ago, they could shift all the electronics to the top half, and have the entire volume of the lower half for the larger battery. Open up a phone like the HTC Evo, and 1/3 of its interior space is orange plastic mounting bracket that could have been battery if they'd shifted the components around a little more. Maybe compromise between the Apple and Android approach... give the phone a non-replaceable 1000-1500mAH battery that fills all available space and always gets charged first & drained last, and a user-swappable1800mAH battery that gets preferentially used and charged last (so it'll be the one that wears out first).
But no. They have to worry about stupid shit, like trying to make the phone 7mm thick, even though it's going to end up being more than a centimeter thick anyway after you've put it inside a well-padded Otterbox so it won't shatter into a $250 repair job the first time you drop it (a repair job that ends up being even more expensive because, in their quest to shave another.25mm from the thickness, they laminate the fucking glass onto the display so you can't just buy a $10 replacement glass on eBay... but don't get me started...).
Disclaimer: I drop things a lot, prefer to keep my phone's CPU governor locked into "Performance" mode because it pisses me off when I turn it on and have the lockscreen widget stutter and be nonresponsive because the CPU is still scaled down to 100MHz, and I'm tormented daily between the desire to use an extended battery and the certainty of the phone shattering into an expensive repair job if I do (because no composite case will fit a Photon with an extended battery).
> Except that making any reforms as you suggest will rely on the cooperation of the very parties that are enforcing the current system - because it keeps them in power
With appropriate deference and respect to Isaac Asimov, "Enter, the Mule" -- the slightly-Autistic guy from a wealthy, powerful family (or wildly-successful dotcom company) who accidentally winds up in a position of real power (or has enough wealth to throw monkey wrenches into the political establishment for kicks and giggles). No, I can't think of anyone specific... but he (or she) is out there, somewhere, and will statistically show up at some point over the next 25-35 years (it's been a few decades since the last time we had a Mule show up, so we're just about due for another one).
Slashdot Mirror
Well... there's a little more to it than that. A "phone" environment is fundamentally different in the sense that an incoming phone call usually will (and should) stop whatever else you're doing dead in its tracks until the call is dealt with. A scheduling and notification strategy optimized for realtime multiplayer games is going to be completely dysfunctional when your real-world use case involves being able to freeze the action mid-shot and take an incoming phone call, then gracefully ease back into the action when it's finished. That's why Android makes such a big deal about differentiating between "service" and "activity" -- a service can keep running when another activity has the activity focus.
If Android apps weren't forced to divide up the workflow and separate out the parts into "things that can (and should) run in the background without a user interface", and "things that only make sense when the application has focus and the user's exclusive attention", we'd have the same problems that IOS does. Where things in Android's world become confusing is the ambiguity at the "service" end, between "things that happen occasionally on a schedule" (like polling a server), "things that happen in response to something else" (incoming communication, arrival at location, change of sensor state, etc), and "things that should happen, and keep happening, until something else gives them a reason to stop" (like music playback). Complicating things more is the fact that you can sort of *get away* with doing things in background services using threads and traditional Java sleep/wait strategies, but Android will break things that insist on doing things that way in increasingly aggressive ways (particularly Gingerbread and beyond), even when they do it in ways that are considered to be perfectly legitimate and polite in mainstream Java.
Starting with Gingerbread, Android has started becoming downright mean & aggressive towards apps that use TimerTask to schedule periodic tasks in background services instead of using alarms & intents... not quite breaking apps outright, but getting VERY aggressive about killing background services that use TimerTask with partial wakelocks in ways that even a year ago would have been considered mainstream and exceptionally well-behaved (like grabbing a partial wakelock ONLY during actual network activity, to at least ensure that the phone didn't get put to sleep halfway through a http request, even if the service itself ended up suspended until the phone was awakened by something). Now, Android will kill background services after about an hour simply because it decides they've been running for "too long", even if they've been asleep in a TimerTask for most of it. I never even noticed this until I got my Photon last month, because my previous phone (Samsung Galaxy S/Epic 4G) was stuck in Froyo-land, and my app worked flawlessly on it. I knew it didn't reliably poll when the phone was asleep, but it still managed to make it work often enough to not be a big deal. Once I got the Photon, I noticed that it was just silently dying outright after about an hour, and not coming back to life after the phone was awakened.
I can see Google's logic, but I don't think they've done a particularly good job of reaching out to developers (many of whom are still stuck in Froyo-land, if only because American carriers suck & most users are still stuck with it, often including the developers themselves). Yes, the emulator exists for newer versions, but frankly, it's so slow, even on a fast quadcore PC, I'd rather tear off my fingernails one by one than suffer its slowness (and the fact that it seems to either die, or spontaneously lose contact with Eclipse, once or twice per hour, necessitating even more delay and interruption). After I bought my new Photon, my old Epic turned into my "permanently tethered to the computer development phone".
It was "digital", but not in the formal sense the FCC meant when they elsewhere talked about "digital modes".
My quoting of 5wpm/13wpm was just to clarify that I was talking about the Technician-class license back when 5wpm was required to get it, and the General-class license back when 13wpm was required to get it. I wasn't implying that they were speed limits.
I was wrong about the official designation. It's A1A, not 1A0.
I can't quote the exact rule, but apparently the FCC did manage to finally close up another loophole. Apparently, there IS now a rule buried somewhere in the regulations that formally specifies the maximum amount of bandwidth you can use within the novice/technician portion of the "CW-only" bands, and defines it in terms of effective radiated power. It's a rule that would be irrelevant if you're using CW to transmit international morse code with a straight key (or even sending it at halfway normal speeds using a computer to toggle a relay), but would become very applicable if you were broadcasting a de-facto bitbanged AM-like signal with substantial footprint via PWM by rapidly keying the transmitter on and off, regardless of intent or technicality.
Regardless of how non-edgy or non-blackhat it might have been, it was fun ;)
> In short, HDDs recognize only two states, up or down.
That hasn't been true for at least 10-15 years. Modern hard drives use variable signal strength to record multiple bits into each spot. I believe the official term someone came up with was "vertical recording". In vastly simplified terms, it boils down to this: instead of storing nothing (0) or a magnetic field (1), you store nothing, weak, moderate, or strong. 4 levels = 2 bits. Increase the sensitivity and analog-digital resolution, add some DSP magic, and the number of bits per magnetic area goes way up beyond my example with 2 bits and 4 levels to 8, 16, and more. It makes the drives cheaper to make, because instead of storing single bits at precise spots, you can store clumps of bits in slightly more loosely-defined areas.
> There is an international network of packet and pactor based systems that do this on a regular basis
The point is that we're talking about a de-facto high(er) speed quasi-digital mode being used by someone with a 1990 5wpm-code Technician-Class license who's officially authorized to do "CW", relying on a very questionable and loose interpretation of CW's old definition (turning a single carrier on and off) to achieve it in ways the original rulemakers never would have thought possible, let alone anticipated.
In contrast, Pactor by someone with what used to be a General class license with 13wpm code was never controversial, because FSK-based digital modes were always unambiguously allowed for General and above.
As for 200wpm... well, that pretty much the absolute experimental frontier of what you can make meaningfully work if you're transmitting by opening and closing a relay pretending to be a straight key connected to a HF rig, and even 200wpm is seriously pushing your luck. If you go by the "PARIS" standard, and loosely count it as the timing equivalent of 27 bits (3 per dash, 1 per dot, 1 per inter-character pause), you're looking at the equivalent of ~500 baud. At that rate, I'm kind of amazed in retrospect that it was even possible to get meaningful reception, and that the transmitter key-down distortion didn't turn sequential dots into meaningless noisy buzz.
> The FCC should have mandated GSM for the entire U.S. at the outset, as Europe and many other countries did.
You're forgetting that in the early 90s (when Sprint and Primeco-later-Verizon settled on CDMA), GSM sucked donkey balls. It was old-fashioned TDMA, with some automatic network provisioning stapled on top to make interoperability a little less painful. CDMA utterly and completely blows away pre-UMTS GSM in pure technical merit. Need proof? UMTS *is* CDMA (just wider channels and some evolutionary refinements).
Before its merger with Cingular, AT&T was contemplating a switch to CDMA back in the early 2000s. The only thing that stopped it was the fact that Cingular had already committed to GSM, and had already started building out its new network.
There's absolutely NO engineering reason why Sprint and Verizon phones can't be as fully and transparently interoperable as GSM phones in Europe. In countries like India, they *are*. CDMA even has its own superset of the SIM card standard, called "R-UIM" (which is officially now an optional subset of the USIM standard used on modern GSM phones). American phones are balkanized because that's how the carriers like it. With proper firmware and cooperation from Sprint, a Galaxy S2 intended for T-Mobile could work flawlessly on Sprint or Verizon with nothing more than updated firmware (well, ok, it would probably need official FCC certification to make it 100% legal, but the point is that all the hardware the phone needs to be physically capable of EVDO is already soldered to the motherboard, and it's purely a matter of firmware, regulatory approval, and business cooperation. The engineering problems are solved.)
>Their networks aren't compatible.
Actually, UMTS (3G GSM) and CDMA2000 aren't nearly as mutually alien as you'd think. Thanks to new chipsets like the Qualcomm MDM6600 (used in roughly half the new high-end Android phones sold worldwide), the only thing you really need to do to make a "CDMA" phone design work with UMTS is add a socket for the SIM card and support it in the firmware.
If Sprint were smart, and quietly made a point of making sure that all of their new high-end Android phones were physically capable of UMTS going forward (like the Photon, and like both the Evo3D and Galaxy S2 COULD have been if they'd bothered to include a SIM card), they could easily finish building out T-Mobile's UMTS network (using their own backhaul and tower sites in places where T-Mobile doesn't already exist natively) and update the PRL rules so that those same phones started using UMTS instead of EVDO in markets where Sprint's EVDO service was getting crowded compared to the wide open spaces of T-Mobile's UMTS service.
Search my history. About 3 months ago, I posted a mini-essay explaining how Sprint could merge with T-Mobile, continue to support both legacy GSM and CDMA voice/2G data indefinitely, become the only carrier in America physically capable of offering 1900/2100MHz UMTS service on international frequencies (using T-Mobile's 2100 spectrum, and repurposing a bit of Sprint's 1900MHz spectrum), and repurpose 1700MHz and their 800MHz Nextel spectrum for LTE.
Trust me on this... if push came to shove, Verizon is more afraid of Sprint + T-Mobile than it is of competing with a larger AT&T. Verizon would prefer to keep the status quo indefinitely and keep acquiring regional carriers of its own, but it would MUCH rather see AT&T get T-Mobile than Sprint. To Verizon's world view, AT&T is a well-behaved adversary. Sprint is a dangerous, disruptive, raging barbarian determined to overturn the neat, orderly Bell vision of society. Verizon might think AT&T's fetish with wireless over fiber is counter-productive in the long run, but it's not worried about AT&T encouraging consumers to think unlimited wireless broadband is a viable business model.
Actually, I messed up... you can use the scheme with 2 bits per code and variable-length symbols to encode uppercase and lowercase...
00 = "dot"
01 = "dash"
10 (preceded by one or more 00 and 01 codes): lowercase endmark
11 (preceded by one or more 00 and 01 codes): uppercase endmark
one or more 10 codes, without any buffered 00 or 01 ahead of them since the last 10 or 11: space
1100, 1101, and 1110: three more codes to use for things like newline, backspace, and ???
1111---- = escaped-out nirvana. I think you get the idea by now. We've got a way to represent dots, dashes, a way to mark the ends of characters in a way that indicates uppercase or lowercase, and gives alternate meanings to codes like numbers that have no meaningful concept of "uppercase".
Don't forget the deliciously geeky potential of morse(-ish) code as an alternate input method for Android phones, so you can smile attentively at everyone in the vicinity while holding the phone in your lap under the table and sending text messages ;-)
Strictly speaking, if you're willing to treat the fourth ("01") state as "space" when used once and "escape" when used twice in a row, you can meaningfully do Morse with 2-bit encoding and variable-length symbols:
"dot" = 10
"dash" = 11
"end of character" = 00
"end of word" (defaulting to "space") = 01
Some older approaches add extra states, like "inter-dash/dot pause", but when you really boil it down to the raw essence, 2 bits per dot/dash will do the job just fine.
Hell, I remember the good 'ol days circa 1992, before the FCC officially tightened up the definition of "CW", and there was a de-facto loophole in the definition big enough to drive a truck through if you were an uppity teen/twentysomething ham (like I was) with a computer, just itching to use 200wpm morse to do UUencoded file transfers between the US and Europe ;)
Back then, the official rules literally just said you were restricted to "CW", without ever really getting specific about what "CW" actually *was*. I guess they just assumed that everyone knew from tradition, and I suspect the FCC regulators were horrified to find out what guys like me were up to in the final dark days before widespread worldwide internet connectivity.
NOW, the rule explicitly defines the "mode" as "1A0", and explicitly says it has to be "plain text". It doesn't quite go as far as stipulating morse code, but I think I read a non-binding FCC opinion someplace where they basically said occasional adhoc prosigns are OK as long as they're published SOMEWHERE and your intent isn't to conceal what you're sending, but hex-encoded UTF8 and any kind of binary-encoded file is absolutely beyond the pale.
In a way, I can see why they clamped down a bit. At the time I didn't have the RF or digital electronics background to know it, but I now know that turning a carrier on and off is neither instantaneous nor consequence-free, and when you do it fast enough, you're basically bit-banging de-facto AM via PWM and square-wave artifacts that's going to splatter over a MUCH wider chunk of spectrum than a carrier being slowly turned on and off by a straight key.
The problem is that Android's permissions, like most of the API, does a good job of offering general-purpose ways to do things, but does a piss poor job of bundling things into neatly-packaged convenience methods that make it easy to just Do The Right Thing.
Nobody (at Google) has ever really sat down and said, "How can we provide a system-level library that can support the needs of a service like AdMob (without being specific to AdMob itself), then create a specific set of permissions that grant exactly what's needed and nothing more to achieve the specific task of serving location-targeted ads to anonymous users who can be tracked in the aggregate.
It has to be system-level, and have specific requirements for hardcoding things like the adserver's base URL and app id in the manifest, because otherwise a cloaked malware app could use it to leak information to the outside world without being obvious about it. For example:
* The app can request a new ad, but Android introduces a random delay whose maximum value increases as the number of refresh requests does. This is necessary to make time-based attacks (where you modulate leaked information into the request rate itself, treating the request rate like a form of morse code) more difficult. You can't eliminate them completely, but you can make it very hard to convey more than a few bits per minute.
* The location comes straight from Android's location services (GPS, network, or both) and gets automatically rounded down to the desired level of accuracy (say, quarter-degree, tenth-degree, or hundredth-degree). This prevents apps from trying to encode data into the lower bits of the location.
* The URL of the web service that gets queried for the image and click-target URL is hardcoded into the manifest, with the ability to specify multiple in either failover or round-robin style.
* The user ID passed to that web service is handled directly by Android, and the app never gets to touch it. It's randomly generated by Android, and comes in two flavors that are specified by the permissions itself: global to a physical phone, but not associated with a specific identity (ie, if you buy a new phone, your ID changes; it's not associated with your Google ID), or anonymously associated with a specific user and a specific application. In other words, if you're logged on to your phone and tablet with the same Google ID, you'd have the same anonymized ad id when requesting ads in the same app on both devices, but different apps would have different IDs. Any attempt to correlate the two, or to correlate ad ids with real-world identities, would be forbidden by EULA with staggeringly huge liquidated damages payable to both Google and the end user.
The format of the image URL is problematic, because there's a very fine line between flexibility and giving malware the opportunity to leak user information via the URL itself. On one hand, you need an address space large enough to accommodate different images for different advertisers and campaigns, but you don't want to give too many extra bits to tempt companies into trying to encode extra information about the user himself into them. I'd propose something like the following:
Baseurl: rigidly specified in the manifest, with provisions to specify multiple for failover and loadbalancing purposes.
Density: automatically substituted in by Android based upon LDPI/MDPI/HDPI/XDPI
Width: alternative to Density, equal to number of horizontal pixels in current orientation. Mainly, for people like me who hate the way Android deals with 540x960 qHD (I despise scaling and prefer to serve images at native resolution), and the coming trainwreck differentiating between 720x1280 on a 4.5" screen and 1280x800 on a 10" screen.
App ID: hardcoded in manifest
Target-intent and Notification-intent: ooh. These are rough. On one hand, you need flexibility to deliver clicks to the appropriate destination... but too much, and it's another information-leakage nightmare. My current hunch is that you'd
Actually, it does. When the opportunity cost of collecting and analyzing data is high, it doesn't really matter whether it's being collected. When anybody can turn around and do data mining on it with trivial ease, it becomes quite important. Nobody cared about social security numbers being printed in recorded court documents until they became available online, and people didn't become *neurotic* about retroactively redacting them until thirdparties started scraping, OCR'ing, and data-mining those same documents.
What I want to know is why, to this day, it's still legal for municipalities in Florida to sell liens, then record literally a semi-truck of liens recorded against "John Doe" at the courthouse ~2 years later, instead of being required to electronically associate those same liens with the property's globally-unique folio number, so somebody who goes to BUY the property can conveniently find them all in 12 seconds. Instead, cities like Miami can shrug and say, "We sold a lien to somebody 3 years ago, but we didn't keep track of who we sold it to, and we filed it with 300,000 other liens on the same day at the courthouse under "John Doe", so you're just going to have to wait 4 years until the person officially redeems it, or literally spend 3 months looking for a needle in a haystack one record at a time until you manage to trip over it. Assuming we didn't make a typo." It's positively *insane* how easy it is for municipalities in Florida to pile on fines without making even the most trivial effort to notify property owners, and record liens that could end with a property being sold for literally pennies on the thousand-dollar with breathtaking recklessness that seems almost inconceivable. You read in papers about how careless mortgage companies were with paperwork (their excuse for just making up replacement paperwork with robo-signers as they go along), but it's *nothing* compared to how simultaneously careless Florida municipalities are allowed to be, and how ruthless they're allowed to be in spite of their carelessness.
He's not talking about HDMI. He's talking about wireless. Unless you're talking about a $800+ wireless HDMI system, that basically means broadcast 8VSB or COFDM, which means 19.2mbit/sec MPEG-2.
Because you'd have to transform the display into a MPEG-2 data stream with maximum bitrate of 19.2mbit/sec, then modulate it onto an 8-VSB carrier (to work in the US) and COFDM (to work in most other places). It's nontrivial. 8-VSB, in particular, is a bitch to do. The wireless video modulator ALONE would have added a MINIMUM of $50 to the manufacturing cost, and THAT'S if they dusted off the Zenith chipset DirecTV was planning to use before the MAFIAA killed their plans for using 8VSB for whole-house HD video distribution over existing 75-ohm cable to keep the development costs down to a minimum.
Furthermore, 19.2mbit/sec MPEG-2 would utterly suck for high-contrast "computer-type" applications where you're displaying things like windows and rendered text at high resolution and framerates. If you buffered it to take advantage of predictive frames to increase the effective bandwidth, you'd end up with annoying lag. If you tried to do the whole thing with I-frames, your text would be a fuzzy macroblock-ridden mess.
I think it's partly speed. Costs have decreased, but even under the best conditions, backing up a few terrabytes of data takes a relative eternity. It's kind of OK via USB3, but USB2? Hours and hours and hours per terrabyte.
There's also a nasty bug with an entire generation of "green" Seagate drives where you can create a gigantic tarball, but when you try to read it back, the drive's firmware doesn't count "read time" as "activity", and will shut down the drive after a few hours (before it finishes copying). Last I checked, the official fix required reformatting the drive after applying the firmware patch, which won't do you much good if your first discovery of the power-save bug is when you're trying to restore the backup. You CAN get the tarball back, but you'll have to buy ANOTHER drive, then use something like dd_rescue to rip the raw sectors off in two chunks and recombine them on the new drive so you can read the tarball and get the files out of it. I spent almost a week recovering a ~1.7-terrabyte tarball from a Seagate USB2 drive for this exact reason.
> What a load of shit, there is no conceivable reason they would not allow secureboot to be turned off in the bios,
> if they wanted to stop you from booting other OSes they could have locked down BIOS features decades ago, but they didn't.
Until someone decides to sell subsidized, ad-supported computers locked down to stop you from installing a different, non-adlocked OS, they slowly come to dominate the market (because normal users don't value an ad-free experience, or at least don't value being able to do things beyond what the creators of the ad-supported environment felt like supporting), and eventually a computer that's unlocked becomes an exotic niche specialty item that's nearly impossible to buy at a store like Best Buy and literally costs 10-20 times as much, partly because it's such an exotic niche item with so little demand. Sure, they'll exist... but you won't just be paying the difference between the cost of the subsidized model and whatever the subsidy is. You'll be getting completely buttfsck'ed and pay *dearly* for the privilege.
Wait, it gets better. A little while later, you'll discover that Windows no longer exists as a standalone retail product, and the only way to officially get it is to buy it with a locked-down factory-built PC. Well, OK... in theory, Windows will still exist as something you can install yourself... if you're an enterprise customer. So, you hunt down a friend who has the benefit of corporate MSDN membership from work, get him to slip you a license and a copy of Windows 17, then go home and install it. And discover that it won't play sound or 97% of the videos you have, because the DRM won't allow it since you're running in an "untrusted" environment. You get mad, successfully re-encode all your media to strip out the DRM, and chalk up a victory against The Man... then realize that Youtube still doesn't work.
It won't happen tomorrow. It won't even happen next year. But rest assured, the pot is full of water, the frog is happily swimming around, and nearly-invisible blue flames are gently caressing the bottom. The day somebody decides to start selling ad-supported PC hardware, pray to ${deity} that Microsoft firmly says, "No", Linus & Stallman have a rare moment of agreement and categorically say it's a GPL violation, and Apple recoils in horror and says "no", too.
Try asking somebody who matters, like a developer. I can see a lawyer being too clueless to know the difference between a pair of rectangular tablets. I can't fathom an Apple or Android developer with 3 functioning brain cells *ever* mistaking an iPad for a Galaxy Tab, even from 10 feet away. Hell, even the lawyer could probably tell the difference between them if they were actually TURNED ON.
Lots of things look "alike" if you don't know what to look for. People who use Android and Apple products daily know exactly what to look for (big center button, thin, and light? iPad. No big center button, thin, and light? Galaxy Tab. Fake center button on an inch-thick tablet that weighs 2 pounds and has a display that'll make your eyes bleed? Generic Rockchip-based Android tablet from Shenzhen. Badly-positioned antenna that drops 40% of its signal strength unless you hold it like a Pop Tart horizontally in front of your face, gripped in a pincer-like manner between your thumb and middle finger at the optimal location? iPhone 4. Dysfunctional GPS? Samsung Galaxy S.
> When has Apple attempted to stop someone from using something covered under one of their patents without the other party first bringing litigation against Apple?
Ummm... can we say, "Samsung?"
IANAL, and I haven't read the entire patent, but it looks like Apple's new patent is specific to location services that are correlated via some fixed beacon. In other words, wireless access points broadcasting their SSIDs.
GPS satellites aren't fixed beacons, because they aren't in geostationary orbit.
Strictly speaking, cell towers could be considered beacons, but only if phones used their broadcasts to make the location decision for themselves. If you turn it around, and move the location-triangulation logic to the carrier side, it bypasses the patent because end users might meet the definition of "beacon", but they definitely don't meet any definition of "fixed".
Where Apple could really use this to fight dirty is the realm of non-GPS-based fine location (IE, more precision than cell tower based location, but not as much as someone getting a GPS fix under clear sky in an open field). In other words, the location service relied upon for services like Foursquare (where it HAS to work dependably indoors, under conditions where tower-based location isn't good enough because it might be a mile off, and GPS won't work well enough to be useful).
My prediction: Apple will try to use it to make Google quit using wifi SSID data to improve the accuracy of network-based location service, and will bully Skyhook into dropping support for Android.
> If Apple didn't hold this patent someone else would use it against them.
They might use it to extort money against Apple, but it's still an improvement over Apple's likely behavior (attempting to use it to prevent anybody else from implementing anything that looks remotely similar, period). Part of the reason why the entire mobile industry is rapidly coming to despise Apple is because they're *worse* than the worst patent troll. At least shameless patent trolls can be paid off. Patent trolls just want to steal your money. Apple wants to own your body and soul.
It's more like bureaucracy and legal liability. If the owner of an old, mothballed mall signed a lease with an "Occupy" group that explicitly allowed them to camp out, the city/county would be issuing code violations to the owner within a matter of minutes for allowing a use not in conformance with zoning codes. And if somebody got hurt (possibly by leftist instigators, possibly by over-aggressive police action, or some combination of the two), the mall's owner would be on the hook for the inevitable lawsuit (which no insurance company would EVER issue a policy against).
It's also contrary to city/county zoning/health/municipal codes for them to camp out in parks, but due to free-speech matters and their nature as public places slightly muddying the issue, enforcement isn't straightforward or necessarily legal either. In other words, it's a big legal game of chess where everybody's hands are somewhat tied and (to some extent) unclean. In effect, it's a living demonstration of "Never give a bureaucrat a chance to say no." It's rare for a bureaucrat to lose his job in a scenario where he says 'no' when he could have said 'yes', but it's easy for a bureaucrat to get fired for saying 'yes' when he had an excuse to say 'no'. When edge cases show up, it's usually in everyone's best interest to just make a token effort to not egregiously violate the spirit of a law & give enforcers an excuse to look the other way for a little while. The complication in THIS case is that the "occupy" protestors (or at least, their leaders) *want* confrontation with authority to make a political point. They don't necessarily want people getting shot in the streets, but let's face it... OWS got more free public relations and media coverage by getting forcibly evicted from the park than they would have *ever* gotten if they did nothing but peacefully smoke pot in tents out of public view, and occasionally smile at the cameras & wave signs. The tent cities made news for a few days, then faded into the background noise and ceased to matter to (or even exist in the consciousness of) 99.999% of Americans.
The problem is that due to the way patent law works in America, someone would have to be sued for infringement, then fight it in court, and win. You (generally) can't preemptively sue for an ironclad declaration of non-infringement. AFAIK, there IS a process for seeking a judgment that your use is non-infringing, but the barrier and risk is VERY high; if you lose, it's considered authoritative proof of intentional infringement if you do it anyway (and thus subject to treble damages), and if you win, you can STILL lose a later lawsuit for infringement... it just demonstrates that you made a good-faith effort to not infringe, and therefore should not be subject to treble damages. In other words, heads they win, tails you probably still lose anyway.
Another thing to remember is that you can patent a specific novel implementation of something covered by a broader patent, but it doesn't invalidate the broader patent. It just means that if somebody does the patented thing the specific way YOU patented, you can get in line behind the original patent owner and sue for infringement as well. However, a license from you would not recursively grant a license to the broader patent. In an ideal universe, there would be a fair, objective, tech-savvy arbiter who could look at the broader patent, your patent, and say, "The broader patent has merit, but your patent is what really gives it 99% of its value, so we'll allow you to license your patent, then mail a check for 1% of the amount to the owner of the broader patent & tell him to have a nice day." Unfortunately, the way it works in the real world is that the holder of the broader patent has veto power over the whole transaction, and by the time everything is said and done, you'lll be lucky to end up with the table scraps and crumbs. It's a serious shortcoming of American patent law, and unfortunately it's something that nobody has ever really come up with a good, objective, and fair way to fix.
> The BIGGEST complaint/problem with smartphones today is the lower battery life.
And it's a problem that could be 100% solved if the damn manufacturers would just make the phones a millimeter or so thicker, and give them 3000mAH+ batteries instead of wimpy 1500-1800mAH batteries.The whole reason Android phones with extended batteries end up with a pregnant hump on the back is because the battery's volume has to fit within the footprint of the OEM battery. If they went back to circuit board designs that fit together like a Chinese puzzle (daughterboards stacked onto mainboards) the way PDA phones USED to get built ~8 years ago, they could shift all the electronics to the top half, and have the entire volume of the lower half for the larger battery. Open up a phone like the HTC Evo, and 1/3 of its interior space is orange plastic mounting bracket that could have been battery if they'd shifted the components around a little more. Maybe compromise between the Apple and Android approach... give the phone a non-replaceable 1000-1500mAH battery that fills all available space and always gets charged first & drained last, and a user-swappable1800mAH battery that gets preferentially used and charged last (so it'll be the one that wears out first).
But no. They have to worry about stupid shit, like trying to make the phone 7mm thick, even though it's going to end up being more than a centimeter thick anyway after you've put it inside a well-padded Otterbox so it won't shatter into a $250 repair job the first time you drop it (a repair job that ends up being even more expensive because, in their quest to shave another .25mm from the thickness, they laminate the fucking glass onto the display so you can't just buy a $10 replacement glass on eBay... but don't get me started...).
Disclaimer: I drop things a lot, prefer to keep my phone's CPU governor locked into "Performance" mode because it pisses me off when I turn it on and have the lockscreen widget stutter and be nonresponsive because the CPU is still scaled down to 100MHz, and I'm tormented daily between the desire to use an extended battery and the certainty of the phone shattering into an expensive repair job if I do (because no composite case will fit a Photon with an extended battery).
Try OLED. You can almost feel your retina sizzle when you view one in a dark environment ;-)
> Except that making any reforms as you suggest will rely on the cooperation of the very parties that are enforcing the current system - because it keeps them in power
With appropriate deference and respect to Isaac Asimov, "Enter, the Mule" -- the slightly-Autistic guy from a wealthy, powerful family (or wildly-successful dotcom company) who accidentally winds up in a position of real power (or has enough wealth to throw monkey wrenches into the political establishment for kicks and giggles). No, I can't think of anyone specific... but he (or she) is out there, somewhere, and will statistically show up at some point over the next 25-35 years (it's been a few decades since the last time we had a Mule show up, so we're just about due for another one).