As I understand it, the intent of a patent is to protect the value of the invention to the inventor by giving them exclusive control of the rights to use said invention. In return, they are asked to encourage future innovation by sharing that information with the world instead of keeping it a proprietary secret. Pretty simple and straightforward, and I really have a hard time disagreeing with that being a desirable goal.

Most of the complaints about the patent system being “broken” come down to a few points:

1. The patent is not novel; it’s an obvious method to anyone spending any mental effort on the problem space.
2. The patent is too broad; It could cover any number of possible techniques without taking a stand on one (or a handful). This usually seems to be done to get around the requirement of sharing the information, keeping aspects proprietary. One might also consider this related to “not novel.”
3. The inventor (or, usually, reassigned rights holder commonly referred to as “patent troll”) has done nothing with their rights to the patent on their own. On its own, there is nothing wrong with this–it would be perfectly legitimate to have a sole licensee. When combined with items 1 or 2, though, most people agree that it’s is predatory and stifles innovation rather than encouraging it.

My Proposal: Within a defined grace period after patent status is granted (I’m envisioning 5 years, maybe 7), the patent holder must show measurable revenue due to a concrete implementation of the patent, or that it is a recognizable part of another product which generates recognizable revenue. This revenue may be recognized directly by the inventor, or by licensees of the patent. If such evidence is not given within the grace period, the patent is considered fallow and control rights are revoked.

A patent that does not result in a concrete implementation within a reasonable period of time is hard to consider as “benefitting society” and thus unworthy of the rights exclusivity granted by the society in exchange.

Comments(1)

(There is no Easter-related content here; the timing is pure coincidence.)

I just received word that the 2.0 update to ESPN Passport–the last fruits of my contracting with the fine folks of RogueSheep before joining Black Pixel–went live on the App Store today. What started out as “add Facebook Places functionality” became a much smoother, more efficient and focused application that I was proud to have a part in.

If you’re at all interested in adding a social network aspect to your sports watching, go check it out. It’s free, but you’ll need to sign up for a free ESPN Passport login to get the most out of it (Facebook and Twitter logins add even more).

(By the way, have you tried RogueSheep’s latest app, Easy Alarms? I played no part in it, but it rocks all the same.)

Comments(0)

The One In Which Paul Talks Out His Hat (metaphorically, since he and hats don’t get along).

During an entertaining aside in Andy Ihnatko‘s keynote at this weekend’s Voices That Matter conference, I was reminded of a thought I’d had a while ago: Why don’t Mac desktop applications store their license info in the Keychain?

Complaining about restoring license keys should be just as trite of a humor topic as little bags of peanuts on flights, but it still holds true. Go to restore a machine, or move to a new one with a clean install, and you can write off at least an afternoon launching and entering at least two text fields per application.

Maybe I’m the only one who feels quite comfortable with syncing to MobileMe–I actually consider it the feature that keeps me coming back. (I do know there are people who have frustrating issues, and I truly feel for them, but I continue to believe they are in the minority.) Given that setup, here’s how I’d see setting up a new laptop:

1. Configure my MobileMe account and sync down the data, setting up my Mail accounts, Address Book and Calendar–and Keychain.
2. Launch a new copy of my licensed application.
3. There is no Step Three. Go on your merry way.

I’m not expert enough to suggest that it would improve security of your key, but it sure would discourage casual tweaking more than the plist or hidden file schemes you’d need to develop on your own. Also, separation of license key from a preferences file (hopefully developers are already doing this) allows a user to delete the preferences and start fresh without having to worry about relicensing.

I understand that Keychain development can be convoluted, but is that reason enough to not make the user’s life a little bit easier and your support burden of finding a lost license a little less frequent?

As I said at the top, I realize I’m talking out of my…hat here. I don’t have experience doing this (yet), so I am interested in hearing reasoned arguments. Until and unless this is proven untenable, simply consider it a feature request for your next release.

Comments(7)

Apple released iOS 4.3 yesterday, and it looks like iTunes Home Sharing provides almost everything I had wished for in my original post.

