Relational Database - Using Objects to Access A Relational Database (DataTern) - Issued Patent - PRIOR ART REQUEST

Question

DataTern has Patent No. 5,937,402 on using objects to access a relational database. The patent was issued in 1999, and obviously people were using objects to access databases since the 80's. Basically, any software written in the past 15 years that access a database is likely violating this patent. This is true for Microsoft technologies, Java, SAP, etc. Here is its claim 1:

1. A method for enabling an object oriented user application to access a relational database having one or more physical tables segmented into rows and columns, comprising:

• defining a logical table comprising a subset of columns from at least one of the one or more physical tables;
• designating one column of the logical table as a logical primary key column;
• forming a normalized relational schema object representing the logical table;
• generating, responsive to the normalized relational schema object, one or more object classes associated with the normalized relational schema object; and
• employing an object of an object class including the one or more object classes associated with the normalized relational schema object and a respective corresponding logical primary key value to access data in the at least one of the physical tables in the relational database.

I am looking for prior art that shows programmers used objects to access databases long before 1999.

Answer 1

These claims read like the feature list of the Enterprise Objects Framework introduced by Next in 1994, as part of their software development platform written in Objective-C. It was also part of their WebObjects web development platform, introduced in 1996. In 1999 they released a Java version of WebObjects, including EOF translated to Java. Here is an EOF manual published in 1998.

Answer 2

The (then) Borland (today: Embarcadero) Delphi programming language & RAD development environment has been accessing databases with objects since at least 1995.

Delphi is both the name of an the "Object Pascal" programming language and a RAD Object Oriented Integrated Development Environment, which since it's first version provided objects for interacting with tables, queries and or views in a relational databases.

The original 1995 version Delphi 1.0 client/server based objects (TTable, TQuery, TDataset, TDatabase, TSession) serves as sufficient prior art to for the claims in question, however the "Midas" (now "Datasnap") multi-tier technology that was released around 1997 with the advent of Delphi 3.0 provides additional prior art should there be quibbles with the former.

In particular, I submit the following comments in response to the claims above:

1. A method for enabling an object oriented user application to access a relational database having one or more physical tables segmented into rows and columns, comprising:

Generally Delphi's database components since version 1.0 has had this exact goal, of allowing an object oriented user application to access a relational database. In particular, the TTable (1 physical table or view) or TQuery (1 or more tables or views) are therefore 2 concrete classes providing access to an underlying relational database and therefore direct prior art.

defining a logical table comprising a subset of columns from at least one of the one or more physical tables;

Both TQuery and TTable instances define logical tables for use in a Delphi application and so serve as prior art here as well.

designating one column of the logical table as a logical primary key column;

First note that in general, keys need not be single column, so the claim here is oddly limiting for something that is supposed to be for general use and expanding the state of the art.

Nonetheless, Delphi supports several ways of defining both single and multi-part keys for its data access objects that serves as direct prior art here.

Concrete examples:

1) TField objects (which are contained in TQuery/TTable etc) support (at least) the TField.ProviderFlags property (e.g. property "pfInKey") which allows one to specify that a particular TField is a key field for the containing logical table object.

2) TTable components (amongst others) can additionally store both field and index definitions which imply whether a field is part of a logical primary key or not: TTable.IndexDefs for example contains a list of index definitions, each index definition has several properties, including the list of fields making up the index, and properties to specify various aspects of the index, including whether it defines a primary key (Index.Options include enumerated value ixPrimary)

3) Midas TClientDataset similarly is a completely logical dataset class that allows a user to define field, field properties (including key specification) as well as having an IndexDefs property that can define logical indexes and primary key, and which can be used to access data from a back-end relational database.

forming a normalized relational schema object representing the logical table;

The term "relational schema" usually refers to a database schema, which usually includes multiple tables (or relations), so this statement referring to a singular "logical table" whilst simultaneously referring to a "normalized relational schema" seems on it's face confused and at best poorly worded.

