associative patent

8/17/2019 Associative Patent

1/66

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIUS008051102B2

&12'nited States PatentEverett

(10) Patent No.: US 8,051,102B2(45) Date of Patent: Nov. 1,2011

(54) DATA BASEAND KNOWLEDGE OPERATINGSYSTEM

(75) Inventor: Ron Everett, Montreal (CA)

(73) Assignee: Levitronics, Inc., Montreal, Quebec(CA)

( * ) Notice: Subject to any disclaimer, the term ofthispatent is extended or adjusted under 35U.S.C.154(b)by 1974days.

(21) Appl. Noz 10/620,9SS

(22) Filed: Jul. 16,2003

WO

5,333,237 A5,333,310A5,448,722 A5,481,718A5,490,258 A5,555,409 A5,561,793 A5,592,666 A5,619,621 A5,649,190 A

7/1994 Stefanopoulos et al.7/1994 Sakai9/1995 Lynne et al.1/1996 Ryu et al.1/1996 Fenner9/1996 Leenstra, Sr, et al.

10/1996 Bennett et al.1/1997 Perez4/1997 Puckett7/1997 Sharif-Askary et al.

(Continued)

FOREIGN PATENT DOCUMENTS0129717 4/2001

(Continued)

OTHER PUBLICATIONS(65) Prior Publication Data

US 2004/0024790Al Feb. 5, 2004

Related U.S.Application Data

Tanenbaum A. S.,Memory Management, XP-002282085,Chapter 4,pp. 206-209.

(Continued)

(51) Int. Cl.G06F17/30 (2006.01)

(52) U.S.Cl. . 707/793; 707/803(58) Field of ClassiTication Search ..................07/103,

707/4, 10, 3; 395/613See application file for complete search history.

(56) References Cited

U.S.PATENT DOCUMENTS5,448,726 A4,591,983 A4,752,889 A4,816,994 A4,853,873 A4,868,763 A4,884,218 A4,893,232 A

9/19855/19866/19gg3/19898/19899/1989

11/19891/1990

Cramsie et al.Bennett et al.Rappaport et al.Freiling et al.Tsuji et al.Masui et al.Agnew et al.Shimaoka et al.

(60) Provisional application No. 60/398,843, filed on Jul.26, 2002, provisional application No. 60/457,207,filed on Mar. 25, 2003.

Primary Examiner John E BreeneAssistant Examiner Dennis Myint(74) Attorney, Agent, or Firm Dennis M. Carleton;George P. Baier; Fox Rothschild LLP

(57) ABSTRACT

70 Claims, 31Drawing Sheets

Associative Data Management and Knowledge OperatingSystem using a Data Instance centric architecture, where DataInstances are typically atomic. Each Data Instance can be atthe center with all its associations. The base structures encap-sulate the Data Instances and can generally be identical inform and function, and application independent. Encapsulatereferences can include references to all other directly relatedindependently encapsulated Data Instances. The encapsu-lated references can beboth unique identifiers for each andevery associated Data Instance and also logical indexes thatencode the abstracted location ofeach Data Instance, makingit possible to both identify and locate any Data Instance usingthe same reference key.

Named

~ettprie(((II&ianSTOCK PRICEPinto Beans $1L10Kidney Beans $9.85White Beans $13.45Wax Beans $18.72

Application =ependent

'Ro t i o n ' ow

Context

'~ta STOCK ~ZO PRICE+11 Pinto~ +21 $9+)+12 Kidney e~ +22 $11+j+13 White ~~+23 $13+1+14 Wax Be~~'+24 $13+j

(rory Context] (colContext]

An application-dependent 'primary'slotion

Symmetricol expressed as tno encapsulated,KnOS Context application-INDEPENDENT

/rnCrS Contexts.

Assimilating a 'Pritnar]r'elation


2/66

US 8,051,102B2Page 2

5,671,4065,701,4535,701,4675,713,0145,713,0315,726,8985,758,3335,799,1575,809,2975,812,8405,822,7805,873,0495,878,4085,905,9895,920,8675,974,1415,991,7586,002,7726,016,4976,029,1746,031,5376,037,9446,067,5526,073,1116,076,0776,088,6936,101,5006,112,2096,115,7166,134,5496,205,4476,212,5306,233,5866,236,9976,301,5816,317,7496,327,5946,330,5726,356,8976,363,3886,366,9226,385,604

6,400,9966,408,3216,424,9896,425,1196,434,5546,484,179

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABlBlBlBlBlBlBlBlBlBlBlBlBlBlBlBlBlBl

9/199712/199712/1997I/1998I/19983/19985/1998g/19989/19989/1998

10/19982/19993/19995/19997/1999

10/199911/199912/1999

I/20002/20002/20003/20005/20006/20006/20007/2000g/2000g/20009/2000

10/20003/20014/20015/20015/2001

10/200111/200112/200112/20013/20023/20024/20025/2002

6/20026/20027/20027/2002g/2002

11/2002

Lubbers et al.Maloney et al.FreestonDurflinger et al.SaitoJacobsBauer et al.EscallonKroenke et al.Shwartz ...............SchutzmanBielak et al..........Van Huben et al.BiggsVan Huben et al.SaitoEllardSaitoSuver ...................Sprenger et al.HughHughYuLeymann et al.SaitoVan Huben et al.LauGu sackTikkanen et al.Regnier et al.MalloyKadlecChang et al.Bodamer et al.SmileyChatateVan Huben et al.SitkaGu sackSprenger et al.AlthoffBakalash

Hoffberg et al.PlattShaw et al.Jones etal.Asami et al.Roccaforte

U.S.PATENT DOCUMENTS I/2003g/20033/2004

10/20056/20024/20036/2003

11/200312/20032/2005

Hasegawa et al.White et al.Aldridge etalSilberberg et al.....Berk .....................Eversole et al.Plourde et

al.........Walker et al..........HughAbineri et al.

6,513,038Bl6,609,132Bl *6,711,582 B2*6,957,214 B2*

2002/0069240 Al *2003/0076978 Al *2003/0110513 Al*2003/0216169 Al *2003/0227487 Al2005/0044079 Al *...707/102

.......707/4 FOREIGN PATENT DOCUMENTS0177904 10/2001

OTHER PUBLICATIONS702/6 WO

707/103 R707/103Y......707/4.. 709/203.. 382/100.. 725/134....463/25

707/10

707/103 R

TanenbaumA. S.,Memory Management, XP-002282086,Chapter 4,pp. 191-205.CCITT, Information Technology Open Systems InterconnectionStructure of Management Information; Management InformationModel, XP-002282087, Recommendation X.720, Jan. 1992, pp.1-27.Elementary Data Structures, XP-002268154,Chapter 11, pp. 200-218.

Graph Algorithms, XP-002269155,Chapter g, pp. 537-547.Chen, The Entity-Relationship Model Toward a Unified View ofData , ACM Transactions on Database Systems, vol. I, No. I, Mar.1976,pp. 1-36.E.F. Codd, Extending the Database Relational Model toCaptureMore Meaning , ACM Transactions onDatabase Systems, vol. 4,No.4, Dec. 1979,pp. 397-434.Lazy Software Ltd., The Associative Model ofData White Paper ,Copyright 2000 Lazy Software Ltd, pp. 1-15.Richard Hull, et al., Semantic Database Modeling: Survey, Appli-cations, and Research Issues , ACM Computing Survey, Applica-tions and Research Issues, vol. 19,No. 3. Sep. 1987,pp. 201-260.Lazy Software Ltd., Lazy View Database Aggregation CapabilityWhite Paper , Lazy Software Ltd., Copyright 2002, pp. 1-4.Codd, A Relational ModelofData for Large Shared Data Banks,IBMResearch Laboratory, vol. 13,No. 6, Jun. 1970,pp. 377-387.Senko, Diam H: The Binary Infological Leval and Its Database

Language FORAL , Mathematical Sciences Dept., p. 121-140.Baldissera, etal., Interactive Specification and Formal Verificationof User's Views in Data Base Design , 1979IEEEECh1406-g/79/0000-0262,pp. 262-272.

* cited by examiner


3/66

U.S.Patent Nov. 1,2011 Sheet 1of 31 US 8,051,102B2

QfLUC3CK0

I-0V)

Cf

0

CftQ

CG

lQ

0UJC3

CKCL

0+0

+~~0

Na0blCS+

II

8~ocax V)

AI

Ol

U)

V)g CI

0) (ga) ~co

hC

~V U+- c~V) c

~ cg 0

gaC

V)c0)

V)

Cf

0 cQ

CU

U~ cQ blcQ+-

Oc~+-v) Rzc00

e cK~OCJV tJ00& V)

Q & I-~ v) J-x NNLLI c6 cnQ

0

th)n CK

uNNLLI c6 A

% I-v) I-oo d

wc)numV~oo&tvi m aci

th) LA

CL ~

~ CQ 0

W LAM ~CL ~

CQtQ

O~~ I- g

Vl

Cf

&.cn@exa

cUbl

CQ

OCO

LA

AI

Q

000Ol

CX

Chc~Cf

C3


4/66

U.S.Patent Nov. 1,2011 Sheet 2 of 31 US 8,051,102B2

,, I. &kc +-0 CQ C g

CL Ol

hC ~~ o0 +-V) a

tnl/7

elh) 4cf~ cG

V)V

z~

4J 0 LA LA cUp()

P) CO

CV

NCO

hC OQ +CL

)CI

+-X

0 +O

N CUlS

8c

L

C0

8

cX 00

c~h ~

~ Q~O

O 4~Op0 4

.0

.a +0

'g c0C V)wO

c0+0Ol

L

~~CL

0CFIC0

~

~E~VlN

NCAc~0D


5/66


li jjI'fjil tijj[

C +-.0 C C»»» 0a& g.Oq) a

Q. CL»»»

~M

ill

en

+ill QIA

+X4»

CD

0

a

eOg0+

VV)

c0+aCX

00+++

ggg$

P.V0

CY N N 4 +ILJ cn cn u v)

I I I I I(()O~~~~~E~&l

Cg Ca c g »I» aa~CQx .~a ~

QN

OI

00»0

+)C

0D

+-»»lrDi~

»»» OC 'g»»»a+ 0C g»»» 4M

Ihl

