Data processing: artificial intelligence – Knowledge processing system – Knowledge representation and reasoning technique
Reexamination Certificate
2001-06-21
2004-08-31
Knight, Anthony (Department: 2121)
Data processing: artificial intelligence
Knowledge processing system
Knowledge representation and reasoning technique
C706S046000, C706S061000
Reexamination Certificate
active
06785664
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to automated software systems for processing collections of computer files in arbitrary ways, thereby improving the productivity of software developers, web media developers, and other humans and computer systems that work with collections of computer files.
BACKGROUND OF THE INVENTION
The general problem addressed by this invention is the low productivity of human knowledge workers who use labor-intensive manual processes to work with collections of computer files. One promising solution strategy for this software productivity problem is to build automated systems to replace manual human effort.
Unfortunately, replacing arbitrary manual processes performed on arbitrary computer files with automated systems is a difficult thing to do. Many challenging subproblems must be solved before competent automated systems can be constructed. As a consequence, the general software productivity problem has not been solved yet, despite large industry investments of time and money over several decades.
The present invention provides one piece of the overall functionality required to implement automated systems for processing collections of computer files. In particular, the current invention has a practical application in the technological arts because it provides automated collection processing systems with a means for obtaining useful, context-sensitive knowledge about variant computational processes for processing collections.
Introduction to Process Knowledge
This discussion starts at the level of automated collection processing systems, to establish a context for the present invention. Then the discussion is narrowed down to the present invention, a Collection Knowledge System.
The main goal of automated collection processing systems is to process collections of computer files, by automatically generating and executing arbitrary sequences of computer commands that are applied to the collections.
One critical part of automated collection processing systems is automatically calculating a variant computational process to execute on the current collection. This calculation is quite difficult to carry out in practice, for many significant reasons. One reason is that the computation can be arbitrarily complex. Another reason is that many files can be involved in the computation. Another reason is that many different application programs can be involved in the computation. Another reason is that platform dependent processes can be involved in the computation. Another reason is that various site preferences and policies can be involved in the computation. And so on. The list of complicating factors is long. Generating and executing arbitrary computational processes is a complex endeavor even for humans, let alone for automated collection processing systems.
For communication convenience, this discussion is now narrowed down to focus on the general domain of software development, and in particular on the field of automated software build systems. This is a useful thing to do for several reasons. First, it will ground the discussion in a practical application in the technical arts. Second, it will bring to mind examples of appropriate complexity to readers who are skilled in the art. Third, it will provide several concrete problems that are solved by the present invention. Even though the discussion is narrowed here, readers should keep in mind that automated collection processing systems have a much wider application than only to the particular field of software build systems. The goal of automated collection processing systems is to automatically generate and execute arbitrary computational processes on arbitrary collections of computer files.
Software build processes are good examples for the present invention because they effectively illustrate many of the problem factors described above. That is, software build processes they can be large, complex, customized, platform dependent, and can involve many files and application programs. For example, large multi-platform system builds can easily involve tens of computing platforms, hundreds of different software programs on each platform, and tens of thousands of data files that participate in the build. The automatic calculation and execution of such large software build problems is a challenging task, regardless of whether manual or automated means are used.
One of the most difficult aspects of calculating and executing software builds is accommodating variance in the calculated processes. For example, typical industrial software environments often contain large amounts of process variance in tools, processes, policies, data, and in almost everything else involved in computational processes.
Process variance is difficult to handle even for human programmers, because variance usually requires simultaneous, peaceful, co-existence and co-execution of a plurality of variant instances of complex processes. Peaceful co-existence and co-execution are not easy to achieve within industrial software environments. For example, two variant processes might both use a large customer database that is impractical to duplicate. Or multiple working programs in an existing working process might be incompatible with a required new variant program. And so on. In typical cases, many interacting process issues must be resolved before variant processes of significant size can peacefully coexist in industrial software environments.
As a simple model of variant process complexity, consider a single long strand of colored beads on a string. Beads represent programs, data files, and process steps. Beads can have variant colors, shapes, and versions. Individual beads represent steps in a computational process, individual programs, particular input or output data files, or particular sets of control arguments to particular program beads. Finally, consider that software build problems of medium complexity are represented by several hundreds or thousands of beads on the string.
This bead model can now be used to illustrate how process variance affects complexity. To begin with, it is reasonable to say that most complex industrial software processes must be varied in some way to meet the needs of various computational situations. In the bead model, this is equivalent to saying that most beads on the string will need to be varied at some time, by color, by shape or by version, in order to create a new, particular variant process to meet a new, particular variant software development situation.
As one example, it is often the case that some original data files will be incompatible with a proposed new computing platform bead or a proposed new program bead, requiring that multiple data beads be changed whenever certain platform or program beads are changed. This example illustrates coupling among particular changes within a particular computational process. This example also illustrates the point that it is not always possible to make only one change in a process; in many situations, multiple bead changes must be coordinated in order to create a desired variant computational process.
As a second example of bead model complexity, large industrial software environments can easily contain tens of long product strings and new product version strings, each containing many hundreds or thousands of beads. Further, tens or hundreds of programmers can be continuously improving the various product strings by adding new feature beads, fixing software bug beads, modifying existing feature beads in some way, or cloning, splitting, or merging whole strings of beads. Since each string change must be tested, it follows that many variant combinations of data beads, feature beads, bug fix beads, and process beads must peacefully co-exist together in host industrial software environments for arbitrary periods of time.
Thus it can be seen that automated collection processing systems are not faced with only simple problems involving single complex computational processes. Instead, automated systems face a far more difficult, more general problem that invo
Holmes Michael B.
Knight Anthony
LandOfFree
Collection knowledge system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Collection knowledge system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Collection knowledge system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3287775