Today's spurious software patent is...

Sadly, on any random day, we could probably pick a case like this. Today it appears to be Spotify's turn to face a lawsuit for "infringement" of a spurious patent that should never have been granted in the first place.

The abstract of the patent begins:

"In order to distribute music information from a central memory device (2) via a communications network (4) to a terminal (6), this information is organized in a digital music information object."

As you can probably guess from this opening line, and sadly like so many other "software" patents, the rest is pure flannel: a very broad overview of the blindingly obvious steps that one would take in designing an application, but without having actually invented any non-obvious implementational details. Pretty much every line of the patent leaves you coming away thinking "Sure, that's obviously true, but what's your actual invention?". It's another example of how the patent system urgently needs to be reformed with at least:

- patent examination which goes beyond the intelligence of a chimpanzee on hallucinogenics (or as a next best thing, to paraphrase Donald Knuth slightly: if you would expect a 1st year software engineering student to be able to solve a problem as a homework assignment, you shouldn't be able to patent the solution as an "invention");
- severe punishment for companies that attempt to file spurious patents;
- more severe punishment for false claims of infringement (such measures do already exist to discourage large companies from bullying small developers, but they clearly don't go far enough).

There's also an interesting article in this week's Pod Delusion on the subject of patent trolls, looking at another recent case of patent abuse (Lodsys-Apple).

There's no hiding from ngram analysis

It's not often that a corpus linguistics paper makes it to Slashdot. A notable exception today came in the form of Burger et al's paper on Discriminating Gender on Twitter. Using surprisingly simple techniques, they present data suggesting that a machine algorithm can determine a tweeter's gender more reliably than human judges.

As far as I can see, their measure of reliability is of the % of correctly attributed tweets over the data set as a whole. It would be interesting to see more analysis on the nature of tweets that the system can't judge reliably vs human judges (and vice versa). To what extent do typical tweets fall into polarised categories of "readily categorisable" vs "highly ambiguous", or is there more gradience? And it will be interesting to see what other demographic data can be gleaned using similar techniques.

Estoppel

Following on from my post yesterday about how a statement in Jonathan Schwartz's blog post indicated that Sun approved Google's use of Java in Android, I should perhaps have pointed out-- as others reporting on this have-- that there is indeed a judicial basis for Schwartz's statement being used in Google's defense. The principle is estoppel, defined by Black's Law Dictionary as:

"An affirmative defense alleging good-faith reliance on a misleading representation and an injury or detrimental change in position resulting from that reliance."

Will Jonathan Schwartz's blog post finally persuade Oracle to pick its toys up and put them back in the pram?

In case you've missed all the commotion, or just found it a little bit dull, I remind you that in August 2010, Oracle filed suit against Google, claiming that their Android operating system violates various patents held by Oracle after they acquired Sun Microsystems.

The extent of damages that they can actually claim for appears to be in some doubt. After an initial claim of several billion dollars, and a judge effectively ruling "don't be so silly" last week, the claim may be reduced to as "little" as 100 million dollars. If I had 100 million dollars, I wouldn't be sitting round writing silly blog posts. But to Google, that's petty cash.

Now, to naive bystanding programmers such as myself who are not lawyers, a few things always seemed a little bit odd about this case:

• would a company the size of Google with the legal resources it can afford really just go ahead and commit billions of dollars worth of patent infringement and hope that "nobody would notice"?
• if there was a big problem with Android's use of Java technology, why didn't Sun raise this at the time?
• some of the patents in question really boil down to some quite small, specific points of implementation (e.g. specific details of implementation of protection domains, the "pre-processing and packaging of class files", and some implementational details of the virtual machine), many of which could probably be worked around by using alternative implementations or (and hence) a reasonable licence fee negotiated with Sun if need be.

Or put another way, the whole case smells of somebody scratting around through their recently acquired arsenal of patents looking for an excuse to sue. Rather than learning to play happily with all the other children in the classroom, Oracle seems intent on shouting "But Miss, the red crayons are mine!".

Meanwhile, commentators had noticed the curious deletion of blog posts of previous Sun CEO Jonathan Schwartz. Unfortunately, such Orwellian attempts to rewrite history don't tend to work on the Internet. Thanks to nothing more sophisticated than a search in The Way Back Machine, a key post from "Jonathan's Blog" has been restored to its former glory. And in this post, Schwartz states: "I just wanted to add my voice to the chorus of others from Sun in offering my heartfelt congratulations to Google on the ennouncement of their new Java/Linux phone platform, Android". As commentator Steven Vaughan-Nichols has also pointed out, this doesn't exactly sound like Sun were saying "We disapprove of Android because it violates our patents and will be suing Google for billions of dollars".

It will be interesting to see if this evidence can persuade the two parties to finally bang their heads together and get on with more interesting things. Like it or lump it, Android is a key market for Java technology, with Android accounting for a 30% share of tablet shipments in April-June 2011, for example. I can't help feeling that it would be more conducive to the platform's development for Oracle and Google to have a more sensible working relationship.

Google's malware warning

Google have given more details of the malware warning that they will be issuing at the top of their search engine. They have been able to identify around 2,000,000 infected machines on the basis of traffic sent to their servers.

A couple of things strike me about this:

• I wonder how applicable this technique could be to other servers in general? Could we see other sites performing a similar civic duty of warning users about potential malware.
• Given that one route of infection (which Google blames specifically as the culprit in this case) are those fake "Your computer has been infected" popups already littering the Internet, how do we give out a message to users that these popups should generally be ignored because they're likely to be fake, whilst at the same time issuing genuine warnings in an ostensibly similar manner?

I'm interested to hear your thoughts either here, or by tweeting to BitterCoffey.

Dear universe: please make your default settings sensible

I'd occasionally noticed that alerts for my calendar events would sometimes go off at odd times on my iPad. For example, I'd wake up in the morning to find that the "5 minute" alert for a mid-morning meeting had already gone off. I suppose the first couple of times, I just assumed I must have entered something wrong when setting up the event. But, being the aspiring cross between Columbo and Paddington Bear that I am, gradually my suspicions were aroused.

Luckily, some other people more patient than I am with spuriously designed user interfaces were able to come to the rescue. In case you haven't found it, the offending setting is an option burried in the "Mail, Contacts, Calendars" section of your iPhone/iPad settings curiously entitled "Time Zone Support". With this set to a particular Time Zone (rathr than simply being switched off), then your device will not adjust calendar events to match your current time zone.

So you might be thinking "hey, what's your beef, this is a great feature to have, no?". Well, yes, it's a great optional feature. But the things that strike me are:

(a) to say that the iPhone/iPad are supposed to be the holy grail of PDAs (aren't they?), it doesn't seem like a terribly fine-grained feature, particular as there is a "Location" field in calendar events, and that thanks to the miracles of GPS, the device knows where you are at any given moment (or at least, knows where you are to within an approximation of a couple of skyscrapers/underground bunkers-- usually good enough to tell what time zone you're in);
(b) why give this option a silly, non-intuitive name and then turn it on by default? why by default would I tend to want events not to be in synch with where I am at the moment, given that the whole raison d'être of these devices is for travelling...?

Well, I'm sort of happy now I've discovered the option. But on the other hand, grrrrrr.

Rip-off for rip-off's sake

In response to crackpot loon conspiracy theories that instead of landing on the moon in 1969, Nasa played a hoax that has then been kept under wraps for the past 40 odd years, my argument has always been that rather than stage and hide such an elaborate hoax, it's probably easier just to go to the moon. (The other main evidence for the falsity of the moon landing hoax being that Fox TV made a documentary about it...)

Well, my grip on reality may have been overturned today by reports and pictures of fake Apple stores in China. Somebody who can actually be bothered to go to these lengths of counterfeiting and then sustain the momentum of preventing the relevant authorities from finding out must be doing it out of some bizarre sense of national pride. I'm really not convinced it isn't easier to just franchise a genuine Apple store...

On the dangers of our reliance on opaque algorithms

Kevin Slavin offers an illuminating TED presentation on the implications of our reliance on computer algorithms whose complexity has reached the point of being opaque to human understanding.

The fine lines of iPhone app rules

"It's not whether there is anything wrong. It's whether or not there appears to be."

It appears that app developer Daniel Amitay has been finding out recently about the finely shaded grey areas of Apple's rules on what you can and can't do from an iPhone app.

One of Daniel's apps, Big Brother Camera Security, is designed to mimic the iPhone passcode screen and then photograph any user making an incorrect attempt to enter the passcode. He also decided to collect statistics on the most common passcodes chosen by users by having the app anonymously send those passcodes. Apple have since removed the app from the App Store.

Daniel argues on his blog that this data collection was legitimate, as the purpose was to warn users against choosing frequently chosen passcodes in a future update to the app, and the the App Store EULA informs users that apps may collect diagnostic data. Apple, on the other hand, appear to be arguing that application was "surreptitiously harvesting user paasswords".

It seems that whether that is strictly the case depends at least on one's interpretation of what "harvesting" constitutes, and how one defines the nature of the separation between the app's lock code and the actual iPhone passcode, given that the app is designed to simulate the iPhone lockup screen. A potentially complicating factor is that the data has also been used as the basis for a (somewhat interesting) article that Daniel has published giving an overview of the statistics obtained for the most common passcodes and most common digits in different positions. Publishing this article, though of interest to the security community, may be deemed to make the data something other than for diagnostic purposes of "facilitat[ing] the provision of software updates, product support and other services [...] related to the Licensed Application" as set out in the App Store EULA.

Some interesting questions to consider:

• if secure hashes of the passcodes, rather than the actual passcodes, had been sent, would that have constituted "harvesting"? (Even though with only 1000 possibilities, the actual codes could of course be resolved from the hashes.)
  
• which precise conditions would need to be changed to allow Apple to approve the app? (Is it ultimately the data itself or the surreptitiousness that is the problem? or the publishing of the data in an article not strictly necessary to updating and supporting the app?)

It will be ineteresting to see how this case evolves over the coming days/weeks and whether Daniel is ultimately successful in getting the app reinstated, and what changes are necessary for this to happen.