PAIR’s broken authentication scheme

It’s not new news that the USPTO’s private pair system utilizes a seriously fragile authentication scheme.  I get why they need something serious, but it’s time to replace the Entrust Java Applet.

I used to be able to get it to work on my Mac, but no longer.   When I couldn’t get it to work on Windows 7, with internet explorer, I had to call the EBC help center, which, thankfully, is open until midnight eastern time.   In order to get it working, I had to go to tools- (alt-t)-> compatability view settings, and add uspto.gov to the list of sites.   Even then, when successfully authenticating, it didn’t go to the PAIR page.  You had to somehow know that the authentication was successful, and open PAIR again by going to the menus… it just hangs on the successful authentication.

Come on guys, you’ve got money.   Let’s fix this thing and bring it into the new millennium.

—-

Just learned how to get it to work on Safari, thanks to this post.

Managing Extreme Ambiguity

Every organization must cope with ambiguity and uncertainty.  At a former employer, we used to interview candidates for the skill “tolerance of ambiguity”… because we had plenty of it.   Many management articles discuss ambiguity as something externally given to the organization to deal with.   For example,    Courtney,  Kirkland, and  Viguerie characterize four levels of uncertainty, ranging from “forecasting the future” with some certainty, all the way to situations where the range of outcomes can not be identified.  The term “forecasting” alone indicates that the ambiguity is about some external force or state.

In contrast, at MIT in 1993, Schrader,  Riggs, and Smith argued that uncertainty and ambiguity are different, and that they are chosen by how the problem solver frames the problem.

In the MIT model, they describe the decision process as having  a model to evaluate outcomes.   Uncertainty occurs when the model is understood, but information relating to the variables of the model is not understood.   Ambiguity is where the model is unknown, and in the worst case (level 2) the variables to input to the model are also unknown.   The matrix from their paper is here:

UncertaintyAmbiguity

The difference is important because to resolve uncertainty, we just need to go collect some data, then apply it to our model.   To resolve ambiguity, however,  we have to create a model, then get the data.  In the worst case we have to propose the variables to put into the model as well.  Ambiguity is significantly harder.

Some environments will have inherent and extreme ambiguity as a consequence of the leadership and organization in place; according to the MIT model, they have chosen the ambiguity.    My theory is that some organizations bias towards the chaos of ambiguity precisely because it defers decision making.  If you are trying to lead in such an organization without either power or authority (or both), the best you might be able to do is reduce ambiguity by making or forcing decisions that enable models to be formed.  Start with decisions that have relatively well understood consequences and little resistance, and use them as guideposts to build a fence around the problem.   Eventually you should have a smaller number of variables so that a model can be envisioned.

‘Comprising’ vs. “Consisting Essentially Of”

In going through the MPEP I ran into this jewel in 2111.03 Transitional Phrases:

For the purposes of searching for and applying prior art under 35 U.S.C. 102 and 103, absent a clear indication in the specification or claims of what the basic and novel characteristics actually are, “consisting essentially of” will be construed as equivalent to “comprising.”

Being equivalent to comprising helps a lot. I used to worry quite a bit over these transitional phrases when used in software patents. Although this doesn’t add clarity for “consisting of” without “essentially”, it is still very helpful. Why anyone would have used “consisting” for software is beyond me, but patents with such claims are out there.

Knowing-Doing Gap

In one of my leadership minute videos, I mentioned the knowing-doing gap. It was a concept I learned from a former boss, and I happened to see it in print today, referencing an article in HBR from 1999: The Smart Talk Trap by Jeffrey Pfeffer and Robert I. Sutton.

The article makes some great points, including that Leaders learn to talk well, but may never actually do things, mostly because they are rewarded for talking. Talking is given more weight than doing, and ironically, more pay. It mentions that people tend to see criticism as more intelligent than praise. That organizations are driven to complex plans because simple ones are presumed to not be viable.

In many organizations, sounding intelligent takes priority over doing, and that has the effect of uninspiring others. Eilieen Shapiro, in Fad Surfing in the Boardroom, called mission statements “a magic talisman, hung in public places, to ward off evil spirits.”. In other words, mere words can be uninspiring and may actually inhibit performance.

Their solution is multi-pronged, and is basic blocking and tackling.

  • Leaders who do the work, rather than just talk about it, help prevent the knowing-doing gap from opening in the first place.
  • Plain talk and simple concepts are marching orders.
  • Create informal rules governing discussion — focus not on faults but on overcoming them.
  • Close the Loop—following up to make sure something actually happens after it has been decided on—isn’t a very complicated idea. But it is a potent means for preventing talk from being the only thing that occurs.

Virtual and Remote teams

This post is also the subject of a Leadership Minute video.

In 1996, I was working for a subsidiary of Cray Research in San Diego which got acquired by Sun Microsystems. We knew that the company was Bay Area focused; if you weren’t in the Bay Area, you were a second class citizen. In early interactions it was very clear that neither group had the skills to collaborate remotely, so we decided we better get good at it, and we would have to drive the development of remote collaboration skills from San Diego, because the Bay Area contingent wasn’t going to care.
13836475024_f2993a19c3_b(hover over image for attribution)
We first made sure the audio equipment was good. We did have video conferencing, but decided for the most part that was a distraction, and was too expensive to put in every meeting room. If the audio quality is poor, you might be able to work through it, but it will be inefficient.

The most important thing after being technically able to hear each speaker in a room, was to change behaviors. When you are present in a room full of speakers, you can see who is speaking, and who is not speaking. You don’t have the luxury remotely. At the start of a remote meeting, someone has to make sure that each person present introduces themselves on all endpoints. That enables remote leaders to ask for input from others who have not spoken.

If a speaker has any doubt that someone may not know who is speaking, they should announce their name when starting a new dialogue. It may seem tedious, but it’s important to know who said what.

If a listener doesn’t know who is speaking, they need to ask. If listeners do this enough times, the proper speaker behavior eventually comes around naturally. In general, they will be a little embarrassed that they assumed the listeners knew who was speaking, so they’ll change to avoid that.

If any remote listener can’t hear, they need to ask the speaker to speak up. In an in-person meeting you might be able to augment the mumbler by reading lips and observing body language, but remotely, don’t let them get away with sloppy communication.

The reason this problem exists is that the ability to speak remotely is relatively new to humans if you look at it from an evolution standpoint. It’s why we think telepresence is so compelling. Until telepresence is the norm for remote communication, we have to use “new” skills. Because so much of our work is done remotely now, we better get good at it on a much larger scale.

The end of the Sun Microsystems story is that we became good enough at it that it enabled a company wide initiative to reduce the real estate expense. The objective was to put 1.5 people in each corporate-paid seat, by letting them work from anywhere.