+a~UONN

CaOl

ra~~E~N

U-V

+

+-X0 +O

Qlr~a

Cl


6/66


IIIf I

1

,Io»

LLJ 0 LAgQO'A

m col

OO

IllcaYcn 0-

,~op0+-c,'V) n

Vl 'c'i

IL) cb I

w4,

g NC +III 0CLL

CL

IIIII «Ii,,il«llllllP) N

IO+w

l%l

I~

cjI .

IIIa cILI

cQ~~oc

~t) Na.

a cacQX

I I I IvH g QQ0 M

Ln O

IX

gN $

qo

0

lX

0I

NV

0m Qm

In Nrn e)

$QCllX4l+-C0V

CC$ID

CO

O+C0

CCl4l

CLI

IDCV.

C CO

C5 C

N VI I

IO ChOTJ

X

In

N

O in In In

CO

XQ+c0

V)0O

EO

CJ

Odf.

Oc0~CJQ

~~0S

CL

CAc~0tD


7/66


clO

++~»IaCfOl

~~aVOO

I

0~lQO „

O

C +ILl CCL.O.Q~

P) hl8'f

NNN+ltu Cn Cu u II) I-I I I I I

0CCJbl Cl

hLCO

~.~ 0O~tv)Nz

VIV) UU

& CQX -—al M

LlJ 0 lA lA N '~ aaI c 4,e' aai,VI V)

V))CC

U t: hC

X~-~o~ alI,LOa

fff ffll~ '4llf

ff

rCV.

Q0

I- nV)Qsl

Ra~

gg3 3

XQC0

0

=.@F3gN QN

ln XIII

clCJ

(I7

r

gO n In g)

+)C4IC0'V0

+c0

00+NCL

illC00

CY

0f0~+.0

~~~~NN

lACh

~~QL

C)


8/66


LJ Vl VlC CL0 ~~ vlCL C

DV +VILLL-

LLL

O

Nlh C gd 4 8VVCV LLL CLL Py

a &+.a. ~ W W

G.5C ~0& ~m&heO

0 P) ~ P) PJ?Q Pl g LA

1k'?'

Z

'b.~v

O'i O.~v

E '4'@

N4%I-I I INCl Ch

~E

ILl 0 IQ NM lh~MCIM

NP) ALAOQf- CLv) 0

ClLl

I

04lOL

0Zlr

VlCacQ P7Lll CQ+- 0+-

Vl&g a&.CQ

0IA LA Cd00m Pl aCi

VlVl u~ CO Pg

CO 0- tg galg c~ Xa

Vl

aLllCQ+-

0L-

I

M

UillLQ

M

CU Pl

NNNCQ CQ

I I I

Vl %- CQ O ~C5 X

Vl+„ +.oC C ~aaaL. +-

LLL

LO

JL ~l

V)I

aX

0

K-0CbV~rEV)

CFIr0


9/66


LLl

$0

Y 0I-

gO

C0Ol

CQ

Ol

ill

cillL,ill

illLX

V)4 c0

Ih

5CL g+ Q

Caill

CLL

0V C0 ~-V)

aill

4lCY

CCl4l

ClW+

C0

O lA

AQ

/~

4gQ,.i~

Og

g Uillc a+- enalga-~ ~ta c00LLIVM

Qf.

0 lO M~v

iT) g)

N NQ

aO VllllO g

0c~c

0

X .-::-I

3 3

g6Gg

Vl

XOl+c0V

V)0~~Na0+CJVOVlf/I

C$cCO

Ql

C:VIhL

Qf

Cl

0

cD


10/66


lg 0 IA IA N~H (0

H M al Ill (0Z cL

Cc g4I CO

CO

0 c0- Y

C IIIcl aCICO

x0pc Va.cr +

ICc 004lCO

0CO

4lC

0 Y

~mc Vag(0&Ol D

of IOIllNCO

D ~Qf, rlQ rV

k 4N m '0 IA

N VI I I I(0

58 a~ga D

OI IXoct 0

NI

~N

Co +0

QQf.

k kc W NN N

I4 CO COM I I't4 tV'H 'H

JL

4l4I'0

M

0iPI0.I

0Z

I I ICI aI

I

k

0IIIC

M

4I

~a o ~VI ea ooQ+ cC 04ICO

00

III Cc 0a ~4ICix 40

C(I aCOx0

CgD~-I Q

NQ%'V V)I I I

0V

c0 4lCO

0 cl0. Y

IIIk C Ca 4Ig a4I CO Ci

CO

cled0. YW

c hC0 Q(O 0I- O IA IA NM(0 IC II

m Ia~v

ILI IAOIAN(0al ~'m(0

CXA.

m m Ngni

nIn In (n

u ~~~~~(II Vl

ln In In In ln0~v k M k Ai k (() +I ~V c Q0

I- ZPl

p) g N N N N

Q 0 ~Nm~IAk k k k ~LL N m't IAZ sr m

Nr00+COlVlQL.CLtQ

Of.0D00N~~aCLE

00Olc~UTD


11/66


~%I

~%l

tQ

+Dlh0Cf

~~

VlcU

C6

o+- g0 CL

VlcQQ

CQ

+.

Q 0~r~cC ' D—0 ~ .—

Cfco~ g-O~~V &ogo+aQ Cl~

+

E.&wC} CL CY~CLCV

OPV)hC

1t}}VC0CH00

C

f3ggV +- c

+ Q +Dm Xf}}}

Vl ~g D DD

:wV'QIQ

QC5

V)

I

M)C C}0

i 4}QOl

CK

Ol

IQ

CIQCLOl

0cHc00O~CLCL

CFl

c~CJL.


12/66


I

h0 '~+

I DD

I

I

E= gH g 0 ~+ac+ o&g g No~ plya QOl f

f v) gv~ e+OwZI-CI

Cl

ZLULLI

cvtY IA IA IA IA IA IA0

~v g rv g CV g P) (nwN NQW F)w

IAKJ fT)

wM Pl w ~ ~

Qno

~ I

cv Sm

Pl M

g3 2

II

I

I

I

IIX I- -)I

I

I

I

I

IIIVc-+ +'0

+g ~ CQI-CON

Q

cCIIKIII

VW+ CLIII III IIICK 0 CK

I

I

I

I

'~ I6)

IA MI )

x I

I

I

N

~ ~ JC0~ClLIQCL0V)0OQl

~~0

C3


13/66


IIV

CK

nnC3ICl0

I-0U)

O gn P) n) Pl

jI

)I

I

)~'

I

I

GC4l0

'

cCllll

CO

OcCL

t

0EIII

HCY

Cl

V0V)

O

0'o

PN jap)(u

gop@~en3N

/

rV (V OJ+&

o')QICl lO

x P ~~ t+- O'0C '. 0,::;:.=:'A~=V)cr~+ 9 1, EV

~~ NC+-~ g~~ +lS~O 0o~ -'J4e„ 4--i- K ~ III IAg 8 ++ +Hg III H0 g

Qlc~OO0O

CL,EC5X

LJJ

Cl

a~ClL


14/66


~ %

0 ~V ~

:o

a

~~

~ ~ ~

AI

00 ~

c$CFIs

QJ3Vl+.

AI

OV)

, RlsC0

VCQN

AI

VV)

m Q cECION4gc.Q+N Z

+-Cl

O CG

AI

C0NOl

CL

OCopD cnI-I

CO

&y) g) K7(y) lA g)

LO

IO

h- 0

ECgo

0+.Z

IA

N ~O ~-N

AI

I.mCh

~A ~N

4l

OlCQ

OltY0c0~MIcE

I+

AI

Ihl

E0L.~~c

tLI

AI

Cl

0

0CLOl

AI

XIQ

C0V

EM

Chc~C$

Ll


15/66


16/66


UC0M

+ 8N ~N N

m

c0SlS

lA

~ 00N

OltJC0l%

O

C)Ch

CQm LACU

CU Qc

/I

I ..3I

0L. 0+ MQ~Z

LA~.mN ~m ~0 ~NN

OP] s ~ LX), . „@yI ~

~ CUN g) m~ CUmm~

~ ChQ ChU PhLLL

O CULLL aO

WZ

5

U g +U—~~0EOWmm

4) -~~ 0+0 X~ V ~eC

0 ~

0I- ~cri QC ~Q

X hLCf V)

LA

Ol +XC 0NL. C6+5CL~+

00t~0X'0

~bCf

OC0LQ

CL

%l

O04l

CL05i0Olt00

~~C$X0

~h

0c0+'JQ

I

CG

ClC~0S

C3


17/66


OOlc~g 0Ol M

5

+0

Oa.

D g4J He c gQ ~

O

gO

N5IQ tQ ~

C gOl + aa I

4O

IQI

~~acn O

LD

c

I

IIII

I

I

I

C0NSOl

c0Q

~~J3

lM

g

c ~u) OE cn'- c e rbit dL. H 4l

O I-

O )MM

gC&

marXo

..CI

a+DU 5O

Oa)- ~&+-

tn ~ 0Q

+~ gHa- P~&o aEV)0

CFla~C5

CD


18/66


0S~c)m~V~MIII

0 Ill ~ ~ ~L

O

m 4—' —. +

AI ~

, ~ '.0;-.3~ '-:8

0

-'.III

CL

A'I: '. 4—.—..+ .

. '' -4l':.c' '+

+ OIIIl C&cvo2rlny gV ++ 0CIIIl Q

E

gCO CI CIL g C CIII ~ a O4 8 D

IO O

Io; ~, ~m0

VcIll

o. oIItlJ LLI

E EC L

C g

Cl IQc c0 o ID D D*I

N

mC.O

C$

& + r0

E~ oIll

0~Nr~ Q

lll UJ )E

Ig ~tA Q0

p Z +II

MV)

~ ~

LA

4 ~

V)0 gr oalV

cQI QQw cK

cW a.III LD - '

og

In

0ryclMQ Zg

0c III

C3 )4k—

0)CQC0V

NI

CO

I

NI m

COm

4 ~ OI 0

0w0

D &

40-+ 0X Nc0

IAlA

CO CO CO

mm

W ~ CO ChNNNN

g- Hlll g(g)

C$g 'C(

V

00

~C hIII0 —,oc g

00 5

DMa ~(~

g- U)V


19/66


