Newsgroups: comp.speech
Path: pavo.csi.cam.ac.uk!pipex!uunet!hela.iti.org!smp
From: smp@iti.org (Stanley M. Przybylinski)
Subject: Submissions to the SPI "folklore" database
Message-ID: <1993Mar16.204259.15412@iti.org>
Organization: Industrial Technology Institute
Date: Tue, 16 Mar 1993 20:42:59 GMT
Lines: 585


To:      Members of the Software Community
  
From:    Bernard A. Galler, Chairman
  
Subject: Submissions to the SPI "folklore" database
  
The Software Patent Institute is now operating, and we are asking the
software community to help us build our "folklore" database by sharing with
everyone the concepts and techniques which they find so familiar, but which
the US Patent and Trademark Office generally cannot identify as prior art,
since they lack any specific reference to the technique in question.  We
must help the USPTO do its job better, so that patents are not granted for
techniques that have already been invented but were lost in the "folklore"
prior to the creation of our SPI folklore database. This folklore exists in
old offline journals, user manuals, conference proceedings, course handouts,
and other materials not yet readily searchable by the USPTO.  Please note
that the SPI is "rigorously" neutral on the desirablity of software-related
patents. we believe the existence of this database will help, regardless of
one's position regarding software- related patents.
 
Please search your files and previous publications, and let us have
your contributions to this important activity.  And share this message
with your colleagues.  As you will see, I have begun this exercise using
my own files, and it is actually an interesting and enjoyable experience.

Please try it soon!
  
Sincerely,
 
Bernard A. Galler


:o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-:
:....................................................:
:....................................................:
:.....0100100100......0100100100100....010010010010..:
:...0100100100100.....01001001001000...010010010010..:
:..010................010.........010.......010......:
:.010.................010..........010......010......:
:.010.................010..........010......010......:
:.010.................010..........010......010......:
:..010................010.........010.......010......:
:...01001001000.......01001001001000........010......:
:.....01001001000.....010010010010..........010......:
:..............010....010...................010......:
:...............010...010...................010......:
:...............010...010...................010......:
:...............010...010...................010......:
:..............010....010...................010......:
:...0100100100100.....010..............010010010010..:
:....0100100100.......010..............010010010010..:
:....................................................:
:....................................................:
:o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-:

SOFTWARE PATENT INSTITUTE

SUBMISSION PACKAGE

MARCH 15, 1993

INTRODUCTION

This document represents the latest version of SPI's submission
package to be given wide circulation. SPI is:

1.   Posting this document on the Internet and other electronic fora;

2.   Sending this document  to the SPI mailing list and to other groups;

This submission package includes the following:

	(a) material on SPI and its mission;

	(b) an exhortation to contribute;

	(c) material on the database and how to access it; 

	(d) a template (with instructions) for making a submission; 

	(e) examples to illustrate; and

	(f) the license SPI needs to receive.

Please send submissions or comments to Internet: spi@iti.org or to
Software Patent Institute, 2901 Hubbard, PO Box 1485, Ann Arbor, MI 48106-1485.

THE MISSION OF THE SOFTWARE PATENT INSTITUTE

The Software Patent Institute (SPI) is a nonprofit
institution dedicated to providing information
to the public and to assisting the USPTO and others by
providing technical support in the form of educational and
training programs and providing access to information and
retrieval resources. The primary goal of the SPI is to
provide the best available information as to prior art in
the software field for utilization by the public and the US
Patent and Trademark Office (USPTO). In addition, the SPI
will provide an educational resource from which the USPTO and
the public may obtain an enhanced understanding of the
nature of software, of software engineering, and of the
history of the discipline and its relationship to the patent
process.

As such, SPI is asking people throughout the software
industry, government, and academia to contribute
descriptions of software techniques and processes to the
Software Patent database. (Note that SPI is NOT building a
collection of the techniques and processes themselves,
in source code, object code, or any other form.)
These descriptions form the content of the database and will
be made available for computer-aided searching to the USPTO,
the members of SPI, and the general public. SPI expects
USPTO and others involved in the patent process to search
for patent-related reasons. However, software developers,
historians, and computer scientists will undoubtedly find
the database useful for many of their purposes as well.

At the start, SPI is particularly interested in documenting
what industry, academia, and government have been doing.
Thus descriptions of techniques or processes that were first
described or used in the past are its first priority,
especially the "tricks" that "everybody knows" but most
people are unsure of how they know -- whether from a chapter
in a standard reference work, from a conference or course,
from some publication that is not available on-line, or
from some other source.

ACCESSING THE DATABASE