Maybe the author meant "relation schema", where "relation" is a formal name for what we would otherwise call a table, and the "relation schema" is then informally the description of the structure of the table (rows, columns) and so on.

Either way, as mentioned before, any of the many TDataset descendant object included in Delphi, and in particular TTable, TQuery and TClientDataset serves as prior art as objects representing a logical table (relation) in a Delphi application.

For more on this apparent confusion of terminology, see: http://en.wikipedia.org/wiki/Relational_schema http://en.wikipedia.org/wiki/Database_schema http://en.wikipedia.org/wiki/Relation_schema

generating, responsive to the normalized relational schema object, one or more object classes associated with the normalized relational schema object;

Part of the work done by the Delphi environment is to generate instances of TQuery, TTable, TClientDataset and so on, and to populate these objects with the attendant field definitions, index definitions, keys and so on, or to allow the developer to specify these manually by hand if so desired.

These objects form part of a so called datamodule object, which itself is an instance of the TDatamodule class. Delphi allows one to define relationships between various "TDataset" objects (TDataset being the ancestor of several of the classes previously mentioned and so being a collective term for any Delphi application "logical table"), thereby establishing relationships between the logical objects and thus effectively a relational schema.

The TDatamodule then is prior art for the "relational schema object", and whether it is normalized or not depends on the developer and how he/she designs the logical tables in question, but suffice it to say that a normalized form is supported if desired.

and employing an object of an object class including the one or more object classes associated with the normalized relational schema object and a respective corresponding logical primary key value to access data in the at least one of the physical tables in the relational database.

As a concrete prior art example: A TClientdataset class instance named "cdsCustomer", housed with other TClientDatasets (say "cdsOrder" with a master-detail relationship with cdsCustomer) in a TDatamodule instance, with a suitably defined primary key field & index on the "CustomerId" logical field (together with suitable supporting Midas backend) will allow the Delphi application containing this clientdataset to retrieve data in a back-end relational database table called say "tblCustomers", locate a specific CustomerID in the logical table, modify values in the logical table (without at that point having any link with the back-end) and eventually sync the update back to the database.

In summary, this claim describes nothing more than what Delphi's object access classes have already been providing since at least 1995.

Delphi release dates:

http://delphi.wikia.com/wiki/Delphi_Release_Dates

Delphi Developers guide (c) 1995 Borland:

http://portal.aauj.edu/portal_resources/downloads/database/delphi_database_application_developers_book.pdf

Answer 3

Sun Microsystems:

Provisional U.S. Patent Application No. 60/068,415, entitled “System and Method for Mapping Between Objects and Databases,” filed on Dec. 22, 1997

https://www.google.com/patents/US6360223

EDIT: Too late. US5937402A filed Jun 19, 1997. This is not prior art.

Answer 4

Informatica has used objects to store its mappings and sessions in DB since late 1990's. I joined it in 1999 and it was a well-established company by then (went public in April 1999). I believe I've heard of a patent being awarded to Informatica for that very thing: storing objects in RDBMS.

Answer 5

When did ADA and smalltalk get the ability to access databases? Both languages predate the patent by more than a decade, and I'm sure accessed databases before then.

• Embedded SQL for Ada 95

• ODBC bindings for ADA 95 - Low-cost Development Systems

Answer 6

You may want to try US 6,457,007. Published as JPH0798669 (A) ― 1995-04-11. There are two related JP applications - just need to translate them. If you think there is something missing, you may want to look at related filings by the inventors.

"When the table location extraction unit 33 in this Embodiment 13 receives a table access statement 255 or 256 in which the physical database name holding the table 100 to be accessed is directly designated, the extraction unit deletes the designation of the physical database name from the table access statement 255 or 256 held in the statement buffer 6, creates a statement 257 or 258, and informs the table location inquiry unit 36 of the physical database 1 (DB_a or DB_b) which is designated in the statement 255 or 256 as an access object."

