A week ago Thursday, I spoke about software patents and intellectual property to the Twin Cities CocoaHeads developer group.  This was my first significant presentation on the topic and  I was concerned about how it would be received: developers have a very low opinion of patent law, even worse now in light of recent events regarding Lodsys and Macrosolve.  I’m delighted to say that everything went brilliantly!  In fact, one of the most active participants later admitted that he had expected to sleep through the presentation. The presentation itself went extremely well: we had a fully engaged audience, lots of questions, and provided valuable information on a difficult topic.  But more than that, I learned a great deal about presenting this topic to developers.

I like to think of myself as very knowledgeable about intellectual property and software patents, but I have no illusions on the subject: I have not attended law school, I don’t practice IP law, and I have no first-hand experience in these issues.  The last thing that I want to do is give bad advice, so when in doubt … invite a practicing patent attorney to co-present!

Speaking of which, I want to give credit to my co-presenter, Patrick Kendrick of Fogg and Powers LLC.  Patrick did a phenomenal job both of handling the subject matter and addressing the group’s questions.  I could not have had a better team-mate.

What worked:

Have a software developer present the subject: since I am not an attorney, everything I presented was at a level that was easily understood by developers.  No offense to either IP attorneys or developers, they are both pretty smart demographic groups, and they both have their own professional “language” which is harder for others to understand.  While I stumbled upon this insight by sheer dumb luck, I am confident that it is the right way to present and I will plan all of my future presentations this way.

Have a practicing attorney co-present: this is a complicated enough topic that it would be easy to get wrong.  When I did answer a question incorrectly, Patrick was right there to keep me honest and clarify the issue.  I must admit that it’s quite a humbling experience, but given that the only other choice was defending my admittedly inferior knowledge of IP law, I took the high road and said “I stand corrected.”  Even if I was completely accurate in the presentation, there is no way I could have answered the questions adequately.  My point is that there is no substitute for the insight which a practicing patent attorney brings to the conversation.  As above, this is now part of my standard format for these presentations.

Lead a discussion: I’m not sure if this is necessary, but it certainly worked well Thursday.  The downside was that the audience didn’t necessarily ask questions in the same order as my presentation notes, and I had to say “We’ll get to that shortly” a couple of times.  What I think a discussion format did was to draw to audience into active participation and give them more of a stake in the presentation.  I think the end result was positive, and I hope to do this whenever possible.

What I’d like to change:

Time! The presentation went about 75 minutes (out of 60).  We had more questions than we had time for; and I didn’t even address the specifics of the Lodsys or Macrosolve issues.  I can’t say that I would recommend going longer, as that would tend to lose audience members, but I can definitely see doing part II of the presentation in the upcoming months.

The Apple Infrared remote: Perhaps I haven’t given enough presentations in this manner to see this coming; but I was on the audience side of the podium, and my laptop was facing towards the presenter’s side of the podium — in other words: away from me.  Fortunately, I was in a room full of Mac developers, and it was quickly identified that the IR remote really did need line of sight to the front of the laptop. All things considered, I’m delighted this was the worst technical problem we encountered.

What didn’t work:

The REAL issues: One of my goals is to teach developers how to recognize patentable IP in their daily work, and to give them a working knowledge of what to do about it.  I don’t know any simple answer to the former; and I foresee a dichotomy in addressing the latter: some IP filing will be routine (think of do-it-yourself wills and such) while other IP filing will require a patent attorney; knowing when to seek competent counsel is critical.  Given the time constraints, it is now patently obvious that addressing these topics in a short presentation was simply wishful thinking.  It has become clear that I will need to create some kind of IP workshop for developers, where we will look at examples of intellectual property filings and attempt to train developers’ instincts on what the standards of patentability are (in practice), so that they are in a better position to identify valuable IP in their daily work.

Closing thought:

I am anxious to schedule the next presentation.  It’s going to be a long and challenging journey, but I am convinced that this is what is necessary to protect the field of software development from economic parasites of the likes of Lodsys and Macrosolve.