O

0CLOl

CK

0 Cl«0III «Qal III g~a In0 0«xIII «ZH

« Inx~

~xncOo

a 0

0

ala«~oxQg II)W OH

Jr

m NKfg@C

t0IQ

H

I 'OI

g%]'a-g ~s+It J~

IQ C g S-III 0+ g «0oHua«o

g « III 0 IIIct'In & & .L0 + QC

III ~J ~~]

RRI~N I'~%a-- ~ 0 0+tl III

t- pP V)Q K +x

C «III~ C0III«on'cn V0CL

0+ 0a «V 4J0 IIICI

NCV h-

+III X«+~0c

V 0V

pJ. I

e ~ ~

Im~~~~CfQ

QCJ

~~VI

CLOl

+c09CQ

OEOl

HCl+a0CJO

c~0

C3


20/66


1'$

0

i-IIII'l

V

ONOSLQ

CK


21/66


h

1

i

h

h

J

T

hh

l

jj)ll

* A

)I

C-

+

+LOE4l

MUcCf

X

QVCa

Ch

C$


22/66


&L

04l +C )(y

O

a~4l Caae E

CCI 4lo~

M

O

4lEI-

I

4laCL

~U)

0—~ aITI .VO cnCL ~

CY a

CL U)

Q:::-CO .0/

' :0:

0:&~I

CCl m0

~o'l

V4lVlC0VD4l4lDL0

4lEI

4lVaCL

U)

aV

0

',00::CCl,:0

0

0C

LLI

0C 4l

ChH.D0

~ aVm a4la~

~ wO ~4l %Na Ch4l CO

a ~'%j

0G',Es:.'o.

,/:;::g PJ-:. -':Al:-:jjAl:.,Q io:

,„.O.I-

I

Lfj

a o--Vl

~,:-o

+aIA

4~ DlmClCL /LE~Cd

CL 4-N 0 0

0 cil ~.& 0WV-~g4lCa~ 4l%™4lL 0 a

4l ~- Da 'D 'CFIV ~acaODa

CfV~Ul

CL

D

C00

OEQ+

CFIc+CfQCL

Ql

c~C5


23/66


&L

0Ill P

gXg+X cR~Q ~C~ aQ~ C

CD Q

~ W~

+O

EI-

I

OlVQCL

0 a0CL ~l ~

a. V)

oCD; jy)0--.~' o.

O.,;in;

o,

H:&~I

:0)CD ~0~o

Q+a

VQ

0V0tQ

Ill'UC-0

fI

IIlVaCL

lO

DaV

CL

:;:,.0~. o

~hajj',.Al-,'.0;;-;:In-:;

: o

0~'o

Al

0 ino

0CQ ~Ql

CLQ0 gQ0 0

cs aIll+-a ~gO CO ~

L.IllQlg CO

.'o~o

g1

0

/

cLLI

E'UcQD

VJMMIn

o

+aQQIWagcgCL ~0 0y CLOlN ~.~ 0

tQ

OA+ +

Va Q

CLII) I/I

c~.0Al

omP)~ cuUIIl~ InaDo

0U

CfV~Vl

CL4)

c0C00

O

E+

ch+0UCL

0Al

CFI~~0


24/66


Cp+V ~ taN

C

L Ck

0' o0 VlV CD g

)CDO LCf, U-

c0

CL

cC,Cl+- CDCD

C«4

OVl

Vl

+-CD

aCl.

0VlVlCD) VlVlOaVl

OCD Cl+-a

CDc0a ~CDVla

+-

L VlCDV)

Q

+-«CD

0O0

VllC«D g

EaLClL0

oD VlVl cVlI-

Vlc

O

L CDa+'DVI

O 0D ~~

'+-.Vl0

'=- '~O«.~

@i-'~- C.=. ''I«~ +

O«

.:,.* . „-'+-. . o,=«cD.:.- :,„„-',l ..'+-.':Vl:::;;:;Vl ' +—.;. C'.,'.:.',CD.-„«

O«

aCD

X ~aL .

+ LCD+-

CD CDVl

OO CDCL LVlCD

ViCD

al

CDlCl ej$

~M~~

««

CD+ . '««l +a . 'Cl «C Q ', Q L)

:, .« ~Vl ~ «

,0'j'''

+- VlU V): MD

L«pggi

a a C,'+

n- ~~ O- ~= 0-; i+ V«~ S CD 0 S CD ' S+

04 - CD OC'.0 M 0~~CDc CDc~V) ~ ~V) ~ ~V)~

I~hc .-W 445)o: o ~ . o ~ -,'i VVV««l . g s:,':.,;POPac ~j aa

CAa~C

C Hl


25/66


Of

+.CIII aIC+- C0CL IE '&oA UI

IA

C4

IA

Qt

CAE+L a.E'H UI

QI0

(9

~-%hl~&

0-CLIA

.CV

,\H

I/I4I

Q IIl~~ QO~IaIO gZ QJ

EP cr

MIIfI ~Ial w~Z

pa'c» ~a'+a4-'~.4+I»4'4aI »a+4 4»W 4+

a sQ++0+%~IIIa +I +4M.+»»

a++

»~'IO CI~.Pl PLhajj'''ed-

c8tC

LU

cl

CLE

CalllQ

tel

CFlacOl

L.Ol

CKI

cHNCU

Clc0


26/66


L0Cl

IQVQL.Ol

v) I-Ovw Ouamu 14~l-lvtLl el-Ov~ Oaoma

V)LLIO

ogv /mingO~& aca

Z Pc 3 9

NX ChI- c

LA

LLI IA C& IA Ng&

4 N N g IQ

IAUO

Cl

CtlOl++ Cl

L0Ll

CJl %0c a-4l5 EvZ

CV

CFIa~0

C3

C V) W Q Q LLI I- CX M %J ~ M


27/66


Vl X Q Q tlJ I- K M H ~ M

aV 4lYn~O

SQ.—Q

CQ

cg N

O„O„0„vj


28/66


N N CC)

,o;ClCCI

C~Ct

Cgl

'O+WW

,aa

Cll 0 CA LA NtJ ~ CK)CL CA CA CA. CA.-

I/I

V

I- ccilii v.R9

lh 0, NClj

aNNQ'U CCl CCl V

I Itt Itttttttittttttt tVI III IIIC III g + Cg g o Q

5C CnIcl Ccl g Ccl

'Ot ;oQ~C'C-X~Q PL c-~ ClXautu) Ra-.~RE

+-cc) 0 Cll0

pg ~o'

/~ N

I

M

N

NCl

N

~H

MV)

0hLIS

EEV)

8

c+Wl

Clw &a

O cIICCC

g Ig

Co aIX

0OCA

CV)

CCcl

m

Cl'g C CCCCcl Ctl O g.+

a ~ a+=x ~e eCl g + CIl R V)ci v L~.o~)&

Clice

aalu- 'LI ~4 hC

V) g ol Ic 0 gCciOg& C.&+ci + O

CCC

IAAJCA

Cf

D


29/66


pN

0 N

EdZX

c0V

op~

opw

I/I 0CCI 6 III-Eg

/I d + +-C I/IQ)OI+CII + III hC~ CO I/I & 4 y/I.~~.-+- cO I/I 0 ~ C OOCII g Ill O~

C Cll ~ C~ CCIOPddarI 'Q~g +0 & v c+ CII I/I + CII '-I/I

dC —C III&~+% dxt-e

p~

~pN

jp

I/I

0 cQ~- acCQ

IQ Ci CLCII0~Lu &O ~ CIIICI

OfI I/I-op~O ddl- ~c Q) P/I,0~Ã 0

O

0'.(fj

go, m +plCII

H

III

/'Y

eoc ui0 CL-I/I N

0

e 0 ~+0~

V)

~r

I0

'L0+.~O

~pIA

'~.'~

O &

1;&g 1N

IA, IA IACV

c0vj

0I

ECV)

4

NClc~0D


30/66


On CPl

Cll

O'+CO

'2?

@--3/4'?y?

'?'


31/66



32/66


l/l+CL

c

ill

Q.+0

UQ


33/66


qO

0~D

pO

Q L)I- cf.v) 0

CY

0

1 I

ki

imtQ

Q EF

O~ KEJ Pg,

~~'~ I'Otu IN

QtY0I-

Q Q00I- I-v) v)

oI III ILJI Ll

0 ~mO-I 'V I-0 +

II-

I ~ (y':oCK Q

Q QI ~OpI cO«o e-

I

II Cl IQ I

o O III III II I

lhQlo a

Cf CLV

N

a

I-~ v)u)

QQQ

~ ~o~iQN v) v)

0p co~ cx7

tn in U v)KHZ H

0~0v) C-i„''

+Ol 0Q C0 0

o0 II+ II)c

QQQ. IItY QC QC ~ ~Q,OOOI- I- I-v) v) v) Q0& (3

4l

CL o cu 0

Irn0 H H

+0Ol

Jho ~+v)w~~

Q Q'Q 0 IXo . QOOPOILU n v)

- I0

0OI go D

QCY0 Iv) I

0~o+

v)M

thg, l/lc+V I ~

oCJ

g 0CL Q

Vl

Q 'LClEo

LI


34/66

US 8,051,102B21

DATA BASEAND KNOWLEDGE OPERATINGSYSTEM

CROSS-REFERENCESTO RELATEDAPPLICATIONS

This application claims priority to corresponding Provi-sional U.S. Patent Applications 60/398,843, filed Jul. 26,2002 and 60/457,207, filed Mar. 25, 2003.

FIELDOF THE INVENTION

The invention pertains to the field of data management,most commonly called Database Management Systems orDBMSs.

BACKGROUND OF THE INVENTION

The earliest business-oriented data processing applicationsconsisted ofrecords of information contentcollected into flatfiles based on like record structures. Each department withinan enterprise attempted to independently computerize theirdata-intensive functions (e.g., invoice processing, customerbilling). Aspects of the enterprise's data were repeated orreplicated at will, as these flat files of information were spe-cifically engineered for each aspect of the separate softwareapplications. There was a massive level ofdata redundancy inthe flat files, which made information very difficult to updatecompletely and often resulted in software applications givingwrong answers or taking inappropriate actions. Flat file com-puting also meant that there was no enterprise view of dataacross the spectrum ofdepartmental information. Each soft-ware application used a unique physical data storage designand basic device access methods supplied by the hardwaremanufacturer to implement physical data management withinthe application. The flat file approach to data processing wasextremely error-prone and costly, and provided no strategic