The database currently resides on a computer at the home of
the Software Patent Institute, the Industrial Technology
Institute of Ann Arbor, Michigan. During the development and
testing phase, access is limited to those helping to conduct
the tests (drawn primarily from the USPTO and the members of
SPI). SPI is hoping to have dial-up (and perhaps even
Internet) access by sometime in the middle of 1993.

Once linked, searchers will be able to use all the standard
techniques available in commercial-grade text-searching
software, including individual keywords, Boolean operations
among keywords, proximity searches and so forth, similar to
other text-based databases such as Westlaw, Lexis, Orbit,
and Dialog. Individual records will be available for on-line
examination and downloading, subject to standard charges,
which will be comparable to those of other text-based
databases.

Over time, SPI will "add value" to the database by adding
keywords and other search aids to those that come with each
original submission. In fact, SPI has developed a relational
database which will contain such added value and has been linked to
the free-text database containing the submissions
themselves. For now, the process starts with submissions to
the free-text database, and we are hoping you will agree to
help us in this way.

SUBMISSION GUIDELINES

Each record in the Software Patent Institute database consists 
of a free-form, textual description of a software technique or 
process and some additional, structured information. If you 
have the legal authority to give us something that is more 
complete but less structured than individual submissions, such 
as the complete text of conference or course proceedings, we 
are happy to accept such material if it can be provided in 
electronic form.

We have provided a template in this document that you are free to
copy and fill out if you find that it helpful as you prepare
electronic submissions.

SPI needs to receive the submission in electronic form (email or
a MSDOS or MacIntosh disk) and the license agreement in paper form.

STRUCTURED INFORMATION:

The structured information is as follows:

SUBMITTER:  the person or organization making the
submission. You may request that this information not be
assessible in the database, but SPI still needs to know for
legal requirements. Note that the submitter may or may not
be the creator of the technique discussed, but should be the
author of the description or otherwise have the legal
authority to transfer the description to SPI. Even in the
accessible cases, SPI will not publish more than the name
(either organization or individual or both), city, state,
zip code and country. However, it does need the contact
information -- postal address, telephone, fax, email address
-- in order to post items in the database.

TITLE: A reasonably short (under 20 words) but descriptive
label for the technique being described

DATE(S): SPI will automatically add the date received and
the date posted, but you undoubtedly have information about
when this technique was used, sold, or described in a
printed publication.  Please include what you know, in the
form of date1 (event that took place on that date); date2
(event that took place on that date); etc.  For instance:
2/13/76 (discussed in Programmers Journal article); 3/18/78
(used in XYZ compiler sold by ABC). Note that "sold" or
"used" dates do not have to be the date of first use; you
may not know that. If you give us the dates you do know
about, it will be helpful. Here are some you might give us
if you know them:

     Date created (conceived)
     Date reduced to practice
     Date submitted for publication
     Date on publication
     Date publication hit shelves
     Date presented at conference
     Date incorporated into commercial product
     Date product advertised (if before first sale)
     Date product hit shelves (first offer)
     Date product sold (first sale)
     Date you learned about the item (for those submitting
something created by others)
     Date you obtained the item (for something created by
others)

REFERENCE(S): If you are working from another document, the 
facts of publication (author, title, date, publisher, city, 
country, volume, etc.) would be most helpful. If you are not 
working from another document, you can leave this field blank.

KEYWORDS: Keywords are individual words or short phrases
separated by semicolons. Over time, SPI and its users will
add keywords to various records. It would help (but is not
required) if you would suggest some keywords yourself. We
are particularly interested in keywords that relate to the
free-form description but do not appear in it because such
keywords are synonyms for concepts in the description or are
a higher-level class to which the description belongs. If
you add keywords (either single words or short phrases less
than 6 words), please separate them by semicolons.

DESCRIPTION: SPI needs to receive one or more paragraphs of
ASCII text, or text in a form that SPI can convert to ASCII.
SPI can handle most standard personal computer word
processing formats for either Macintosh or MS-DOS computers.

SPI is interested in any software idea, procedure, process, 
system, method of operation, concept, principle, or discovery, 
regardless of the form in which it is described, explained, 
illustrated, or embodied in some work. Put another way, SPI is 
interested in an invention, a discovery, a process, art, or 
method, a new use of a known process, machine, manufacture, 
composition of matter, or material; or any new and useful 
improvement thereof. The item does not need to be "new" now; 
presumably it was new at the time it was first tried.

The purpose of the description is to let the reader know
enough about the process or technique being described to
allow a decision to be made as to whether to pursue the
topic to some source of further information.  Thus, the
description should contain (a) a statement of the problem
being solved, or the functionality being provided, in
general terms independent of any specific language or
hardware or software platform with which it may have been
implemented; and (b) a description of the algorithm or
sequence of steps which indicates how the problem would be
solved, or the functionality provided.  A diagram, such as a
simplified flow diagram, may be useful, but is not required.
Likewise, an example of the application of the process or
technique may be useful, but is not required.

