What?

Consider this Abstract from the patent:

A software design process includes three elements–an object/component driven element, a situation/scenario driven element, and an arbitrator/communicator element that is logically interposed and serves as an intermediary between the object/component driven and the situation/scenario driven elements. Through an iterative communication process overseen by the arbitrator/communicator, software design can take place and be measured against a metric. The communication process overseen and implemented by the arbitrator/communicator can allow ideas and developments provided by one element to be translated into a format that the other element understands. Once the metric has been achieved, the design process can be terminated.


This is, essentially, semiosis. Or the transmission of meaning. This is an attempt to patent the transmission of meaning.

But wait, there’s more. There’s woo:

For example, the left brain tends to look at parts, while the right brain tends to look at wholes. The left brain is logical, sequential, rational, analytical, and objective. The right brain, on the other hand, is random, intuitive and holistic. The right brain is good at synthesizing, being subjective and processing relationship information. … the left brain is responsible for number skills, written language, reasoning, spoken language and scientific thought. The right brain, on the other hand, is responsible for insight, 3-D formulation, art awareness, imagination and music awareness.

…Most individuals have a distinct preference for one of these styles of thinking. Some, however, are more whole-brained and equally adept at both modes. Left-brain scholastic subjects focus on logical thinking, analysis, and accuracy. Right-brained scholastic subjects, on the other hand, focus on aesthetics, feeling, and creativity.

… Consider now how the left and right brains map to the entities that are involved in the software design process. Specifically, software architects, designers and engineers tend to map to and are properly represented by the left side of the brain. Hence, … this side of the brain is associated with the object/component driven element described above. End users, vendors and customers tend to map to and are properly represented by the right side of the brain. Hence … this side of the brain is associated with the situation/scenario driven element described above. The communication function between the two sides of the brain maps to the arbitrator/communicator element described above.

… When one analogizes the software design process to the process of how the brain communicates, it has become apparent to the inventors that a method of communication, not unlike that of the corpus callosum (which effects the brain’s communication between hemispheres), is desirable in order to facilitate communication between two distinct viewpoints–that of the engineers/designers, and that of the end users/customers/vendors–in order to derive highly functional software components, such as platform components, that will enable high levels of innovation with minimal schedule and situational change risk.

The “Inventor” characterizes the process of software development as a left brain process designed to address right brain needs. The development and transmission of meaning between individuals, between the two halves of the brain, and between software engineers and software users (and by extension, perhaps, all engineers and all users, to include road designers and drivers, electronics designers and watchers of TV’s or listeners to iPods) will all be processes owned by the applicant for this patent.

A software design process has been described that includes three elements–an object/component driven element, a situation/scenario driven element, and an arbitrator/communicator element that is logically interposed and serves as an intermediary between the object/component driven and the situation/scenario driven elements. Through an iterative communication process overseen by the arbitrator/communicator, software design can take place and be measured against a metric. The communication process overseen and implemented by the arbitrator/communicator can allow ideas and developments provided by one element to be translated into a format that the other element understands. Once the metric has been achieved, the design process can be terminated. This approach can provide advantages in the form of leveraging the knowledge of both the object/component driven and situation/scenario driven elements, while ensuring that any dilutive effects due to blurring of the roles as between the elements are mitigated.

…Although the invention has been described in language specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and steps are disclosed as preferred forms of implementing the claimed invention. *

In a sense, this is a patent of all patents. Microsoft. They want to own you. Open Source is not an option, it’s the only way out of this trap.

Comments

  1. #1 Christian
    June 9, 2008

    Weird. What specifically are they trying to get patented? The method with which all software is designed? Is there a source for this abstract? It would be very interesting to spend more time on this subject….

  2. #3 Robert Ward
    June 9, 2008

    Strange…don’t they have enough market share? Do they really need to expand into the brain, or mind?

  3. #4 Alan Kellogg
    June 9, 2008

    Trust Microsoft to turn patents into bloatware.

    Let’s try the other end of the complication spectrum. Your goal is to answer the following questions.

    What does the program do?

    How does it do it?

  4. #5 Gray Gaffer
    June 9, 2008

    Has the qualification for a patent award changed when I was not looking? Although what was quoted was the non-binding introduction, and it would be perhaps more pertinent to see the actual claims, my understanding-from-experience of patents is that processes can NOT be patented, only specific manifestations of implementing them. In particular, that a typical practitioner of the art patented can, from the patent and its citations alone, implement and demonstrate a working instance of that which is patented. In other words, the patent must “teach the art” that is patented in a practical way.

    Of course, this is M$, and that $ has significance in this domain.

  5. #6 Greg Laden
    June 10, 2008

    What is quoted is significantly more than the “intro” …

    I’m not sure about process vs. how to do a process, but I don’t think that this patent is intended to protect anything. I think this is an attempt to have a patent pending that can be used to scare others into giving up on trying to compete with microsoft. That may not be very logical, but when the suits show up in numbers, they can be very scary, I assume.

  6. #7 Gray Gaffer
    June 11, 2008

    You may be right. I remember encountering one person waaay back who had apparently by use of oblique language convinced the Patent Office to grant him a patent on using character buffers in front of UAR/T logic. In 1984. When the GIANT chip did exactly that in 1972. So M$ may even get their patent granted and be relying on their $ to protect them from challenge. Do you by any chance have a reference to the actual application? Seeing the claims might raise even more interesting points.

    The Abstract is an abbreviated form of the preliminary discussion that describes the domain, operating considerations, and other relevant Art including other patents that this one may extend or need to avoid. It precedes the actual claims of the invention. It is non-binding in that only the claims themselves form the patent, with Claim #1 being the most fundamental and the others building on it. The other stuff can be changed at pretty much any time, and is really considered primarily a teaching aid in the sense of “teaching the art”.

    My experience: I am named inventor on five software patents (so far). Patents rather than trade secrets because that is how the management thought. I myself am not so gung-ho on software patents; while I know such things were not even thinkable when the Patent Office was instituted, Patents were specifically intended to protect products, not ideas. A process is an idea. A mousetrap is a product. You can not patent the idea of catching mice with a device. You can only patent a specific device, e.g. how the trap is sprung, how the mouse is then contained. Anybody else is then free to invent their own mousetrap, as long as they use a different method for springing the trap and containing the mouse. And they can patent that too.

    Interestingly enough, the PO seems to use the syntactical form of the patent language to define what is patented, rather than its semantic content. It is possible, especially with software patents, to manipulate them simply by choice of words. I suspect this derives from their method of identifying potential infringements. In the UAR/T case I mentioned above, we enjuneers are typically naive enough to think that something we did is so obvious an extension of the art that it is not patentable, and so don’t patent it. Then along comes some joker like that who takes advantage of the fact that no patents exist and uses language to point the PO away from existing art (which voids the “novel” part of patentability). Sometimes these tricks even work to the extent of sustaining challenge: back in the 80′s somebody – I forget who – patented the use of a blank front panel on rack-mounted outboard audio processing gear. Along came we, putting networked computers behind our front panels and moving all the UI to the PC. To avoid infringement challenge we had to put a reset button on the front. We were not alone. Their advantage? manufacturing cost. Ours? a UI that was actually usable. Different focus, I guess.