Abstract:

A distributed database management system includes a communication network, at least a terminal device including an application program execution unit connected to the communication network, a plurality of information processors connected to the communication network, a plurality of physical databases installed in at least one of the information processors, at least a logical database grouping a plurality of the, physical databases, the logical database being defined by logical database information stored in at least one of the terminal device and the plurality of information processors, at least a table stored in at least one of the physical databases, and a table location searching unit installed in at least one of the terminal device and the plurality of information processors, for searching a table stored in at least one of the physical databases based on the logical database information, the table being requested to access on a logical database, from the application program execution unit.

Answer 7

The foremost example would be Toplink for Smalltalk and Java, now owned by Oracle.

See:

• http://books.google.com/books?id=ko5KTfIHjasC&lpg=PA6&ots=nya4WfXH0A&dq=smalltalk%20orm&pg=PA6#v=onepage&q=smalltalk%20orm&f=false
• http://www.oracle.com/technetwork/topics/history-of-toplink-101111.html
• http://en.wikipedia.org/wiki/TopLink

Answer 8

I'd have a look at what PowerBuilder was able to do during that timeframe.
My memory about what features PB had back then is vague enough that I don't know how much of this patent it covers, but I suspect there would be a fair bit.

Answer 9

I'd also like to point out Dogpile and Copernic regarding this.

DogPile is a meta search engine I used back in the 90's as a way to get results from multiple search engines, searching a database of search engines to show results the other search engines in which, in turn, relayed results from their databases to match the keyword queries. Copernic was/is a desktop search engine service, essentially using your computers HDD and indexing it in a searchable database on your HDD that can be used to quickly and easily find files on your computer system.

Answer 10

Reading the claims closer, I now believe that the POSTGRES prior art doesn't apply. The patent appears to relate to an object-oriented software system accessing a database, not using object-oriented methodology within the database itself.

So for prior art, we're looking for object-relational mapping (ORM) systems. The ActiveRecord part of Rails is an example of this, but it's not old enough for prior art.

Answer 11

Here's a link to a paper written in 1993 about Open Database Connectivity (ODBC) which was the defacto standard for accessing databases within Object-Oriented code.

http://www.openlinksw.com/info/docs/odbcwhp/mtarc/#The%20Generic%20ODBC%20Driver

You can clearly see numerous references to objects accessing databases.

Answer 12

The relevant prior art would be in having keys made of multiple fields and using an object which contained "stuff" that was then mapped to those multiple fields via the "normalized schema".