view of the enterprise.This situation led to a universal quest to separate physicaldata management from the functional software applicationsand create independent, reusable applications whose solepur-pose would be physical database management. These appli-cations became known as Data BaseManagement Systems orDBMSs.

Because enterprise data often has rich structural complex-ity that is almost impossible to capture in flat files (ke., allstructural complexity is flattened into two dimensions andhence the term 'flat'), the first attempts at independentDBMSsused smaller records oflargely non-redundant infor-mation with either hierarchical or networked 'pointers'. Tochoose among these DBMSs it was necessary to decidewhether the data was inherently hierarchical or networked.Both approaches provedto have limited scalability. For theseand other reasons, hierarchical and network DBMSs met withlimited commercial success.

In 1970,E. F. (Ted) Codd of IBM published a relationalmodel ofdata storage and retrieval for large shared data banks(CODD, E.F.,A Relational ModelofData for Large SharedData Banks, Communications ofthe ACM 13,6 (June, 1970),pp. 377-387,hereafter referred to as [Cod70]).Ted Codd'smodel for organizing database records with limited redun-dancy is a set-theoretical (mathematical) model that treatsdata contents the same whether itsunderlying structures arehierarchical or network-oriented. Though elegant and univer-sal, Ted Codd's approach was not largely adopted through theearly 1980sbecause mainframe computers of that day wereincapable ofsupporting the input/output intensity required by

5

10

15

20

25

30

35

40

45

50

55

60

65

a relational DBMS (RDBMS). As hardware capabilityincreased through the 1980s, most industry practitionersbegan to line up behind Codd' RDBMSas the best means tomanage large shared data banks.

While there are hundreds of thousands of business-ori-ented software applications today that still operate with flatfiles and hierarchical or network-based DBMSs, these meth-ods of managing enterprise databases are considered out-dated. Information update is now the province of on-linetransaction processor (OLTP) sites that are implemented byRDBMSs.Large-scale complex query is increasingly beinghandled by specialized applications called data warehouses(DWH) that operate on vestiges ofCodd's relational model.Ted Codd' relational model today stands astride the world ofenterprise computing.

Despite near-universal acceptance as a database manage-ment mechanism, there arehuge problems with the relationalmodel. The most significant is the lack of relationship defi-nition. Relational modelscontain almost no clues as to a) howthey were created; b) what the various relationships amongthe data actually are; or c)how the relationships are reflectedin the model. Mostpractitioners and experts who work withthe relational model are destabilized by its lack of semanticcontext. As a result, many experts, including Ted Codd him-self (CODD, E.F., Extending the Database Relational Modelto Capture More Meaning, ACM Transactions on DatabaseSystems 4, 4 (December, 1979), pp. 397-434, hereafterreferred to as [Cod79]), have attempted to create semanticdata models (HULL, R.,KING, R.,Semantic DatabaseMod-eling: Survey, Applications, and Research Issues, ACM Com-puting Surveys, Vol. 19.No. 3, (September, 1987)pp. 201-260, hereafter referred to as [Hu1187]). For example, asemantic datamodel posed by Peter Chen in 1976(CHEN, P.P., The Entity-Relationship Model Toward a Unified ViewofData, ACM Transactions onDatabase Systems I, I (March,1976),pp. 9-36,hereafter referred to as [Che76]) is almostuniversally accepted as the means to determine the semantic

context ofa relational model.There have been many serious attempts to implementsemantic data models (SDMs)as DBMSs.None have reachedthe commercial marketplace, partly because they are moredifficult to implement just the required optimizers are difficultpropositions), and partly because they are typically moredifficult to use in real business settings. Also, the more seman-tic context a DBMScaptures, the more difficult it is to makecorrections and changes. Though such changes may have lessimpact than when the semantics are managed by the func-tional application, efficient support for semantics in a DBMSis very difficult. Getting a value-based or record-basedDBMS to work takes significantly less resources. Anothernotion as to why semantic datamodels have not done better inthe commercial marketplace is that semantic context does notdo much to improve performance (and may actually retardperformance). Given that RDBMSs are challenged for per-formance, it is probably not surprising that more semanticcontext has not found its way into value-based DBMSs.

With rare exceptions (e.g.,Sentences from Lazy SoftwareLtd), semantic datamodels are not used as DBMSs.Unlikehumans, a computer has no need to understand the semanticcontext ofdata. A computer needs only for the DBMSschemadefinition to be efficient for maintenance and execution. Ifsemantic context helped a computer to be more efficient, therewould be a reason to include semantic information in theexecution system. There is no reason to believe that semanticcontext would improve the performance of the relationalmodel. For example, there are no RDBMSs that also imple-ment Peter Chen's E-R semantic datamodel [Che76].There


35/66

US 8,051,102B2

are numerous semantic data models and specialized imple-mentation techniques, but there is only one widely acceptedmeans of implementing enterprise databases an RDBMSrunning on the relational model.

Background Art Relational Model:Ted Codd's relational model (originally [Cod70] but

defined for current context in [Cod79])is the foundation forrelational DBMSs, which aretoday the prevalent implemen-tation for enterprise systems. In a relational representation,which is shown in Drawing 1., Relational Model , all data isfolded into two-dimensional relations (tables) consisting ofattributes (columns) and tuples (rows), such that some com-bination of the attribute values will uniquely identify eachtuple (primary key or PK).Such a 2D table iscalled a relation(hence, the term relational. The remaining attributes (col-umns) in a relation (i.e.,those that are not part of the PK) arecalled the non-key attributes or NKs of the relation. Withineach relation, integrity is ensured when the NK attributes aredependent upon the whole setofthe designated PK attributesand nothing but the whole set of the PK attributes (normal-ized, normal form, third normal form and 3NF). Creatinglookup relations that define the range ofacceptable values foran attribute ensures attribute-level integrity.

Relations (tables) are connected to one another only byshared combinations of identifying attributes. PK attributesmigrate from relation to relation, where they are known asforeign keys (FKs).FK migration begins with the primaryrelations, which are the relations with only one attribute in thePK and no FKs. Relations with multiple attributes inthe PKare called associative relations. Information is typicallyextracted from a relational model by projecting and/or select-ing, then joining the resulting relations according to the FKsand, finally, filtering the results table based on any attributevalue limitations specified in the transaction. StructuredQuery Language (SQL) can specify the data manipulationinvolved inprojecting, selecting, joining and filtering. Whenan enterprise database structure has been captured in its cor-rect (canonical or normalized) relational format, there is noredundancy in the stored NK attributes.

The best definition ofthe relational model can be found in[Cod79],Section 2. The Relational Model , which definessuccinctly that which is generally accepted as the relationalmodel. The remainder of the paper ([Cod79])proposes anextended relational model to capture more ofthe meaning ofthe data. Codd's extended relational model sought to movethe relational model toward a more semantic datamodel withat least four personalities . The extended relational modelwas not adopted by industry.

Advantages of the Relational Model:The relational model has a highly evolved structure that

facilitates data retrieval and a ero data redundancy goal forNK attributes that ensures data integrity. The relational modelalso separates logical data representation from the physicalimplementation. The data repository can be plied with a rela-tional calculus implemented by a highly evolved and broadlystandardized SQL, for example, as specified in [SQL92].

Relational Model Advantage Application-OrientedStructure:

The process for evolving a relational model causes the datamodel to exactly mimic the business model. Each relation iscreated to exactly support some number ofend-user views ofdata that are required by the software application. Once thecorrect relational tuples are located in the relational model, allofthe necessary attribute values (instances) for the particularuser view are directly contained within the structure of the

5

10

15

20

25

30

35

40

45

50

55

60

65

tuple. No additional dataneed be accessed orretrieved (ex-cept, sometimes, lookup values that can be stored inmemory).

Relational ModelAdvantage Limited Data Redundancy:The normal (canonical) form of the relational model

ensures that no tuple of attributes is stored more than once.This has the advantage ofreducing the amount ofdata to bestored and ensuring that updates to non-key attributes will beperformed without anomalies. Each question posed to anRDBMSshould only be answered in one way (when multiplereplicated tuples are involved ina data model there exists thepossibility that the data replicas will be out-of-synch and,thus, provide wrong answers to questions). The elimination ofdata redundancy from the flat file model was one of thedriving features of the relational model.

Relational Model Advantage Relational Calculus andSQL:

The relational model has a highly evolved relational cal-culus for manipulating the elements of the model and abroadly standardized SQLfor plying the relational data struc-tures.

Problems Involved in the Relational Model:The principal problem involved with the relational model

is that its fundamental data structure is both highly evolvedand application-dependent. In simplest terms, the rowxcol-umn structure of a relation lacks symmetry. The attributesthat are bound into the various relations, the designations ofthe PK attributes and the nature and structure ofthe intercon-necting FKs are as unique to a given enterprise' operation asfingerprints are to a person. Relational application software,written in SQL, relies completely on the structure of therelations and business rules.

Each aspect ofthe relational model maps to many differentviews/interfaces in the application and each view/interface inthe software application interfaces with many differentaspects ofthe relational model. This many-to-many relation-ship between the application software and the representation

of the data has the effect of binding together the applicationand data so tightly that a minor change in either can havemajor consequences on the other. Becausethe relational mod-el's application-dependent data structures (ADDS) areunique, complex and fragile (resistant to change), the ADDSfeature ofthe relational model causes many severe problemsin the software applications.

Relational Model Problem Involved ADDS vs. Rela-tional COTS:

ADDS makes the distribution and maintenance of com-mercial off-the-shelf (COTS)application software a very dif-ficult business proposition. Becauseeach application is inher-ently unique (by virtue ofthe ADDSuniqueness), it is difficultto achieve the economy of scale necessary tosustain a busi-ness distributing COTS applications. If the data model ismade more flexible (complex) to accommodate a range ofvariation in the underlying business model (such as varyingoperational practices within an industry), the artifacts ofthisflexibility will cause the application software's complexity toincrease, proportionally, to handle the increased operationalflexibility (because SQL is tightly bonded to the data struc-ture). Although any given implementation only uses a smallportion of the ADDS-induced flexibility, every implementa-tion must be able to fully identify and understand the flexibil-ity. The relational equation flexibility implies unnecessarycomplexity is inescapable with respect to any given imple-mentation ofthe COTS software.

Relational applications that are built on such flexible rela-tional model data structures often suffer operational difficul-ties and failures that are not caused by any aspect of the


36/66

US 8,051,102B2

particular enterprise's business model, but rather are causedby unneeded and unused artifacts of flexibility (included inthe COTSapplication to accommodate competitors'usinessmodels).

