Explanation of the Abstract

Taken out of context, the abstract of Patent 6,272,672 is hard to read. But every sentence has its own purpose, and taken together the sentences tell a big story. Here is the abstract, sentence by sentence; following that is some of the story that each sentence tells.

★Interactive event-driven programs are structured and executed using two types of constructs: interconnectable processing components and flow objects with associated data.
★Components are interconnected in a hierarchical dataflow network, and references which provide access to flow objects flow on the interconnections.
★Response to events and bidirectional coordination over multicomponent data paths, even in a distributed object system, employ unidirectional dataflows and intercomponent message sequences mediated by flow objects.
★Scaling and abstraction of complexity are facilitated by encapsulation of constructed networks into new component definitions.
★An interactive debugger preserves state as an executing program is edited, permitting an event-driven program to be modified in the intervals between processing of events without reinitialization.
★A component protection method employs multiple levels of usage authorization within components, enabling developers to define and distribute new protected components in a decentralized component market.

★Interactive event-driven programs are structured and executed using two types of constructs: interconnectable processing components and flow objects with associated data.

This invention reconceptualizes the entire class of applications with interactive graphical user interfaces. This class includes programs that run in Web browsers, smart phones, airline ticket kiosks, and new devices such as iPad.

The patent describes a new way of thinking about, and building, these applications in a way that is essentially different from the way they are conceived of, built, and execute today.

In the new conception programs consist of two different kinds of things: interconnected dataflow components and flow objects. Flow objects contain application data that flow along the component connections from database to user interface.

Plumbing or wiring are workable metaphors for these programs. The value of the invention is that plumbing/wiring is more than a useful metaphor; this the way the programs are actually structured and the way they execute.

★Components are interconnected in a hierarchical dataflow network, and references which provide access to flow objects flow on the interconnections.

Representing applications as dataflow networks is not new. Such representations were widely used in the era of batch file processing, particularly with punched cards and magnetic tapes. In the batch-processing era there was no academic computer science, and many people with a high-school-level education were quite good at conceiving and designing complex information processes as dataflow networks, that is, as sequences of file processing operations. But these were batch (i.e., noninteractive) applications, and the techniques in existence then could not be straightforwardly extended to describe today's interactive transaction-oriented applications.

This invention brings the dataflow network model of information processing into the domain of event-driven interactive programs without loss of the model's earlier virtues: understandability, concreteness, and amenability to graphical representation. The invention applies the dataflow conceptual model to the world of interactive programs in a way that is both understandable and makes engineering sense.

★Response to events and bidirectional coordination over multicomponent data paths, even in a distributed object system, employ unidirectional dataflows and intercomponent message sequences mediated by flow objects.

The engineering problems that blocked the practical application of the earlier file-oriented dataflow conceptual model to interactive processes usually boiled down to two questions.

1.How do you handle the response to a user event that originates at the user interface (for example, a mouse click on a button)?
2.How do you handle the response to a data change that occurs (no matter what the cause of the change) so that all user-interface views of the data are automatically updated?

Earlier attempts to represent interactive processes as dataflow networks incorporated variations on the following approaches.

1.The handling of an event at the user interface is treated as an "inward" flow (away from the user toward the database) of control information from the user interface to the site where the processing must occur in response to the event. This “inward” flow of control information is to be distinguished from the "outward" flow of data information, which proceeds from the source of the data to the user interface. In other words, flows proceed in both directions across paths in the network.
2.When a data item changes, its new value is propagated throughout the network along all possible paths leading from the source of data out to the user interface.

These approaches, while they might be possible in principle, are impractical from an engineering perspective because they can consume orders of magnitude too much processing. The invention takes a different and straightforward approach that makes engineering sense.

★Scaling and abstraction of complexity are facilitated by encapsulation of constructed networks into new component definitions.

It's easy to build toys and hard to build robust, industrial-strength tools. When a new construction paradigm is presented the first question that is usually asked is: "Yes, but does it scale?" A construction paradigm scales if its virtues do not deteriorate as its applications grow larger.

Scalability requires that, no matter how large the application, the designer can find a way to partition his design in such a way that he is not swamped by complexity. If he is using a graphical design tool, for example, the number of things he has to deal with on the screen at any time should vary little with the total size of the whole application. This requirement is met by the capacity of the construction paradigm to support abstraction. Abstraction is the ability to add to the repertoire of basic building blocks by reducing a whole structure to the definition of a new, single building block. Furthermore, this new building block must be usable according to the same set of construction rules no matter how great is the complexity that is hiding in its interior. A corollary of this requirement is that it must be possible to build abstractions out of other abstractions, i.e., to many levels of depth.

Dataflow components support abstraction in the patent. That is, a network can be built out of components and these networks can then be defined to be a new component type. This new type can be put into a library and used in other networks.

There are earlier object-oriented construction paradigms that have graphical representations, in which networks are also built out of boxes and lines. These object-oriented networks (as distinguished from the dataflow networks of the patent) have two kinds of flow paths, those which carry objects and those which carry messages. In the paradigm of the patent there is only one kind of flow path. This difference between one kind of flow path and two kinds of flow path turns out to be the difference between being able to support multi-level abstraction and not.

★An interactive debugger preserves state as an executing program is edited, permitting an event-driven program to be modified in the intervals between processing of events without reinitialization.

So far we have discussed the construction paradigm without any regard for whether it is practically realizable in tools. It is; the patent describes an application or component construction tool (they are the same; an application is a special case of a component) that looks like a wiring or plumbing CAD tool. Many of the figures in the patent are screen shots taken from an early prototype of this tool.

The representation of a dataflow application in the construction tool is a visual network in which, except in the brief moments when processing of an event is occurring, nothing is happening. This static, visible nature of applications in the construction paradigm is an important part of what makes them understandable to many more people than can understand software programming.

This sentence of the abstract has an important consequence: the distinction in conventional programming between "build time" and "run time" does not hold. The building and the running of the program are going on simultaneously; one sees the user interface of the tool alongside the user interface of the running program. That makes this construction tool more like the tools we are used to when we work with concrete objects: we get immediate feedback about the changes we make to our working material. We take such a property of manual tools for granted; suffice it to say that this property almost never holds for software construction tools. The difference is the reconceptualization of applications afforded by the dataflow model.

★A component protection method employs multiple levels of usage authorization within components, enabling developers to define and distribute new protected components in a decentralized component market.

The decoupling, for both components and flow objects, inherent in the construction paradigm suggests that components can be built for reuse. A marketplace of reusable components has been the holy grail of software for years but has been achieved only partially. The patent brings this ideal closer to realization.

In order to have a true market in reusable components, either all components are "open source" or else there must be a fine-grained way for component developers to protect their intellectual property rights. The patent describes a means whereby multiple levels of usage permission can be assigned to components, with the user of a component receiving only that level of authorization for which he has paid. Furthermore, depending on the particular level of authorization, it should be possible, for example, to build a composite component employing a licensed component without being able to find out what is inside the latter component. The patent describes a technology in which the construction tool interacts with the authorization information in each component to enforce the rights of every component supplier, no matter how deeply that supplier's component is buried inside a component network. The protection mechanism makes it possible for a component builder to use restrictively licensed components to build and license a new component while protecting the property rights of the suppliers of all interior components which the component builder might have licensed and used.

Contact the Inventor