There seem to be some quirks (all videos and podcasts are marked as unplayed on the device) and other behaviors I’d like changed (watching/listening to a podcast on the device doesn’t report that to the shared library). These niggles are really just small issues compared to the big advance of having access to my full library.

Thank you, iOS team!

Comments(0)

It’s still the first half of January, so I’m in the grace period for a “Year in Review” post.

2010 was one heck of a slingshot year for me and Corporation Unknown. I started the year unemployed and thin on contract work, and finished it with Corporation Unknown’s highest revenue in its 3-year history and a job offer I can’t refuse.

(Read the article)

Comments(1)

I ran down a strange bug yesterday that I thought I would recount in the hopes of saving someone else the half day of frustration.

I was going along, minding my own business, implementing a typical -tableView:didSelectRowAtIndexPath: delegate method to create a view controller, push it onto the navigation stack, and then…nothing. The view didn’t appear, and the app interface became unresponsive. Numerous pauses in the debugger showed what would appear to be normal stacks in the running of the app–no infinite recursion going on, thankfully.

The view was actually in a strange nesting of UITableViewControllers, UINavigationControllers and UITabBarControllers, so I reworked that to the bare bones of a UITableViewController pushing a freshly made UITableViewController onto its navigationController. I verified that it was being initialized properly, and that I had a valid navigationController to push onto (and other view controllers did push with the same navigationController). Still no change.

(Read the article)

Comments(0)

Today, Tim Bray commented about Android applications needing to frequently save their restore state and be ready and able to gracefully terminate without notice. (This behavior also applies to iOS apps, of which I have much more experience than Android.)

At some point, after I’d explained a few times why you have to write software this way on Android, I started wondering why all software, without exception, isn’t written this way by default.

As of 10.6, Apple added enableSuddenTermination and disableSuddenTermination calls to the NSProcessInfo API to allow you to implement similar behavior on the desktop. At its most simplistic description, you can inform the system your application doesn’t need to have its memory paged back in just to destroy it all–just kill the process and you will be sure it behaves properly on relaunch.

I encourage all fellow iOS developers who have already acquired a “sudden termination” design style to make note of this when developing a desktop Cocoa application; I also encourage desktop Cocoa developers to start thinking about how they would design with this paradigm, as it will be one more portable technique when and if you decide to go mobile.

(NSCache and Purgeable Memory is another new-to-10.6 mechanism I consider similar to iOS’ didReceiveMemoryWarning, only giving the OS permission to purge memory instead of it requesting you clean up.)

Comments(0)

Yesterday I tweeted about a feature I would like:

Want: iPod on iPad able to browse desktop iTunes à la Home Sharing. Watching WWDC videos on iPad w/o having to sync first–yum.

I received a few recommendations for Air Video and StreamToMe. I’d forgotten that I’d downloaded Air Video but hadn’t set up the server; I’d also forgotten about StreamToMe even though I subscribe to Matt Gallagher’s blog.

I fired up the Air Video Server and started it serving the iTunes U playlist. Connecting and browsing from the iPad client was simple and straightforward. Trying to stream a WWDC video paused to buffer annoyingly often–which I blame less on the software than the 2GHz Mini it was running on, which probably also had the misfortune to have Time Machine kick in at the same time. But it doesn’t seem to have a functionality I implied by the “Home Sharing” reference: Copy the video to the iPad to watch elsewhere later. StreamToMe looks to have similar features (and lack thereof) to Air Video, so I didn’t test it.

I appreciate the recommendations, I really do. But neither of these can get past the one requirement I didn’t specify: I don’t want a third-party solution. My tweet was really a passive-aggressive desire to have Apple implement this.

(Read the article)

Comments(1)

Due to “overwhelming demand,” I am sharing my configuration set for Accessorizer here. I think there needs to be some explanation to many of the decisions, though, so here you go. This is not intended to be an interminable discussion of coding style and practices, though–if you disagree, go ahead and make your own configuration based on mine. This is also not intended as comprehensive documentation for Accessorizer–read its included documentation, explore tooltips, and experiment freely.

(Read the article)

Comments(0)