In addition, identifying, understanding and ignoring theunused artifacts of induced flexibility in the application andthe data model necessarily consumes the most talentedhuman IT resources of the enterprise, as well as other insti-tutional resources such as data storage, processing, trainingand documentation. As the COTS software vendor's cus-tomer base continues to grow, the need for flexibility andattendant complexity increases until the existing customerbase begins to reject the COTSapplication. This often resultsin the failure of the COTS application vendor.

It is fair to state that the ADDS inherent in the relationalmodel are the root cause of many if not most commercialfailures ofCOTS application software vendors. [ke.,a) com-mercial viability requires vast flexibility, b) because ofADDS,vast flexibility implies unnecessary complexity (withrespect to any given customer), and c) ever increasing andunnecessary complexity causes customers to stop using theapplication.]

Relational Model Problem Involved Long Frozen Base-lines:

For a given relational software application, the completestructure of the relations must be known/defined before thecoding of the application software can begin. Thus, becauseofADDS, long frozen requirements baselines are necessaryso that the relational modelers can ascertain and document thespecifics of the enterprise's data structure (it is not uncom-mon for enterprises with complex data structures to requirefrozen requirements baselines measured inyears). The com-plexity is so extreme that it is often necessary to use semanticdata models to first describe the data model in abstract terms.Because the underlying data model of the enterprise doeschange during the period of the frozen baseline (sometimesconsiderably), relational application software typically lags

behind the true enterprisemodel, often toa substantial degree.Relational Model Problem Involved Resistance toChange:

Because of the ADDS and the tight bond with SQL, rela-tional software applications are highly resistant to even thesmallest changes in the structure of the relations. Themostsensitive problems in this area are involved with changes inthe single PK attributes of the primary relations. Any givenPK for a primary relation can migrate to become FKs in asubstantial number of relations within the enterprise's rela-tional model. Any changes in such PK attributes can inducechanges throughout a relational model, as well as the associ-ated application software. This implies that minor changescan be very costly to make, and necessary changes are oftenavoided with costly workarounds (because the cost to correctthe problem in the application is even greater). As a directresult of ADDS and FK migration, relational applicationstypically have years of unapplied application changerequestsin backlog. This is why COTS enterprise applications basedon the relational model typically have a low degree offit to thecustomer' needs.

Relational Model Problem Involved Structural Degrada-tion:

On the typical enterprise application, RDBMSs are facedwith a physical reorganization problem relative to the basictabular organization of information. The problem, which isattendant to the ADDS, is that relational information is storedin a highly-organized form which should be at least clusteredif not physically contiguous on the storage medium. How-ever, a table isonly represented inits pristine structural form

5

10

15

20

25

30

35

40

45

50

55

60

65

on the storage medium when it is first loaded (or re-loaded).When rows are deleted and inserted, this clustered physicalarrangement on disk cannot be maintained. Over time, theRDBMSwill gradually lose much ofits throughput efficiencybecause of the relational model's reliance on structured datastorage. The enterprise may simply accept this loss of efft-

ciency or correct it by periodically reorganizing the tables onthe physical storage medium.The problem of structural degradation is inherent inrela-

tional data management. Reliance oncomplex physical datastructures is the problem. All complex physical data storagestructures degrade over time. When the DBMS relies on thephysical structures for organization, processing efficiencydegrades in proportion to the erosion in the physical struc-tures.

Relational Model Problem Involved Need to De-Nor-malize:

Normalization is considered a key theoretical strength ofthe relational model. In practice, it is one of the great weak-nesses of the model. It is a rare implementation of the rela-tional model that can afford the inefficiency involved infullnormalization. The join operation isextremely inefficient andthe greater the degree of normalization the more joins must beperformed. De-normalizing the structures of the relationalmodel provides for operational efficiency but leads to updateanomalies and significant redundant data that then must beplied to support operations. This is especially true of therequirement to keep the data replicates updated in synch withthe copies ofrecord. All ofthis complexity must be added tothe application. Complex queries require so many joins, thatdatabases on the relational model must often be de-normal-ized further just to support complex query. When the updateprocessors (OLTP) cannot support the added redundancy (de-normalization) that is required for complex query, it is fre-quently necessary todeploy separate DWH sites just to sup-port the complex query.

Relational Model ProblemInvolved Elemental Security:The security requirements of enterprise applications are

difficult to predict. Customers oftenrequire that security clas-sifications (for access to data) be at the row or column (at-tribute) level. In some cases, customers may require securityat the 'cell'evel of a table (rowxcolumn). There are nopractical ways to implement security labels within the cells oftwo-dimensional table structures (certainly none that are efft-cient). This is so because security is actually a different, thirddimension to the two-dimensional table. A certain 'row-col-umn'ombination (two-dimensions) might require no secu-rity, or one or more security labels. Ifthe security dimensionis collapsed (folded) onto the two-dimensional table, as isrequired by the relational model, the result is not good.

This is an example of one area where induced flexibilitymakes the relational model untenable. To make applicationsbroadly useful, the underlying data model must allow forcell-level security. Yet, cell-level security may only beinvoked ina few instances. The rigid relational table structurewould have to be built to handle security labels on allinstances (cells). This approach is enormously inefficient.One alternate possibility is to create adjunct table structures(category relations) with only the row-column values thatrequire the security labels. In a secure mode, this doubles thenumber of reads that are required to process transactions.

The more dimensions ofcomplexity that exist in the appli-cation (such as security) the more difficult it is to implementthe application in a two-dimensional relational depiction.


37/66


38/66

US 8,051,102B210

the more robust semantic models developed by, among oth-ers, Codd himself [Cod79])is rooted in its simplicity.

One grouping ofsemantic datamodels that is related tothisinvention including a Knowledge Operating System or KnOSis the one that describes data as two constructs: entity sets andbinary relations. These semantic binary data models(e.g.,[Abr74],BRACCHI, G.,PAOLINI, P., and PELAGATTI, G.,Binary Logical Associations in Data Modeling, Modeling inData BaseManagement Systems. North Holland, Amerstam,(1976) pp. 125-148, hereafter referred to as [BPP76],DEHENEFFE, C., HENNEBERT, H., and PAULUS, W.,Relational model for a Data Base, Proceedings ofthe IFIPCongress, (1974)pp. 1022-1025, hereafter referred toas[DHP74], HAINAUT, J. L., and LECHARLIER, B., AnExtensible Semantic Model of Database and its Data Lan-guage, Proceedings ofthe IFIP Congress, (1974)pp. 1026-1030,hereafter referred toas [HaL74], and SENKO, M. E.,Information Systems: Records, Relations, Sets, Entities, andThings, Information Systems I, I, (1975)pp. 3-13,hereafterreferred toas [Sen75])treat each binary relation as an inversepair of possibly multi-valued functions (see Drawing 6, Semantic Binary Data Model ). The SBDMs and thepresent invention have the same core construct (sets ofbinaryrelations in inverse pairs ofpossibly multi-valued functions),but the present invention is not a semantic datamodel, per se,in that it does not seek to define relationships. Instead, thepresent invention treats the binary relations as basic, unnamed associations , in much the same way that the relationalmodel implements the net results of the E-Rmodel.

In short, people crave semantic context; computers andDBMSs do not. DBMSs benefit only from efficiency andmaintainability. Ifthe inclusion of semantic context makes aDBMS less efficient or the database/application less main-tainable, it is a weak candidate for addition to a DBMS.Unfortunately, semantic data models do both (less efficientand less maintainable). The more semantic context a DBMScaptures, the more changes are required when one discovers

either that mistakes were made or that the enterprise modelhas changed. If this were not true, all of the commercialRDBMSswould have absorbed at least the E-Rsemantic datamodel [Che76] into their basic framework.

Advantages of the Semantic Data Model:One of the better treatments of semantic models was pro-

duced by Richard Hull and Roger King in 1987, SemanticDatabase Modeling: Survey, Applications, and ResearchIssues [Hu1187].Semantic data modeling techniques providethree principal advantages over record-based or value-basedmodels such as the relational model.

Increased separation of conceptual and physical compo-nents. In the relational model, the access paths available toend-users tend to mimic the logical structure of the databaseschema directly (by comparing identifiers in order to traversefrom one relation to another). The attributes of semanticmodels are used as direct conceptual pointers. Decreasedsemantic overloading of relationship types. The relationalmodel only has two constructs for recording relationshipsamong objects:a) by binding attributes within relations and b)by using the same values within two ormore relations. It is forthis latter reason, that the relational model is often called value based .

Availability of convenient abstraction mechanisms.Semantic models provide a variety of convenient mecha-nisms for viewing and accessing the schema atdifferent levelsof abstraction.

Peter Chen's Entity-Relationship (E-R)model [Che76] isthe most widely used and widely recognized semantic datamodel. The E-Rmodel is the standard semantic data model

5

10

15

20

25

30

35

40

45

50

55

60

65

for understanding, analyzing, defining, designing, describingand improving a relational model.

Problems Involved in the Semantic Data Model:Semantic data models have been widely used in schema

design but have not experienced much commercial success asa means of implementing computing solutions. There areseveral reasons

forthis.

Most of the semantic data models are not implementationmodels (they are used for schema design). For example, theE-Rmodel is not an implementation model.

Many semantic datamodels areused by the object-oriented(OO) behavioral computing paradigm. OO has suffered froma lack ofsuccess because many enterprise datamodels do notsustain a broad-based crisp boundary condition (the corerequisite ofOO).

Many semantic datamodels have a narrow focus of inter-est, which is not well suited to commercialization as an imple-mentation model.

Many semantic data models aretoo complex to gain wide-scale usage. Codd's own semantic extension to the relationalmodel [Cod79]gained no following because ofits theoreticalcomplexity. The very simple E-R model is the standardsemantic datamodel for defining relational models.