I was doing this sort of things with Informix (I think that's the correct RDBMS) in the late 80's.

However, that's not what this patent teaches. What's being taught is a way to generate OBJECT CLASSES from the normalized schema, the perform the query.

This is a very narrow (IMHO) patent and probably not the least bit related to what most people think it is related to. Especially since I have source code lying around on disk from '86-'87 time frame which did what people seem to think this patent covers.

Answer 13

The patent requires a novel improvement on prior art, and I must say that while working on Ingres in the 70's, the "improved" capabilities on an RDBMS specified in the claims do not qualify as "novel". This says to me that if you combind "object oriented" programming techniques (80's technology) with a relational database management system (70's technology), then you have something new in 2013. Not in my world.

Answer 14

Toplink is a very good answer.

I wrote an object/relational mapper for Java in 1996, and sold it to an early application server vendor, Novera. That product was shipped through 2000. The company was bought by Mercator, Inc., (nee Turnkey Systems, Inc.), which I believe was then bought by IBM. I could dig up documentation if that would help.

Another one that blows away this patent is Persistence Software: http://en.wikipedia.org/wiki/Persistence_Software. In fact, I remember being temporarily spooked by one of their patents on the topic.

Answer 15

A Commercial Object Oriented Database available before 1999.

A summery can be found here:

https://burks.bton.ac.uk/burks/pcinfo/progdocs/oofaq/s8d03.htm

We had the manuals lying around a couple of years ago. Probably still have in storage.

Answer 16

Also the Perl DBI-Modules (first released on Oct 12 1994 according to http://search.cpan.org/dist/DBI/Changes#ANCIENT_HISTORY ) are an example of an object-relational access mechanism that predates that patent by five years.

Answer 17

Texas Instruments (Jun 29, 1993)

"O-R gateway: a system for connecting object-oriented application programs and relational databases"

The TI patent specifies SQL mapping of objects to RDBS. us5937402 makes an emphasis on "rules", but that just seems to me more generic. You could define these "rules" in SQL or any other arbitrary language.

In the TI patent, all the Object to Relational code goes through explicit compilation phases, and in us5937402 this is not expressed, perhaps not required by these "rules", but this seems to me to be just a logical iteration of the TI concept.

Answer 18

Steve Jobs internal demo of NeXTSTEP 3 (from 1992) demonstrating -- among other things -- writing an object oriented application interacting with a database.

Database specific part is around 25 minutes in.

https://www.youtube.com/watch?v=gveTy4EmNyk

Answer 19

Clipper 5.x (1990 through and Clipper VO (Dec 1995) were object-oriented RDBMS languages. While the "OO-ness" of Clipper 5.0 is debated, that of Clipper VO is not. That said, the concepts introduced by Clipper 5.0 may qualify as prior art. http://www.thocp.net/software/languages/clipper.htm

Another relevant branch is Ingres-Postgres-Illustra. Illustra (both a company and product name) was formed in 1991-92 and will be able to demonstrate prior art at least that far back. http://www.knowledgerush.com/kr/encyclopedia/PostgreSQL/ http://archive.computerhistory.org/resources/text/Informix/informix.illustra_information_asset_management.102653331.pdf

Cheers,

Eli.

Answer 20

Persistence software: bridging object-oriented programming and relational databases

"Building object oriented applications which access relational data introduces a number of technical issues for developers who are making the transition to C++. We describe these issues and discuss how we have addressed them in Persistence, an application development tool that uses an automatic code generator to merge C++ applications with relational data. We use client-side caching to provide the application program with efficient access to the data."

Published in: · Proceeding SIGMOD '93 Proceedings of the 1993 ACM SIGMOD international conference on Management of data Pages 523-528 ACM New York, NY, USA ©1993 ISBN:0-89791-592-5 doi>10.1145/170035.171541

· Newsletter ACM SIGMOD Record Volume 22 Issue 2, June 1, 1993 Pages 523-528 ACM New York, NY, USA

ftp://db.stanford.edu/pub/public_html/keller/1993/sigmod-93-persistence-demo.pdf

Answer 21

Actor from the Whitewater Resource Group was an OO language that provided classes for accessing database content.

This http://books.google.com/books?id=LjwEAAAAMBAJ&pg=PT86#v=onepage&q&f=false, InfoWorld article dating back to October 1990 describes the features of version 3 of Actor, including a mention of ISAM type of data access. Note, everything in Actor was an object/class.

Also here is a paper from Naval Post Graduate School from June 1988 that Prototyping Visual Database Interface by Object-Oriented Language. The prototype described in the paper used the Actor language as well.

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=12&ved=0CC8QFjABOAo&url=http%3A%2F%2Fwww.dtic.mil%2Fdtic%2Ftr%2Ffulltext%2Fu2%2Fa200820.pdf&ei=CODuUeTwIoLjiAKynoGwDA&usg=AFQjCNHvoSlIEGFkoIQ-hWME_i0layd5Dg&sig2=xFctPC6xB-kGHtLHtV7Tog&bvm=bv.49641647,d.cGE

Answer 22

A paper published in 1993 describes this process: http://dl.acm.org/citation.cfm?id=171541&dl=ACM&coll=DL&CFID=349550071&CFTOKEN=88660538

(PDF of paper available at: http://pdf.aminer.org/000/599/026/persistence_software_bridging_object_oriented_programming_and_relational_databases.pdf)

Sample C++ code is included in the paper:

void demonstratePersistenceMethods()
{
    // Login to the database
    ROMS::connect(“scott”,”tiger”);
    // Create new persistent department
    Department * currDept = new Department("Sales","Building 1");

    // Create new employee, assign to department
    Employee * emp = new Employee("Jensen", currDept);

    // Read department with key = "Systems"
    Department * existingDept = Department::queryKey("Systems");

    // Read all employees who work in Systems dept
    Employee_Cltn * systemsEmpSet = existingDept->getEmployees();

    // Update employee relationship (also maintains ref integrity)
    emp->setWorksIn(existingDept);

    // Delete Sales dept from database (also checks delete constraints)
    currDept->remove();
}

This patent also appears very close to a patent filed Mar 22nd 1995 (5499371 - Method and apparatus for automatic generation of object oriented code for mapping relational data to objects)

Finally, a paper published in Communications of the ACM in April 1988 describes mapping from an OO heirarchy to relational databases to objects in detail (although mostly a manual process for determining the structure to tables should take):

http://sims.monash.edu.au/subjects/ims2501/seminars/oomodelling.pdf

Answer 23

Back in 1996 when I was taking college courses we used SmallTalk (IBM?) and PowerBuilder for some of the coursework. These were both highly object oriented and used objects to represent databases, tables and queries.

From documentation in 2000, but this is with version 5.5 and as I recall we used something very similar in 1996.

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS200-275

VisualAge Smalltalk Advanced Database Feature Version 5.5: This feature is a thin Smalltalk layer on the most commonly used native UDB capabilities that allow you to enhance DB2 applications for speed. For applications that must perform complex database access with a time delimited window, the Advanced Database Feature provides, in some cases, up to two times the speed of standard VisualAge Smalltalk CLI drivers for key operations.

Answer 24

The Clipper third-party community had a product called Object DB

CA-Clipper class library. (Princeton MICRAN introduces ObjectDB 1.1) (Brief Article) (Product Announcement) Data Based Advisor | June 01, 1994 | Copyright ObjectDB 1.1 is an upgrade that includes autoincrement fields, triggers, virtual columns, domains, and more. Features extended support for handling non-object DB files. Can pull in and manipulate tables on-the-fly. Supports declarative referential integrity, network-independent multi-user transaction processing, crash recoverability, automatic concurrency control, and multi-context table access. Price is $199.

Answer 25

I am not a database person nor have I used many, however I have been aware of them for a long time. The following might include prior art:

software was released in 1976:

http://en.wikipedia.org/wiki/Multics_Relational_Data_Store http://web.mit.edu/multics-history/source/Multics/doc/info_segments/mrds.info

Additional reverences can be found by google for multics mrds

Answer 26

There is also some scientific work published long before 1999, directly dealing with OO access to relational databases:

• Ramanathan, Providing Object-Oriented Access to a Relational Database, 1994 [PDF]
• Sutherland et al., The Hybrid Object-Relational Architecture (Hora), 1993, ACM [PDF]

Answer 27

Microsoft had a core library in the mid-90's built on com objects intended to access databases through ODBC or other means. Here's an example:

http://iprodeveloper.com/development/using-vb-40s-dao-access-as400-data

Answer 28

See:

Fundamentals of database systems (2nd ed.) Authors: Ramez Elmasri Univ. of Texas, Arlington Shamkant B. Navathe Georgia Institute of Technology, Atlanta Publication: · Book
Fundamentals of database systems (2nd ed.) Benjamin-Cummings Publishing Co., Inc. Redwood City, CA, USA ©1994 ISBN:0-8053-1748-1

Chapter 22, Page 688 shows a sample object oriented class accessing its data from a relational database. Published 1994.