Source: http://www.google.com/patents/US7853961?dq=6462713
Timestamp: 2017-10-19 08:07:01
Document Index: 696435362

Matched Legal Cases: ['Application No. 200610004388', 'Application No. 200610004388', 'Application No. 417', 'Application No. 417', 'Application No. 200610004388', 'Application No. 200610004388', 'Application No. 200610004388', 'Application No. 72', 'Application No. 06101151', 'Application No. 06101151', 'Application No. 544991', 'Application No. 544991', 'Application No. 173430', 'Application No. 1']

Patent US7853961 - Platform for data services across disparate application frameworks - Google Patents
Data management between a common data store and multiple applications of multiple disparate application frameworks. A data storage component is provided that facilitates the storage of data, which data includes structured, semi-structured, and unstructured data. A common data platform interfaces to the...http://www.google.com/patents/US7853961?utm_source=gb-gplus-sharePatent US7853961 - Platform for data services across disparate application frameworks
Publication number US7853961 B2
Application number US 11/171,905
Also published as CA2533942A1, CN1828527A, CN1828527B, EP1696352A2, EP1696352A3, US20060195476
Publication number 11171905, 171905, US 7853961 B2, US 7853961B2, US-B2-7853961, US7853961 B2, US7853961B2
Inventors Anil Kumar Nori, Sameet H. Agarwal, Jose A. Blakeley, Pedro Celis, Praveen Seshadri, Soner Terek, Arthur T. Whitten, Dale Woodford
Patent Citations (80), Non-Patent Citations (40), Referenced by (31), Classifications (9), Legal Events (3)
Platform for data services across disparate application frameworks
US 7853961 B2
a. Relational data modeling and access.
b. Rich object abstraction and programming environment.
c. Semi-structured data modeling via XML storage and querying.
d. Unstructured data as files.
2. Flexible organization—the capability to organize arbitrary collections of objects and not statically, as a table.
a. Support for file system namespace and organization.
3. Rich query/Search—the capability to query all data.
a. Support for rich querying (e.g., SQL, OSQL (object-oriented SQL), XML Querying, C# Sequences). OSQL is a functional language that is a superset of SQL.
4. Rich behaviors—support for rich data behaviors. This is not a replacement for application/business process logic.
5. Flexible administration—administration at different granularities (e.g., item level operations such as copy, move, and serialize).
6. Data Synchronization—peer-to-peer and master-slave synchronization of arbitrary collections of data.
7. Sharing—the capability to share data across multiple applications and multiple application frameworks. For example, sharing Contacts across Outlook and CRM applications.
8. Schemas—rich, out-of-the-box schemas for user and ISV (Independent Support Vendor) applications to facilitate collaboration with each other.
9. Flexible Deployment—deployable in two- and three-tier environments.
The CDP and associated architecture enables all the benefits described above. Key innovations include a layered architecture, a common data model that factors out the modeling concepts common across multiple application frameworks, and a CDP component (functional) architecture.
1) Some of the components shown in FIG. 4 are “mobile” in the sense that they can live in different processes/Tiers. Specifically, the Constraints/Security engine 112 typically lives in the store process 202 of FIG. 2.
2) Not all components shown in FIG. 4 need to be implemented in order to have a fully functioning data platform. Specifically, the Object Cache 414 can consist of just a session cache. In another implementation, the cache 414 can include an explicit cache which will be synchronized with the store. The query processor 406 operates over objects in the object cache 414.
Several features and/or components of the CDP are described in more detail hereafter. As stated supra, at the center of the CDP is a common data model (CDM) 402, wherein the intent of the CDM 402 is to factor out the modeling concepts common across multiple application domains, from applications working mainly with user data (e.g., PIM, documents, etc.) to LOB and enterprise data. In general, there are two possible techniques that can be utilized to implement such functionality: 1) Model concepts specific to every conceivable (or conceivably important) domain. For instance, define precisely what a “Customer” means (from LOB domain) and what a “Person” means (from user domain) and so on; and 2) Provide a flexible base over which application designers may create their own, domain specific types, constraints, relationships. The CDM 402 utilizes the second approach such that it provides a basic set of types and defines a flexible framework for authoring new types. In this sense, the CDM 402 can be both a data model (e.g., it actually defines certain types and their semantics) and also a data meta-model (e.g., it allows specification of other models).
<EntityType Name=“Customer” Key=“CustomerId”>
<Property Name=“CustomerId” Type=“String” Nullable=“false”>
<Length Minimum=“10” Maximum=“10”/>
<Property Name=“Name” Type=“String” Nullable=“false”>
<Length Maximum=“200”/>
<Property Name=“Addresses” Type=“Array(Address)”>
<Occurs Minumum=“1” Maximum=“3”/>
<NavigationProperty Name=“Orders” Association=“OrderCustomer”
The entity (except the table set) can be contained within a table based at least in part because table sets are the top level organizational unit and a table set is composed of tables. Within a table scope, each entity can have a unique key value. At store-wide scope, each entity can have a unique identity—its key value concatenated with its table's identity, recursively. The entity can be the smallest unit in the CDM 402 referenceable by key and/or identity. The storage operations can target the entity, wherein the operations can be, but are not limited to persist, store, move, copy, delete, rename, backup, restore, etc. The inline type instance can be used in the context of the containing entity. CDM 402 can define the concept of an abstract entity type, which are substantially similar to abstract classes in the CLR. In other words, they cannot be instantiated directly; they can only be derived from to create other instantiable types.
1. API Generator. The application designer designs CDM types and relationships using CSDL and uses a design-time CDP tool called APIG (pronounced ay-pig), which generates partial CLR classes corresponding to these types and relationships. The APIG-generated classes are available as assemblies to application programmers and can be referenced by their application programs with the C# using clause. The classes generated by APIG are, in a sense, canonical classes; they can be a direct representation of the CDM types within an application program. In one example, application classes can be constrained in their definition—such as, for instance, when the application is using classes from a pre-written class library (graphics package, math package, etc.). The application can use the object persistence framework of CDP to durably persist and query for instances of these classes in the store. Such objects can be referred to as Plain Old CLR Objects, or POCO. CDP supports POCO scenarios as well.
2. Object-relational mapping. This component of the CSDL helps application designers declare concrete, non-prescriptive mappings between store concepts such as tables and views, and CLR classes. It can also specify how a constraint defined in terms of the CDM 402 could be mapped to a SQL declarative constraint, a trigger or stored procedure.
3. Behaviors. The CSDL enables application designers determine what portion of the business logic is implemented as instance methods, as static functions, as stored procedures. It also determines the tier where the logic may run (e.g., CDP runtime vs. store).
The programming surface can further include a CDP API, wherein programming surface applications can be written against. The CDP API can have three subparts:
1. Generic CDP data access. This is the portion of the API that exposes stores, sessions, transactions (e.g., StorageContext), query services (e.g., StorageSearcher), and CRUD services (e.g., SaveChanges).
2. CDM data classes. This is the set of canonical, application-independent classes exposing CDM concepts such as Entity, Relationship, Extension, etc.
3. Domain data classes. These are application/framework-specific classes such as Contact, Message, PurchaseOrderes that conform to the CDM 402 but expose domain-specific properties and behaviors.
CDM 402 can also define a query language, the CQL. CQL is designed to allow rich queries against the object structures that the programmer works with. The following are three identified techniques utilized for the basis of the CQL formalism:
1. OPath: The OPath language has its roots in SQL and XPath and was designed to be a CLR-object version of XPath. The design builds on the XPath concept of path expressions to expose a method of dereferencing properties of objects in sequence. The design is based on one simple principle: developers expect to see collections of objects as the primary “structural” construct in an object oriented API. OPath can be the POR query formalism for a database-based file storage system.
2. Object SQL: This approach extends the SQL query language to manipulate graphs and collections of CDM objects. Windows Query Language (WinQL), a variation of SQL designed to query and manipulate graphs of CLR objects, is a candidate design for the extensions needed in SQL.
3. C# Sequence Operators: This is a set of C# extensions for strongly typed, compile-time checked query and set operations that can be applied to a broad class of transient or persistent collections of CLR objects (e.g., via Object-Relational mappings
Strategically, the C# Sequence Operators approach makes the most sense for becoming the framework for CQL. CQL is a query language. Creates, updates, deletes are performed as object operations (new, property setters, etc.). The O-R mapping component within the persistence engine 408 can map these operations to underlying DML operations in SQL.
1. Schema Space: The description of the type in a CDM schema. These are abstract types in the sense that they may not explicitly be materialized within any component of the runtime stack (e.g., from the application all the way down to the store).
2. Application Space: The representation of the types as CLR classes within the CDP API. There can be a 1-1 correspondence between entity/inline types in the schema space and the data classes in the application space. In other words, each entity and inline type in the CDM schema can result in a CLR class. Often, these classes are automatically generated by APIG; however, in the POCO case, the developer can explicitly specify a mapping between CLR classes and types in the schema space. The application space can also contain relationship classes in addition to classes for entity and inline types.
3. Storage Space: The persistence format of the type in the underlying store. If the store is a relational store, then these types are tables/UDT/core SQL types. The O-R mapping component of CDP supports a mapping schema that allows types in the schema space to be mapped to the types in the storage space (e.g., the Purchase Order entity type could be mapped to the PurchaseOrder table in SQL Server).
The CDP query language targets the application space. This makes sense because a developer wants to query using the substantially similar abstractions that they use for other operations (e.g., objects and collections). However, the semantics of CQL are described using CDM abstractions (the schema space).
1. Frameworks: A framework uses extensibility mechanisms provided by the CDP in order to customize CDP for a particular domain. A framework adds value to CDP with type specializations and additional services. However, the programming model exposed to the application is the CDP programming model; in particular, applications still use data classes, StorageContext, StorageSearcher, and the CQL. A database-based file storage system can be an example of a framework on top of CDP which is customized for user data domain.
2. Vertical Platforms: A separate layer on top of CDP with its own APIs, abstractions, and data model. It hides the CDP and exposes an entirely different programming model to the applications. For example, an application utilized in conjunction with email can use CDP, but expose Email Object Model for its users.
3. “Regular” Applications: Just a CDP application meant to accomplish a specific set of tasks. It does not specialize any CDP type, or expose a programming model, or use any framework or a vertical platform.
Vertical Platforms and “Regular” Applications are just code; they can use CDP any way they want without passion or prejudice. Frameworks are a little different; since they add value to CDP without hiding it from the application, they can adhere to the following rules:
1. The framework data model is identical to the CDM, or is a simple, well documented specialization of the CDM. It may define new types, but these types are ultimate-supertyped by Entity.
2. The framework may define additional constraints on existing CDM types and/or author new constraints using the CSDL. In other words, constraints must be expressed by using the CDM methodology for constraint definitions.
3. Frameworks usually do not expose their own query language; even if they do, it can be in addition to, not instead of, CQL.
4. Frameworks usually do not expose their own programming model; even if they do, it can be in addition to, not instead of, CDP API.
5. Frameworks provide additional specialized services on top of the CDP. These services may be implemented as CDP business logic or as additional helper classes and methods.
It is to be appreciated and understood that all of the above rules are intended to ensure that the data saved into CDP by a given framework can be accessible to all applications regardless of whether an application is using this framework or not.
The application uses its own types, and puts its types in a separate namespace and creates private assemblies for the data classes resulting from those types. Since all CDP level access to the instance data belonging to this schema is through these assemblies, other applications will not have access to the corresponding classes.
The application creates its own private CDP store (e.g., a set of entities in CDP over which a StorageContext can be created) whose name is not published to other applications.
Through the use of documentation.
It is to be appreciated that applications can choose some or all of the above methods to have private data.
1) It may not have access to CDP services (or any services built by a framework on top of CDP).
2) Specifically, it does not have the benefit of the CDM—so it has to figure out the tabular representation and issue queries/updates directly at this level.
Note the following consequences for application 1:
1) The business logic in the BL service(s) is effectively bypassed by application 2.
2) Some constraints—e.g., those that are not implemented as Triggers/DRI (declarative referential integrity) are also bypassed by application 2.
In this particular deployment, it is the responsibility of the application designers and/or deployment administrators to make sure that application 2 has its own logic to enforce constraints, etc. so that the right thing happens.
1. Application level remoting via web services: in this scenario, the application logic resides on the middle tier and is exposed to the client as remoted static methods. This is discussed in detail infra.
2. Implicit CDP-service call remoting: CDP API calls such as FindAll( ), FindOne( ), SaveChanges( ) are sent to the middle tier implicitly via the remoting agent and remoting service components. This architecture is described infra. Moreover, the subsequent sections have examples that describe how this works.
3. Explicit, disconnected remoting: CDP API defines a programming pattern whereby the application explicitly defines when the tier-crossing operations should happen. If this operation resulted in data retrieval, then the retrieved data is cached on the client tier. This pattern is usually referred to as the “disconnected mode” (discussed infra).
In particular, FIG. 14 and FIG. 15 illustrate the application logic running on the middle-tier (e.g., a Web service). The primary scenario for mid-tier deployment is the case where application logic runs exclusively in the middle tier; the client 1406 invokes this logic through a web service mechanism (e.g., the web service proxy 1408 and web service 1410). It is to be appreciated that the security engine on the server tier can be hosted in the middle tier CDP process. In a 2-tier deployment, the CDP calls are processed by the CDP runtime 1402 within the client process; the runtime contacts the server when necessary. In a 3-tier deployment, some CDP calls are processed locally (via client tier) and some are processed remotely (via middle tier). Moreover, still others can be processed in both places. A 3-tier deployment defines a methodology for remoting the appropriate calls.
1. The client uses the local CDP runtime to query for store entities. The queries are executed on the mid-tier.
2. The query results are in the client tier CDP's session cache.
The entire “application logic”—including business logic, validation, etc.—are run on the middle tier by the web service and by CDP's BL hosting engine. This processing is triggered by a call to the CreateAppointment( ) method. The following is a detailed examination of the data flow between/across various modules.
1. Raw TDS results are returned from the Middle Tier to the Client Tier without hydrating the objects. The CDP runtime 1402 on the client tier then hydrates the objects.
2. If these objects already exist in the object cache 414, hydrated objects are returned to the Client Tier
1. BL is run both on the client tier and on the mid tier: In this case, the Business Logic Host 416 on the client tier runs the validation and pre-save logic and calls the remoting agent 1414 on the client tier with IPersist.Write(<change vector>). The remoting agent 1414 sends the call to the remoting service 1416 (as seen in FIG. 17) on the Middle Tier. The remoting service 1416 dirties the object cache 414 on the Middle Tier and calls SaveChanges( ). This runs the BL and persistence steps as describe before and returns to the remoting service 1416, wherein the remoting service 1416 then returns to the remoting agent 1414 on the Client Tier, which in turn returns back to the business logic hosting 416. Client side post-save logic may not run by the business logic hosting 416.
2. BL is run only on the mid-tier. In this case, the business logic hosting 416 immediately passes the call to the remoting agent 1414 which in turn sends it to the remote service 1416. Processing happens on the mid-tier as described above.
An advantage of running BL on both tiers is that in case of errors in validation of pre-save logic, they can be trapped on the client tier without having to go through the expense of connecting to the mid-tier.
Tier crossing is potentially expensive and hence may not happen implicitly: there is no explicit indication in line 2 that this will result in a tier crossing operation—in other words, “magic” is involved. “Magic” is used here in the sense that something happens without the application knowing about it or having the ability to control its occurrence. Many times, magic is good; in fact, it is the goal of a lot of software to hide the underlying complexity and make things happen “as if by magic”. However, in this particular case, long experience has shown that application writers send huge queries willy-nilly, assuming that the code underneath somehow returns a lot of data without choking the network or stressing the server. It is a proven design paradigm that any tier crossing magic be made explicit to the application, thereby encouraging judicious coding practices (is “select * needed from <million-row-table>” or perhaps a WHERE clause can be employed).
Client Side Caching and stateless operation: Notwithstanding attempts at judicious coding, there are times when the application needs to work with a (potentially large) data set; frequently, it knows what this data set is. To optimize data access in such cases, the application should have the ability to run the query, fetch the (potentially large) data set and house it locally in the cache. Further queries/sorting/filtering/changes are made to the local copy of the data. Finally a flush operation writes the changes back to the store. Working on the local cache means that the mid-tier maintains very minimal (or no) state, thus making it more scalable.
The solution is to provide an explicit disconnected model. This is characterized by the following pattern:
LocalContext lc=new LocalContext( );
2. The local cache will contain the results of one or more queries, specified as the following:
lc.QueryCollection.Add(“<query1>”);
lc.QueryCollection.Add(“<query2>”);
3. The application “fills” the local context
lc.Fill( );
4. It works on the local context just like it would with any storage context. For example:
lc.Entities.FilterByType<ScheduleEntry>( ).Filter(
“StartTime>@0”, new DateTime(
2004, 10, 29, 9, 0, 0)).GetFirst( );
s.DisplayName =s.DisplayName+“[important, please come!]”;
5. Finally, it sends changes en masse to the store, specified as the following:
// sc is the StorageContext
lc.SaveChanges(sc);
Notice how the application can be explicit in when it wants a tier crossing operation to occur—the lc.Fill( ) in step 3—so that there is no magic triggered by innocent code. Notice also that all subsequent operations can occur on the local cache and hence tier crossing is minimized (along with the concomitant maintenance of state on the mid-tier). It is to be appreciated that the model implied by code fragments above are quite similar to the dataset model in ADO.NET. CDP can also provide a disconnected model.
new StorageContext@\\corp001\defaultstore))
The following addresses naming of a CDP store and discovery of available stores. A CDP store is defined more clearly. There are two possibilities:
1. It is the actual, physical store—database on an actual server.
2. It is the logical store—the argument to the ctor identifies a logical container of entity instances. In reality, this could be deployed as a farm of replicated physical stores and a front end server works with a load balancer to pick the actual physical store that forms the context for this particular session.
In the CDP model, a storage context identifies a logical store, not a physical store. CDP does not specify how the replication, backup/restore mechanisms work at the level of the physical store.
Watcher/Notification Services
Explicit Cache Services
This section should be considered descriptive, not architectural.
1) Schema annotation for change tracking. Schema designers may designate change unit boundaries for their entity types. Change unit specifications control the functioning of the Change Tracking service.
2) Change Tracking. Largely invisible to applications, it maintains versions for change units during all CDP operations, as well as logs of critical operations such as entity deletions. Change Tracking functions correctly even if legacy applications continue to make changes bypassing the CDP runtime.
3) Change Enumeration. Allows a CDP application to retrieve the set of entities and their change units that have been modified since a certain watermark. The changes are returned as CDP entities and RowSets. A set of services is provided for watermark maintenance in the face of failures, backups and restores, and complex synchronization topologies.
4) Conflict Detection. Allows a CDP application to determine whether a CDP operation (such as an update) will conflict with the operations that have already been performed (again, based on a watermark).
Cache different types of data (e.g., entities, unstructured, and XML data)
Different cache access modes (e.g., Read Only, Read Write, Shared, etc.)
Cache coherency with the stored data (e.g., for data stored in SQL Server)
Cache (certain type of data, e.g., session context data) coherency across multiple CDP caches for application failover
Creation of caches;
population of caches
Persisting caches (of part of data) to the underlying stores
Query and update over cached data
Utility Operations. CDP provide support for variety of administrative and utility operations on entities and collections of entities. A sampling of such operations includes: Copy, Move, Serialize/De-serialize, and Backup/Restore.
Base Item type (and related types)
Actual types for modeling user data
Constraints such as lifetime management, containment, etc.
Things a user can do with items: Move, Copy, Rename, Serialize . . .
Organizational constructs for Items: containers, lists, autolist, annotations, categories
End user programming abstractions over items (such as rules authoring)
It is to be appreciated and understood that for application developers, CDP is the UAF programming model.
1. O-R mapping—mapping of entities to tables. CDP supports non-prescriptive mappings to handle POCO scenarios and database-based file storage system server scenarios. This also includes update mapping, providing basic CUD operations against entity (and derived) types.
2. OPath query mapping
3. Implementation of Entity and other CDM core types
4. StorageContext and StorageSearcher, along with session and transaction management
5. Session cache, cache flush logic (SaveChanges)
6. Change Tracking
7. Watchers on entity types
8. Cursor services, including RAV
9. Item level security enforcement mechanisms (row level security, security predicates includes in type views)
The following capabilities in a database-based file storage system belong in the UAF layer:
1. Bindable, per-instance behavior
2. Database-based file storage system API metadata (client classes and behaviors expressed as CLR metadata)
3. Item level methods (Copy, move, serialize, rename)
4. Sync, sync scopes, change enumeration
5. Watchers on containers
6. Path table for efficient path name computation and item domains
7. Metadata handlers
8. Database-based file storage system namespace
9. Code for enforcing item integrity (container, item parts, links, file streams, lifetime management, etc.).
FIG. 20 illustrates an example of a LOB application being implemented over the CDP. Below, the LOB framework requirements are described and how they can be supported by the CDP. A business framework application can be considered a LOB application. The core feature set for business applications is packages as shared business components. Groups of these components manage different business functions such as general ledger in financials to sales force automation services in CRM. The key feature is that these components are faceless, extensible, and can be utilized to serve the needs of multiple markets depending on what level of functionality and complexity is utilized.
Entity create, read, update and delete
Ad hoc queries that return a DataSet
Set-based operations that execute in the database
BF prescribes an agent/service framework for supporting distributed, service-oriented configurations. Given some piece of business functionality, the agent runs as near to the user of the functionality as possible and the service runs as near to the data as possible. “As close as possible” differs with each deployment scenario and kind of user. The agent/service pattern provides deployment flexibility from 2-tier (client-server) to multi-tier deployment. In such deployments, services provide interfaces that can be invoked across service boundaries; agents typically fetch data close to the client (user), operate it on it, and propagate changes to the service.
US5449293 Jun 2, 1992 Sep 12, 1995 Alberta Research Council Recognition training system
US6836777 Nov 14, 2002 Dec 28, 2004 Ncr Corporation System and method for constructing generic analytical database applications
US7058655 Jan 11, 2002 Jun 6, 2006 Sun Microsystems, Inc. Determining object graph and object graph projection
US20020107840 Dec 1, 2000 Aug 8, 2002 Rishe Naphtali David Database querying system and method
US20030004964 Nov 26, 2001 Jan 2, 2003 Kim Cameron Dynamically generating multiple hierarchies of inter-object relationships based on object attribute values
US20030005019 Jun 27, 2001 Jan 2, 2003 Kuldipsingh Pabla Application frameworks for mobile devices
US20030140058 Feb 25, 2002 Jul 24, 2003 Vitria Technology, Inc. Method and apparatus for sharing information between applications using common objects
US20030217128 May 15, 2002 Nov 20, 2003 Motorola, Inc. QOS framework system
US20040015474 Jul 22, 2002 Jan 22, 2004 Anonsen Steven P. Database simulation of data types
US20040015488 Jul 20, 2002 Jan 22, 2004 Anonsen Steven P. Containment hierarchy in a database system
US20040015509 Jul 20, 2002 Jan 22, 2004 Anonsen Steven P. Map and data location provider
US20050027675 May 27, 2004 Feb 3, 2005 Winfried Schmitt Systems and methods for data processing
US20050027720 May 27, 2004 Feb 3, 2005 Winfried Schmitt Systems and methods for data processing
US20050097187 Oct 10, 2003 May 5, 2005 Oracle International Corporation Object relational mapping layer
US20050138052 Feb 26, 2004 Jun 23, 2005 International Business Machines Corporation Method, computer program product, and system converting relational data into hierarchical data structure based upon tagging trees
US20060184568 Feb 15, 2005 Aug 17, 2006 International Business Machines Corporation Having a single set of object relational mappings across different instances of the same schemas
US20060195477 Aug 2, 2005 Aug 31, 2006 Microsoft Corporation Storage API for a common data platform
US20070266041 Aug 29, 2006 Nov 15, 2007 Microsoft Corporation Concept of relationshipsets in entity data model (edm)
EP001457907A Title not available
EP1457907A1 Mar 11, 2004 Sep 15, 2004 Microsoft Corporation Software model of business process
WO2002099702A Title not available
WO2002099702A1 Jun 3, 2002 Dec 12, 2002 Thought, Inc. System, method and software for creating, maintaining, navigating or manipulating complex data objects and their data relationships
WO2004095312A1 Apr 22, 2004 Nov 4, 2004 Wolfgang Flatow A universal database schema
WO2004107205A1 May 26, 2004 Dec 9, 2004 Sap Ag Data processing system and method for application programs in a data warehouse
WO2004107206A1 May 26, 2004 Dec 9, 2004 Sap Ag A data processing method and system
1 "DB Interface Module User;s Guide" (2005) Rogue Wave, Section 7.4 https://www2.rougewave.com/support/docs/sourcepro/edition8/htm:/dcoore/7-4.html 12 pages.
2 Acharya, et al., Discovering and Using Web Services in M-Commerce, SCE Computer Networking, University of Missouri-Kansas City, 2004, pp. 136-151, Springer-Verlag Berlin Heidelberg 2005.
3 Ambler, S., "Mapping Objects to Relational Databases: O/R Mapping in Detail," (2002), downloaded from http://www.agiledata.org/essays/mappingObjects.html on Oct. 5, 2005 (31 pages).
4 Australian Patent Office Search Report dated Apr. 27, 2007 for Australian Patent Application Serial No. SG 200508626-9, 3 Pages.
5 Bernes-Lee, T., Fielding, R., and Masinter, L. "Uniform Resource Identifiers (URI) : Generic Syntax" The Internet Society, Aug. 1998, 40 pages.
6 Blakely. "Data Access for the Masses through OLE DB" ACM 1996, pp. 161-172.
7 Chen, et al. "Turning Relational DBMS into Nested Relational DBMS" (2005) 12 pages.
8 Chen. "The Entity-Relationship Model-Towards a Unified View of Data" ACM Transactions on Database Systems, vol. 1, Issue 1, Mar. 1976, pp. 9-36.
9 Chen. "The Entity-Relationship Model—Towards a Unified View of Data" ACM Transactions on Database Systems, vol. 1, Issue 1, Mar. 1976, pp. 9-36.
10 Chinese OA dated May 15, 2009 for CN Application No. 200610004388.8, 8 pages.
11 Chinese OA dated Nov. 27, 2009 for CN Application No. 200610004388.8, 8 pages.
12 CiteSeer. evidence for Chen reference, 2004.
13 CLOA due Nov. 11, 2008 for Chilean Patent Application No. 417-2006, 3 pages.
14 CLOA due Oct. 6, 2009 for Chilean Patent Application No. 417-2006, 4 pages.
15 CN OA dated Aug. 15, 2008 for CN Application No. 200610004388.8, 9 pages.
16 CN OA dispatched May 15, 2009 for CN Application No. 200610004388.8, with English translation, 7 pages.
17 CN OA dispatched Nov. 27, 2009 for CN Application No. 200610004388.8, with English translation, 7 pages.
18 Davis, et al., Understanding Services for Integration Management, Department of Mathematical and Computer Sciences, The University of Tulsa, pp. 84-93, Springer-Verlag Berlin Heidelberg 2004.
19 Distibuted Management Task Force DMTF: "CIM Database Model White Paper" CIM Version 2.8, Nov. 3, 2003, pp. 1-56, retrieved from http://web.archive.org/web/20040414223542/www.dmtf.org/standards/ published-documents/DSP0133.pdf, last accessed on Jun. 21, 2006.
20 Distibuted Management Task Force DMTF: "CIM Database Model White Paper" CIM Version 2.8, Nov. 3, 2003, pp. 1-56, retrieved from http://web.archive.org/web/20040414223542/www.dmtf.org/standards/ published—documents/DSP0133.pdf, last accessed on Jun. 21, 2006.
21 EG OA dated Feb. 11, 2009 for EG Application No. 72/2006, 1 page.
22 EPOA dated Aug. 17, 2009 for European Patent Application No. 06101151.6, 4 pages.
23 EPOA dated Oct. 30, 2007 for European Patent Application No. 06101151.6, 5 pages.
24 European Search Report dated Apr. 11, 2007 for European Patent Application Serial No. EP 06 10 1151, 2 Pages.
25 European Search Report dated Jul. 6, 2006 for European Patent Application Serial No. EP 06 10 1024, 3 pages.
26 European Search Report dated Mar. 21, 2007 for European Patent Application Serial No. EP 06 10 0768, 2 Pages.
27 European Search Report for European Patent Application No. EP 06 10 0768 dated Mar. 22, 2007, 10 pgs.
28 Examination Report dated Dec. 20, 2006 for New Zealand Patent Application No. 544991, 2 pages.
29 Examination Report dated Feb. 7, 2006 for New Zealand Patent Application No. 544991, 2 pages.
30 Gwyn Cole, et al. "A Guided Tour of the Common Information Model Repository", Jan. 10, 2003, 16 pages, retrieved from http://www.informit.com/articles//printerfriendly.asp?p=30482&rl=1>, last accessed on Jun. 21, 2006.
31 Israeli Office Action for IL Patent Application No. 173430 dated Mar. 10, 2010, 7 pages.
32 Mittal, et al., A Framework for eGovernace Solutions, Sep./Nov. 2004, vol. 48, 17 pages International Business Machines Corporation.
33 OA Dated Aug. 1, 2008 for U.S. Appl. No. 11/550,574, 30 pages.
34 OA dated Dec. 10, 2008 for U.S. Appl. No. 11/468,008, 43 pages.
35 PHOA for Phillipines Patent Application No. 1-2006-000129, 1 page.
36 Site Deck: Product Overview, Copyright 2002-2003 William. (2 pages).
37 Svirskas, A., et al., "An Approach for Solving Java Object Persistence Issues using RDBMS and other Data Sources," Proceedings of the Fifth Eastern European Conference on Advances in Databases and Information Systems (ADBIS 2001), Sep. 25-28, 2001, Vilnius Lithuania (15 pages).
38 U.S. Appl. No. 10/646,575, filed Aug. 21, 2003.
39 Ware, S., et al., "O/R Mapped Object Persistence is the Boon," Feb. 8, 2005, published on the Internet by internet.com, Foster City, CA, downloaded from <http://www.15seconds.com/issue/020805.htm> on Oct. 5, 2005 (13 pages).
40 Ware, S., et al., "O/R Mapped Object Persistence is the Boon," Feb. 8, 2005, published on the Internet by internet.com, Foster City, CA, downloaded from on Oct. 5, 2005 (13 pages).
US8245281 * Dec 28, 2007 Aug 14, 2012 Aruba Networks, Inc. Method and apparatus for policy-based network access control with arbitrary network access control frameworks
US8726299 * Sep 26, 2007 May 13, 2014 Symantec Operating Corporation Image-oriented, plugin-based API to storage server appliances
US8862607 * Jan 24, 2012 Oct 14, 2014 Kabushiki Kaisha Toshiba Content receiving apparatus with search query generator
US8972334 Dec 21, 2012 Mar 3, 2015 International Business Machines Corporation Transparent data service suitable for modifying data storage capabilities in applications
US9122734 Sep 16, 2013 Sep 1, 2015 International Business Machines Corporation Transparent data service suitable for modifying data storage capabilities in applications
US20080306986 * Mar 19, 2008 Dec 11, 2008 Accenture Global Services Gmbh Migration of Legacy Applications
US20120179703 * Jan 24, 2012 Jul 12, 2012 Kabushiki Kaisha Toshiba Receiving apparatus
CN103019845A * Dec 10, 2012 Apr 3, 2013 中国人民解放军理工大学 Method for zero-modification migration of application program under heterogeneous database platforms
CN103019845B * Dec 10, 2012 Jun 3, 2015 中国人民解放军理工大学 Method for zero-modification migration of application program under heterogeneous database platforms
WO2012128878A2 * Feb 21, 2012 Sep 27, 2012 International Business Machines Corporation Shared data management in software-as-a-service platform
WO2012128878A3 * Feb 21, 2012 Apr 17, 2014 International Business Machines Corporation Shared data management in software-as-a-service platform
U.S. Classification 719/328, 707/610
International Classification G06F17/00, G06N99/00, G06F9/44
Cooperative Classification G06F17/30607, G06F17/30569
European Classification G06F17/30S8T, G06F17/30S5V
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NORI, ANIL KUMAR;AGARWAL, SAMEET H.;BLAKELEY, JOSE A.;AND OTHERS;REEL/FRAME:016533/0557;SIGNING DATES FROM 20050629 TO 20050805
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NORI, ANIL KUMAR;AGARWAL, SAMEET H.;BLAKELEY, JOSE A.;AND OTHERS;SIGNING DATES FROM 20050629 TO 20050805;REEL/FRAME:016533/0557