The simplicity inherent in the relational model permits thedevelopment of powerful, non-procedural query languagessuch as ANSI SQL. Many semantic data models can bemapped to a relational model for implementation, therebytaking advantage of the general computing features of rela-tional modeling. Asa result, many semantic datamodels areimplemented on the relational model by an RDBMS.

There is no body of expert opinion today to suggest thatsemantic data models will ever replace record-based datamodels (relational, network, hierarchical) for implementa-tion. But, it is likely that semantic data models will alwayshave a place in the field of schema analysis and design.

BRIEFSUMMARY OF THE INVENTION

The present invention is referred to as the KnowledgeOperating System or KnOS, and is a new computing frame-work for database management, one that works associatively,the same way that humans think. The KnOS's basic organi-zational scheme is the inverse ofan RDBMS,or &data values-&relationship&. This gives the KnOS cellular granularity andallows it to answer any kind of query with maximum efiI-ciency. The KnOS does not attempt to store data according tothe relationships in the enterprise model and, thus, theKnOS's physical storage structure isapplication independentand does not have to be changed when the enterprise's rela-tionships change. Also,when processing data, the KnOS doesnot use asymmetric ASCIIvalues, but rather uses fully sym-metrical Vector Key references.

The KnOS design resolves the problems involved with therecord-based (relational, hierarchical, network) DBMSs, asstated above. The intent of the KnOS invention is to supplantand replace current generation DBMSs on the relational, hier-archical, network, or any other currently implemented datamodels, including both OLTP and DWH.

The invention will generally be practiced through themethod of using software with one or more computers. Asshown in FIG. 2S, the invention can be implemented withcomputer hardware and software. In the embodiment ofFIG.2S, inputs and outputs are shown to the KnOS processor.Theprocessor then manipulates data and instructions consistentwith the invention. In the embodiment ofFIG.2S, data can bestored either within the computer's own memory or externalmemory. While it is presently preferred that the invention is


39/66

US 8,051,102B212

practiced on a single processor, it is also within the scope ofthe invention that the system be utilized on one or morecomputers in a computing environment, including computerslinked such as by the Internet or other network systems. Forsome specific applications, it may be desirable to utilize theinvention with both software, hardware processors, and firm-ware. FIG. 29 shows a firmware device having three func-tions, specifically including security, license key manage-ment and pooling functions. Other embodiments usingfirmware may implement other functions in the firmwareportions. In such a firmware/hardware/software system, theKnOS processorwith itsassociated software can be assignedcertain functions while other functions are implemented byfirmware. In some embodiments, both the firmware and theprocessor can in various applications read and write data tothe storage device or devices. While FIG. 29 shows threepresently preferred functions in the firmware block diagram,it is to be understood that other embodiments can have thefirmware processing different aspects of the invention.

For the purposes of clarification the following terms mayapply:

Application: a complete self-contained program used toperform a specific function

Data Instance: any piece ofdata, information or knowledgethat is differentiable. For example, any piece of data, infor-mation, or knowledge, such as any attribute, item, determi-nant, key, table, column, row, field, container, repository,environment, class, type, model, function, method, operation,relationship, display element, query, data model, view, report,user display screen, data type, file type, item path, file name,computer name, UPC code, URL, user, connection, status,quality, classifier, word, sentence, paragraph, page, chapter,volume, object, partition, sector, or reference, that is userdifferentiable.

Atomic: that which is indivisible by definition withoutdestroying its basic nature.

Fundamental Data Structure: Thesmallest structural com-

ponent ofa data storage or data representation paradigm.Item: The fundamental unitof the KnOS database, basedon the Fundamental Data Structure, the Item encapsulates aself-referencing Vector Key, a Data Instance, and sets ofVec-tor keys referencing other, associated Items.

Vector Key: A multi-dimensional, unique reference to anItem

Vector Key Set: an array of Vector Keys, encapsulatedwithin an Item, which represents a particular type ofassocia-tion between the referencing Itemand all of the Items refer-enced by Vector Keys in the Vector Key Set.

Logical Address: The abstract location of an item, inde-pendent of its actual physical location.

Logical Index: A token or value that directly references theabstract location ofan item as opposed to its actual physicallocation.

Some aspects of the KnOS may superficially resembleexisting data management paradigms and techniques, but theKnOS design is a wholly new invention in datamanagement.The KnOS is a fully symmetrical computing frameworkincluding all of its values, relationships, structures, and con-tainers and all KnOS operations are simple boolean func-tions performed on these symmetrical features. With 100%symmetry of form and function, the KnOS can operate as anative, massively parallel vector machine. The KnOS usesvectorized value representations ofcellular granularity basedon a format which is universally recognized across KnOSimplementations. This means that independently generatedfunctional applications can exchange information without apriori agreement or structural/schema knowledge. With a

5

10

15

20

25

30

35

40

45

50

55

60

65

fully-inverted design and minimal structural contention, theKnOS canrun both real-time update and complex query on asingle data copy, on any computing scale with more inherentprocessing efficiency than the best DWH products. Becausethe KnOS's core fabric isa binary associative structure, it iscalled an associative database management system, orADBMS.

The key differentiating factors ofthe invention are that it isbased on a Data Instance centric architecture, where DataInstances are typically atomic, that is, indivisible by defini-tion from a user perspective, such as the datum in a field in atable in a database, where each Data Instance is at the centerof all its associations, and where the base structures thatencapsulate the Data Instances, the common FundamentalData Structures, are identical in form and function, are appli-cation independent and also contain encapsulated referencesto all other directly related independently encapsulated DataInstances. The encapsulated references are both unique iden-tifiers for each and every associated Data Instance and are alsological indexes that fully encode the abstracted location ofeach Data Instance, making it possible to both identify andlocate any Data Instance using the same reference key.

With respect to Data Instances, the encapsulating entity isreferred to as an Item. An Item encapsulates a DataInstance, as well as all ofthe references defining the associa-tions between the Data Instance and all other related DataInstances. Items are based on the Fundamental Data Structureand are identified by a Vector Key, which is a multi-dimen-sional reference that uniquely identifies each Item in theKnOS system.

The KnOS is the first wholly symmetrical enterprise com-puting paradigm, as shown inDrawing 27, KnOS Symmetry.To the KnOS, every value looks exactly like every other value,every relationship looks exactly like every other relationship,and every structure looks exactly like every other structure.This fundamental symmetry in the computing model, whencombined with cellular granularity, allows multiple proces-

sors to subdivide the workload with ease and execute opera-tions with parallel abandon. For example, the KnOS has andrequires no comparable action to relational joins. TheKnOS conducts all processing with optimized binary tree (orequivalent) searches on fully vectorized, symmetrical struc-tures. Cellular granularity, fundamental symmetry and theuniversal use ofvector representation can maximize proces-sor efficiency to its theoretical limit. Among other things, thismeans that improvements in processor performance yieldproportional improvements inKnOS performance. This is nottrue of any RDBMS or any DWH application. The KnOSdesign resolves most of the issues extant in the relationalmodel.

Value Symmetry Whenever any atomic data value (ke.,aData Instance, such as White Beans , $9.85 , 5 ,... isfirst inserted into the KnOS ADBMS, it is registered with aglobally unique, symmetrical reference value in a vector for-mat, known as a Vector Key. In its preferred embodiment,the KnOSVector Key has four dimensions of location embod-ied therein. They are called Environment, Repository,Context and Item, and will be expressed herein asgE,R,C,I).WI White Beans (a Data Instance) were inserted into the Stock Context at the Manhattan South Repository of the Global Environmental domain, White Beans might beregistered tn the KnOS with the Vector Key (E,R,C,I)=(0,6,1,3).The Vector Key may be expressed as a symmetrical setoffour dimensionally-unique thirty-two-bit binary integers indistinct blocks offour words each. This 16-byte VectorKey isthe KnOS's globally-unique identifier for each Item. In addi-tion to providing unique, symmetrical, compact value repre-


40/66

13US 8,051,102B2

14sentation, the KnOS Vector Key can be used to locate infor-mation. The Item (0,6,1,3),which encapsulates the DataInstance White Beans , can be found as the 3rd Item of the1st Context in the 6'epository in computing Environment¹0.All managed data values are registered in this fashionwhen they are first loaded. All further references to or uses ofany ASCII values by the KnOS ADBMS refer only to theseproxy Vector Keys. This design feature establishes theKnOS's value symmetry, as shown in Drawing 23, ValueSymmetry.

Relationship Symmetry All relationships are recorded inthe KnOS as one or more binary segments, where each seg-ment is an inherently bi-directional association between twoItems. As a default, the KnOS environment automaticallymaintains the bi-directional integrity of the pair. If Item Apoints to Item B then Item B will always point to Item A.KnOS associations are not named, per se, but instead arevalue-based, and they can be classified to improve efficiency(semantic classification is a KnOS tuning technique). When-ever KnOS Items suffer from semantic overload AND theapplication can distinguish amongst the associative contexts,then the KnOS will store the various associations by context.This reduces the I/O required to identify the correct associa-tions, which improves performance. Thetechnique for stor-ing and retrieving relationships using bi-directional pairs ofbinary associations is fully symmetrical. Drawing 24, Rela-tionship Symmetry, shows that if 'Stock'tem WhiteBeans, identified by Vector Key (0,6,1,3)is associated to a'Price'tem of $13.45, identified by Vector Key (0,6,2,3),then the relationship between 'tock'nd 'rice's inherentlysymmetrical (as in $13.45 is-price-of White Beans ).Note that the same association, expressed as a tuple in therelational model, is only symmetrical ifthe 'Price'olumn ofthe Stock table has a secondary index. In addition, all KnOSrelationships are expressed symmetrically both within andacross associations, whereas relationships in the relational

model areexpressed bothwith tuples and with foreign keys orFKs, which is asymmetrical both within and across the rep-resentation.