A complete description need not exceed a few paragraphs, if
there is a more complete source available.  If this
description is all that is being provided, it may need to be
more complete.  If there is an explicit dependency on a
particular hardware or software platform, this should be
described in a separate paragraph.  If an implementation
exists, or existed at one time, that information should also
be provided, but in a separate paragraph.

Group Submissions:

If you are submitting a group of descriptions, such as 
proceedings of a course or conference, we will automatically 
apply the structured information to each separate item we post, 
unless you indicate the different information that should apply 
to particular items.

Examples:

We have included a few records from the database with fields
filled out so you can see actual examples of what we are
requesting.
************************************************************
************************************************************
SUBMITTER: Bernard A. Galler, Software Patent Institute,
2901 Hubbard, PO Box 1485, Ann Arbor, MI 48106-1485, voice:
313-769-4083; fax 313-769-4064; email Internet: spi@iti.org.

TITLE: The MAD Definition Facility

DATE(S): Formal publication date, August, 1969

REFERENCE(S): The MAD Definition Facility
CACM, Vol. 12, No. 8, 8/1969

KEYWORDS:(in addition to published ones); extendibility;
extensibility

DESCRIPTION:
(a)     A method is presented for extending a high-level
language by defining new operators, new data types, and new
definitions for pre-existing data types.  The definition
process identifies combinations of operators (new or pre
existing) and data types, and provides a sequence of pseudo
code for each new combination and for each combination to be
redefined.  For new operators, a precedence value is also
declared.
(b)     The method also provides a process for the
interpretation of the pseudo-code sequences which define
operator/data-type combinations.  Some pseudo-code
statements test state values as anticipated when the
resulting code will be run, and then modify the sequence in
which the pseudo-code is interpreted.  Other pseudo-code
statements map directly to object code to be generated (or
executed).  The use of such pseudo-code definitions is key
to the definition facility which is the central theme of
this capability.

An illustration of the (a) definition and (b) interpretation
of a pseudo-code sequence would be as follows:
(a)
[-------------------------------]
[ Specify new operator and its  ]
[ precedence, or new data-type. ]
[-------------------------------]
     v
     v
[---------------------------------------]
[ Determine possible operator/data-type ]
[ combinations to be encountered.       ]
[---------------------------------------]
     v
     v
[------------------------------]
[ For each combination provide ]
[ pseudo-code sequence.        ]
[------------------------------]
     v
     v
[--------------------------------------]
[ Store sequences in defining tables,  ]
[ replacing old sequences for the same ]
[ combination, if needed.              ]
[--------------------------------------]
     v
     v
(b)
[---------------------------------]
[ Given an occurrence of an       ]
[ operator/data-type combination  ]
[ in the source program.          ]
[---------------------------------]
          v
          v
[-------------------------------------------]
[ Select corresponding pseudo-code sequence ]
[-------------------------------------------]
          v
          v
[-----------------------]
[ Interpret pseudo-code ]
[ one line at a time    ]
[-----------------------]
     ^         v
     ^         v
     ^  [============================]     [---------------]
     ^  [ Is pseudo-code statement a ] No  [Generate actual]
     ^  [ test of a state value?     ]>>>>>[ object code.  ]
     ^  [============================]     [---------------]
     ^         v                                  v
     ^         v                                  v
     ^         v Yes          No  [========================]
     ^         v            v<<<<<[ Is this the last line? ]
     ^         v            v     [========================]
     ^         v            v                v
     ^    [--------------------------]       v Yes
     ^<<<<[ Select next line of      ]       v
          [ pseudo-code to interpret ]    [+++++]
          [--------------------------]    [ END ]
                                          [+++++]

***********************************************************
***********************************************************
SUBMITTER: Bernard A. Galler, Software Patent Institute,
2901 Hubbard, PO Box 1485, Ann Arbor, MI 48106-1485, voice:
313-769-4083; fax 313-769-4064; email Internet: spi@iti.org.

TITLE: An Algorithm for creating equivalence classes

DATE(S): Original disclosure:  ACM National Conference,
1963, Denver, Colorado

REFERENCE(S): "An Improved Equivalence Algorithm," by
Bernard A. Galler and Michael J. Fischer*, CACM, Vol. 7, No.
5, May, 1964, pp. 301-303. (*originally published in error
as Fisher)

KEYWORDS: Equivalence; tree structure; MAD; FORTRAN; high
level language; compiler

