Re: UML diagrams for software patent drawings
« Reply #1 on: Nov 21st, 2005, 4:06pm »
I don't have experience with UML diagrams, but I'll offer a few thoughts.
The nice thing about flowcharts is that they can map nicely to a method claim. I think they also speak at a lower level of abstraction and that helps avoid vagueness issues. Software engineers sometimes anthropomorphize their software -- this module hopes to do this, it wants to do that, it likes receiving messages in this format but it can cope if it receives messages in that format, etc. I believe that such anthropomorphizing can lead to vagueness issues, and I'm not sure UML diagrams avoid those issues as much.
I have to admit that I believe UML diagrams came into vogue well after I left software design, so I'm at a disadvantage relative to current engineers. However, I'll go ahead and risk showing ignorance with these beliefs re UML diagrams.
I believe UML diagrams illustrate what a piece of software is, rather than what it does -- in class definitions, attributes, functions. In a way, I think that can provide good support for article/machine claims (something other than a method).
I believe UML diagrams illustrate only object-oriented implementations -- please correct me if I'm wrong. Making a claim based on such a diagram risks allowing for a procedural (not object-oriented) design around. In short, the higher level of abstraction might allow for non-infringing things that implement the same behavior -- assuming, of course, that the claim/s is/are too heavily influenced by the UML diagram.
I'd say that the best reason for using UML diagrams is that they most likely speak more clearly to one of ordinary skill in the art than do antiquated flowcharts. However, that doesn't mean that one of ordinary skill in the art can't read a flowchart. I believe flowcharts can still meet the requirements of law.
One question I can't answer is whether patent examiners in software groups currently understand UML diagrams. They may; I just don't know.