Structural Symmetry The target Vector Key of each bi-directional pair of binary associations is stored fully encap-sulated with its subject Data Instance. If White Beans (sub-ject) has-price-of (relationship) $13.45 (target), the Itemholding the target dollar amount might get registered in theKnOS as (E,R,C,I)=(0,6,2,3).The subject Item (0,6,1,3)( White Beans ) would be encapsulated with the target Item(0,6,2,3)(for $13.45),and vice versa. These type-classifiedsets of encapsulated references for each Item are stored inordered one-dimensional arrays, called Vector Key Sets (VKSets) by context type, as shown in Drawing 25, StructuralSymmetry KnOS Items. Every Item has the same fullysymmetrical database structure a) a self-reference (VectorKey), b) a Data Instance, c) Relationships (expressed as VKSets), and d) (optionally) one or more Item Embedded Ele-ments (IEE).KnOS Item structures, with all of their encap-sulated target References, are also classified by type andstored in classified Contexts, for example, 'Stock'n oneContext and 'Price'n another, as shown in Drawing 26,Structural Symmetry KnOS Contexts. Each Context hasthe same construct as every other KnOS Context, whichmeans that KnOS Contexts are fully There are many advan-tages of the KnOS system in comparison to systems of theprior art. These differences and advantages are summarizedbelow.

The following outlines some ofthe advantages andobjectsof some ofthe embodiments of the invention.

6

10

16

20

26

30

36

40

46

60

66

60

66

COTSApplications: Because KnOS Items are cellular andKnOS Contexts are both fully independent and 100%sym-metrical, KnOS databases are not application dependent. Thisindependence holds on the broadest possible scale. TheKnOS schema of an enterprise Resources planning applica-tion would have the same format and structure as, say, ageographical information system. A KnOS Context can beincluded or excluded without affecting the structure of anyother Context and without any unpredictable or cascadeeffects on the software. A KnOS database is stored, accessedand processed exactly the same wayregardless ofwhat type ofapplication is being implemented. Applications can be builtone Context at a time with only local and best-availableknowledge. Once defined, each Context can be updated as itscontext is expanded and without altering its structure inanyway. COTS software applications can be prepared for anindustry model (or many industry models) and then imple-mented on a case-by-case basis with none ofthe COTSappli-cation issues associated with RDBMSs.

No Frozen Requirements Baselines: The KnOS can beimplemented Item-by-Item, Context-by-Context, andRepository-by-Repository, using any rapid application devel-opment or joint application development technique. Byvirtueofthe KnOS's design, developers do not need to understandthe format ofvalues, the nature of relationships, the overallstructure ofa database, or even the design of the application,to begin developing and delivering software capability. TheKnOS's 100%symmetrical, cellular technology requires nofrozen requirements baseline for development.

No Resistance to Change: In line with no frozen baselinerequirement for implementation, the flexible, incrementalnature ofthe KnOS implies that applications can be continu-ously adjusted for local changes without affecting anythingbeyond the local condition. For example, the equivalent oftable columns can be added or eliminated without repercus-sion while the application is running.

No Need for Structural Reorganization: The underlying

data Repository of the KnOS is not organized intable struc-tures that degrade over time. Insert, edit, and delete activitywithin the KnOS has no impact on the efficiency ofthe KnOSoperation. The Items within a KnOS Context are not inher-ently sequence or cluster dependent; the KnOS Vector Keysare absolute and not sequence-dependent. Consequently, aKnOS implementation never needsto be reloaded or reorga-nized to improve efficiency.

Ability to Fully Normalize: Full normalization is a vastlysuperior method of database management because, amongother things, it eliminates update anomalies and synchroni-zation errors while reducing the amount of data that must beupdated and maintained. Conversely, performance ofthe rela-tional model degrades in inverse proportion to the degree ofnormalization. The more normalized the structure, the worsethe RDBMSwill perform. In contrast, the perfect symmetryin the KnOS design means that performance is directly pro-portional to the degree of normalization. A KnOS ADBMSimplementation performs best when it is fully normalized.

Also, the canonical form ofthe relational model eliminatesvalue redundancy only in non-key attributes with either verylow or very high cardinality. Tabular structures (value-basedrelationships), however much normalized, do not eliminatevalue redundancy. PK values in ASCII format are repeatedthroughout the relational model because value-based foreignkeys are used to record relationships.

Dimensional Independence Elemental Security: TheKnOS inherits complete dimensional independence from itscellular granularity. The KnOS equivalent ofa tabular cell canhave zero, one or many values (0, I, M cardinality). The


41/66


42/66

17US 8,051,102B2

18Drawing 3 is a diagram ofhow an associative relation ofa

relational model would be assimilated into the KnOS.Drawing 4 is a diagram showing how the rows and columns

of a primary and an associative relation from Drawing 1would be assimilated into KnOS Contexts.

Drawing 5 is a diagram that shows the assimilation of allrelationships from the relational model

example depictedin

Drawing 1.Drawing 6 shows the relational model example from

Drawing 1 depicted as a semantic binary data model.Drawing 7 shows how a single segment of the semantic

binary data model would be assimilated into KnOS Contexts.Drawing S is a diagram showing the relational model

depicted in Drawing 1 both as a semantic binary data modeland as a KnOS model.

Drawing 9 is a diagram showing why the KnOS Contextconstruct is application independent.

Drawing 10 is a diagram comparing KnOS operations tothe equivalent relational operations depicted in Drawing 1.

Drawing 11is a diagram showing an example ofthe KnOSpooling operation.

Drawing 12 is a diagram showing a four-dimensional ref-erence model.

Drawing 13 is a diagrammatic representation showing thestructure ofa KnOS Item.

Drawing 14 shows the KnOS's symmetrical referencing.Drawing 15 is a process model showing how the KnOS

ASCII-bet converts ASCII values to their equivalent KnOSVector Key.

Drawing 16 is a diagrammatic representation showing thesix steps to fetching an Item based on the Item's Vector Key.

Drawing 17 is a diagrammatic representation of a Funda-mental Data Structure as a Repository.

Drawing 1S is a diagrammatic representation of a Funda-mental Data Structure as a Context and an Item.

Drawing 19 shows an embodiment ofa method for updat-ing KnOS Items on a physical media.

Drawing 20 shows another embodiment of a method forupdating KnOS Items a physical media.Drawing 21 shows the KnOS architecture to demonstrate

KnOS scalability.Drawing 22 illustrates inter-referencing between Environ-

ments.Drawing 23 shows the comparison between ASCII and

KnOS value representation.Drawing 24 shows the symmetry (or lack thereof'etween

the relational, semantic binary and KnOS data models.Drawing 25 shows the structural symmetry of a KnOS

Item.Drawing 26 depicts the structural symmetry ofKnOS Con-

texts.Drawing 27 illustrates the symmetry ofthe KnOS design.Drawing 2S shows a block diagram ofa typical computing

environment incorporating the KnOS.Drawing 29 illustrates anembodiment using firmware.Drawing 30 shows prior art.

DETAILED DESCRIPTIONSOF THEDRAWINGS

Following is a more detailed description of each drawingand interpretation ofvarious figures.

Drawing 1, Relational Model , shows a Primary relation('tock') whose single Primary Key (PK)attribute is 'Stock',and an Associative relation ('tock-Orders') whose PK is acombination of two Foreign Key (FK) attributes, namely'tock'rom the 'Stock'elation and Order ¹from the 'Order'

10

16

20

26

30

36

40

46

60

66

60

66

relation. Drawing 1 also shows how the Relational Modelwould project, select and join to answer the sample query'what is the total price ofwhite beans on all stock

o rdes r awng

2, Assimilating a 'Primary'Relation , showshow a primary relation in the relational model would beassimilated into the KnOS. Tuples of the 'Stock'rimaryrelation are named 'Pinto Beans', 'Kidney Beans', 'WhiteBeans'nd 'Wax Beans'. The 'Stock'ontext is an exampleofa KnOS Context used to record row relationships. All othercolumns of a primary relation are assimilated asone columnto each KnOS Context, in this case, a Context for 'Stock'nda Context for 'Price'which is a column-like Context).

Drawing 3, Assimilating an Associative Relation , showsthe process depicted in Drawing 2, but for an associativerelation, or one in which the PKs ofthe relation migrate in asa FK from other relations. There is one KnOS Context foreach relational column plus one KnOS Context to representthe tuples of the Stock-Order relation.