DESCRIPTION:
An efficient algorithm for determining equivalence classes,
given a sequence of equivalence declarations for subsets of
a set of objects.  Each equivalence class is structured as a
tree, with most objects in each tree linked directly to the
root node.  The trees are constructed, and possibly linked
to each other when appropriate, in a single pass over the
sequence of declarations, including a single pass over each
declaration.
Each object in each declaration is examined in turn.  If it
does not yet appear in an equivalence class, it is retained
as the root of a new tree consisting of a single node.  Then
if the object is part of an equivalence class already
identified, this new tree must be combined with the tree
already under construction.  If, on the other hand, it is
the first object in a new declaration, then this step is
unnecessary, since it is legitimately the root of a new
tree.
If the new object has been encountered previously, then we
are either adding to a previously constructed tree (if the
new object begins a new group), or we must again combine two
trees; e.g., the one currently under construction and the
one indicated by the earlier encounter.

******************************************************
******************************************************
SUBMITTER: Bernard A. Galler, Software Patent Institute,
2901 Hubbard, PO Box 1485, Ann Arbor, MI 48106-1485, voice:
313-769-4083; fax 313-769-4064; email Internet: spi@iti.org.

TITLE:  Efficient address assignment for equivalent arrays

DATE(S): Original disclosure:  ACM National Conference,
1963, Denver, Colorado

REFERENCE: "An Improved Equivalence Algorithm," by
Bernard A. Galler and Michael J. Fischer*, CACM, Vol. 7, No.
5, May, 1964, pp. 301-303. (*originally published in error
as Fisher)


KEYWORDS:  Equivalence; tree structure; MAD; FORTRAN; high
level language; compiler, address assignment, arrays

DESCRIPTION:  This is an adaptation of another entry --
An Algorithm for Creating Equivalence Classes.  We assume
the availability of the efficient algorithm for identifying
equivalence classes and their representation as trees.  That
algorithm is modified so that the objects are assumed to be
treated as one-dimensional arrays, possibly with a different
subscript in each occurrence in a declaration.  In the
single pass over the declarations (and the single pass of
the objects in each declaration), certain information is
retained at each node.  Once all of the equivalence class
trees have been constructed, a single pass is sufficient to
assign addresses to the arrays, in all cases satisfying the
equivalence relations implied in the declarations involving
array subscripts.

The information retained with each node is related to the
difference between the base address for that node's array
and that of its parent in the tree.  This information is
sufficient to allow (1) the updating of such information
when trees are linked, and (2) the address computation in
the final pass to assign addresses to all of the objects.

*********************************************************
*********************************************************

TEMPLATE FOR AN INDIVIDUAL SUBMISSION

SUBMITTER:
name:
organization:
street address:
city:
state:
zip code or country code:
voice phone:
fax:
email address (indicate service and address, eg. MCIMail 555-
5555)

TITLE:

DATE(S):
type of date (eg. formal publication):
actual date:

type of date:
actual date:

[repeat as needed]

REFERENCE(S):
author(s):
title:
collective work (journal, proceedings, if relevant):
work identification (volume, number, page numbers if
relevant):
publisher:
place of publication:
date of publication:

[repeat as needed]

KEYWORDS:

DESCRIPTION:

*****************************************************************
*****************************************************************

SOFTWARE PATENT INSTITUTE

SUBMISSION LICENSE

MARCH 15, 1993

Submission Title:                                                                                          

     I (we), the Submitter(s) identified below, grant to the 
Software Patent Institute ("SPI") the following non-exclusive, 
transferable, irrevocable, worldwide license to the identified 
above Submission to the SPI database (but not to any works 
referred to in the Submission).  I understand I will receive no 
compensation from SPI for this submission.

     SPI and its designees may publish, display and reproduce 
the Submission in electronic, print and other media including 
computerized retrieval systems such as databases, electronic 
mail and bulletin boards, facsimiles, and printed 
publications.  Because SPI may need to edit the Submission for 
such purposes as brevity, clarity, and database entry, SPI may 
adapt the Submission as it deems necessary including conversion 
to and from machine readable forms.

     I certify that I wrote this Submission, and/or that I have 
the right to grant SPI this license.  The Submission contains 
no trade secrets of mine, and I did not obtain its information 
as a trade secret.

Corporate Submitter                                                                                           
Signed:                                              Date:                 
Name:                                             
Title:                                            
Company:                                          
Address:                                          
                                                  
Individual Submitter(s)                                                                                       
Signed:                                              Date:                 
Name:                                             
Address:                                          
                                                  
                                                  
                                                  

Signed:                                              Date:                 
Name:                                             
Address:                                          
                                                  
                                                  
                                                  

Signed:                                              Date:                 
Name:                                             
Address:                                          



-- 

Stan Przybylinski, MTS - Technology Transfer and Commercialization
Industrial Technology Institute, P.O. Box 1485, Ann Arbor, MI 48106
(313) 769-4517   FAX: (313) 769-4064