Drawing 4, Projection of Rows & Columns to KnOSContexts , illustrates the first step in converting the 'rela-tions'rom Drawing 1 into KnOS Contexts. A KnOS Contextis created for the rows ofthe one associative relation ('tock-Order', and then one KnOS Context is created for eachcolumn ofboth relations, resulting in additional KnOS Con-texts for 'Stock', 'Price', 'Order'nd 'Qty'.

Drawing 5, Assimilation of Relationships to KnOS Con-texts , shows the assimilation into a KnOS model of all therelationships in the relational model example depicted inDrawing 1.

Drawing 6, Semantic Binary Data Model , shows theclassical semantic binary data model for the relational modelshown in Drawing 1.It is similar to the KnOS in that there isone KnOS Context for eachnode ofthe semantic Binary DataModel. Each of the bi-directional relationships is named andthe instances of association (ke.,multiple values) are shownin the upper left.

Drawing 7, Representing Binary Associations as KnOS

Contexts , shows how a single segment of the semanticbinary data model depicted in Drawing 6.The example showsthe relationship between the stock entity and the priceentity. Each element of the relationship associates one valueof the stock entity (e.g., Pinto Beans ) with its matchingvalue from the price entity. The semantic binary data modeldepiction is asymmetric while theKnOS depiction issym-metrical.

Drawing S, Comparison ofData Representations , showsthe raw data from the relational model example in Drawing 1depicted in all three representations relational model,semantic binary data model, and the KnOS.At the bottom isthe ADDS from the relational model. At the left is the samedatabase represented as a semantic binary data model. In theupper right is the KnOS representation of the same raw data(though accurate context is not depicted in the VKSets ).TheKnOS Context canrepresent the data from both a binary datastructure and a tabular structure.

Drawing 9, Application Independence , shows why theKnOS Context is application independent. Adding a newattribute to the 'Stock'elation (a new column) would alter thephysical construct of the 'Stock'ntity in the relationalmodel. With the KnOS Context data architecture, the samechange simply adds more VKSets to the 'Stock'ontext, itdoes not alter the structure of the Item or the Context. TheItem has the same structure before and after the 'Qty'ttributeassociation is added, namely (Vector Key-Data Instance-VK-Sets).

Drawing 10, KnOS Operations , shows how the KnOSconducts core operations with referenced fetches. This


43/66

19US 8,051,102B2

20example is the sameproblem posed on the relational model inDrawing 1.The KnOS would:(I)Determine which stock-orders are for white beans. FetchItem (0,6,1,3) (Data Instance= White Beans ) from the'Stock'ontainer. (2)Extract from Item (0,6,1,3)any VKSetReferences to the 'Stock-Order'ontainer (ke.,Vector Keysof the form

(0,6,3,X)),namely

(0,6,3,1)&

(0,6,3,5).(3) Determine the associated quantities. Fetch Items (0,6,3,1) & (0,6,3,5) from the 'tock Order'ontainer and extractany VKSet References to the 'Qty'ontainer ((0,6,5,X)).The answer is (0,6,5,1)& (0,6,5,3)respectively. Fetch (0,6,5,1)& (0,6,5,3)from the 'Qty'ontainer to get the answers(Data Instances) 1 and 3 ,respectively.(4) Determine the price of white beans Extract from Item(0,6,1,3)(Data Instance= White Beans ) the VKSet Refer-ences to the 'Price'ontainer (ke.,Vector Keys of the form(0,6,2,X)),namely (0,6,2,3).Fetch Item (0,6,2,3)from the'Price'ontainer to get the answer (Data Instance) $13.45 .(5)The KnOS results are extended and summed to get $53.80. Fetch Item (E,R,C,I) is a Referenced fetch because theVector Key (E,R,C,I)is both aunique reference and a KnOSlogical address.

Drawing 11, An Example of Pooling , shows how theKnOS would answer the question 'which Stock-Orders for Pinto Beans have a Qty&=2?'n the 'pooling'peration,relevant Items are fetched from the database and placed intoa 'pool'or a series of direct integer comparisons whosepurpose is to determine the intersection. The first step is tofetch from the 'Qty'ontext all Items whose Data Instance is&=2, and place them into the 'pool'. Next, fetch from the'tock'ontext the Item whose Data Instance= Pinto Beansand place it into the 'pool'. Finally, put the driver elementfrom the 'Stock-Order'ontext, namely (0,6,3,X),into the'pool'. Perform a direct integer compare on the first 3 com-ponents of the (E,R,C,I),in this case (0,6,3,X).The inter-section result from the integer compares, (0,6,3,2)or Stock-Order 2*, is the answer to the question.

Drawing 12, Multi-Dimensional Reference Model ,shows how a given Multi-Dimensional Vector Key, (1,38,1,5) , might be assigned to a real world situation. In the pre-ferred embodiment of the invention, the multi-dimensionalreference model has 4 dimensions. The world view or Envi-ronment might be assigned to countries, as in UnitedStates =¹1.The Repository view might be assigned to pro-cessing sites within countries, as in the New York processingsite =¹38 (within Environment ¹I).The identities ofpersonsmight be assigned to Context ¹1 within (E,R)=(1,38).The Duane Nystrom person might be assigned reference ¹5within (E,R,C)=(1,38,1).The unique multi-dimensionalreference, or Vector Key, for Duane Nystrom would be(1,38,1,5).It is also the logical index used to find theabstracted location of Duane Nystrom ; which Item inwhich Context in which Repository in which Environment(see Drawing 16 for elaboration).

Drawing 13, Structure ofa Item , shows a conceptual anda physical representation of an actual Item. The physicalrepresentation is depicted on the right. The Item isa variablenumber ofwords (each word=32 bits or 4 bytes), shown herein rows of4 words per row. The columns are for ease ofuse inreading the VKSets the first column is the Environmental( E )dimension, the second column the Repository dimen-sion ( R ),the third column the Context ( C )dimension andthe last column represents the Item dimension or Item ( I ).This vector key is abbreviated (E,R,C,I) herein.

Drawing 14, Bi-Directional References , shows a funda-mental property ofthe KnOS. Each explicit reference has anexplicit back reference. Shown here is the reference that

5

10

15

20

25

30

35

40

45

50

55

60

65

Duane Nystrom has Brown hair color. The Brown Itemin the hair color Context also contains an explicit referenceback to Duane Nystrom . The drawing also shows anembedded reference from Duane Nystrom to a phone num-ber. With an embedded reference, there is no back-referenc-ing ability.

Drawing 15, ASCII-betical Conversion , shows how anData Instance, Duane Lewellyn Nystrom, Esq. is convertedto its KnOS Vector Key. The first and second letters are lookedup in an ASCII-bet to determine which Item's Data Instancevalues start with Du . The resulting Items are then pooledwith the Context for persons, (1,38,1,0).This yields an inter-section of two compliant Items. Compare the Data Instancevalues on all compliant Items to get the answer, (1,38,1,5).

Drawing 16, Locating Item (0,6,8,2) on the PhysicalMedia , shows how the KnOS uses the value of the VectorKey ((E,R,C,I))to locate the Item. First, the KnOS retrievesfrom the Repository container the (C,R,N,O)Directory entry(aVector Key format) whose 'C'alue matches the particular(E,R,C,I). In this case, (E,R,C,I)=(0,6,8,2) matchesRepository directory entry (C,R,N,O)=(8,3,1,5),whichgives the location of Context (0,6,8,0)on disk. Next, theKnOS retrieves from the (0,6,8,0)Context the (I,R,N,O)Directory entry (a Vector Key format) whose 'I'aluematches the particular (E,R,C,I).In this case, (E,R,C,I)=(0,6,8,2)matches Context directory entry (I,R,N,O)=(2,3,6,7),which gives the location of Item (0,6,8,2)on disk.

Drawing 17, Repository Structure , is a diagrammaticrepresentation ofa Fundamental Data Structure as aReposi-tory data structure.

Drawing 1S, Context and Item Structure , is a diagram-matic representation ofa Fundamental Data Structure asCon-text and Item data structures.

Drawing 19, Updating Item (0,6,8,2) on the PhysicalMedia I , shows one method ofKnOS update that may beused if the updated Item will not fit back into its previousspace allotment after update. The updated Item is appended tothe end of the Repository file.

Drawing 20, Updating Item (0,6,8,2) on the PhysicalMedia II , is similar to Drawing 19,except that it depictsthe preferred embodiment of physical disk managementunder the KnOS.As with Drawing 1S,Item (0,6,8,2)receivesan update that makes it larger than the 1-page it was currentlyallotted ondisk. In the preferred embodiment, theKnOS hasno space registry. Instead, the KnOS will first move the nextcontainer, in this case (0,6,5,223),to the end of the file,thereby freeing up enough space to return Item (0,6,8,2)to itsoriginal location. Ineffect, Item (0,6,8,2) inherits as addi-tional space that which was previously allocation to(0,6,5,223).

Drawing 21, KnOS Scalability , illustrates how a typicalhigh-end site might be configured as a range of loosely-coupled processing nodes interconnected by a high-speedbus.

Drawing 22, Inter-Referencing Between ComputingEnvironments , illustrates how incorporating multi-dimen-sional Vector Keys in the KnOS enables items in completelydisconnected data systems to be associated across computingenvironment boundaries.

Drawing 23, Value Symmetry , shows how asymmetricalASCII representations are converted to symmetrical KnOSReferences.

Drawing 24, Relationship Symmetry , shows the symme-try, or lack thereof, of the relational, semantic binary andKnOS data models.


44/66

21US 8,051,102B2

22Drawing 25 Structural Symmetry KnOS Items ,

illustrates how an inherently asymmetrical relational modelwould be depicted as symmetric KnOS Items.

Drawing 26 Structural Symmetry KnOS Contexts ,illustrates how KnOS Items are grouped and encapsulated insymmetric KnOS Contexts.

Drawing 27 KnOS Symmetry KnOS Contexts , illus-trates the overall symmetry of the KnOS design values,relationships and structures.

Drawing 2S A block diagram showing the KnOS systemimplemented on a computer with KnOS software operatingon the system.

Drawing 29 A block diagram showing the KnOS systemimplemented on a computer with KnOS software operatingon the system utilizing firmware incorporating data security,license key management, and KnOS Operations accelerator.

Drawing 30 FIG.30 is a diagrammatic representation ofa prior art data base system. It shows the associations ofStock, Qty, and Order with regard to a single Stock Order ina diagrammatical representation. The relative compactness ofthe data model in relational format and associative format canbe seen.

DETAILED DESCRIPTIONOF SOMEEMBODIMENTS OF THE INVENTION

A computing environment is shown inDrawings 2S and 29.While the system can be implemented in a variety of waysincluding on multiple processors, Drawing 2S shows a soft-ware embodiment on a single computer. Drawing 29 is ablock diagram showing the KnOS system implemented on acomputer with KnOS software operating on the system uti-lizing firmware incorporating data security, license key man-agement, and KnOS operations accelerator. While only thesetwo embodiments are shown, it will be well understood bysomeone skilled in the art, that a large variety ofembodimentsusing different hardware configurations can employ theinvention. This specification hereby incorporates by refer-ence prior U.S.applications Ser. Nos. 60/398,843, filed Jul.26, 2002 and 60/457,207, filed Mar. 25, 2003.

To solve the problems outlined previously which are inher-ent in the relational model, the KnOS is structured inverselyto the relational model. In the KnOS, data values lead torelationships. The KnOS's organization rule is &data values-&relationships&, which means that the KnOS is a fullyinverted data model. TheKnOS stores atomic Data Instancesin successively encapsulated Contexts by type classification,and within the storage mechanism for each Data Instance theKnOS stores references, in Vector Key format, to all of theassociations that are relevant to that Data Instance. In KnOSterminology, unique, encapsulated Data Instance values in alike context are called Items. Items are classified by type(context) and encapsulated in Contexts. Contexts are encap-sulated by Repositories and Repositories are encapsulated byEnvironments. All relationships between Data Instances,however complex, are segmented into binary associationsbetween two Items. The associations are then type-classifiedby semantic or other conceptual context by organizing themin to VK Sets and encapsulating them within the associatingItems. In simple terms, the encapsulated members of Envi-ronments are Repositories, the encapsulated members ofRepositories are Contexts, the encapsulated members ofCon-texts are Items, and the encapsulated members of Items areclassified sets of associations w

associative patent

Documents