Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
The instant application having Application No. 19/254,690 has claims 1-20 pending in the application filed on 06/30/2025; there are 2 independent claims and 18 dependent claims, all of which are ready for examination by the examiner.
Information Concerning Oath/Declaration
Oath/Declaration
The applicant’s oath/declaration has been reviewed by the examiner and is found to conform to the requirements prescribed in 37 C.F.R. 1.63.
Status Of Claim for Priority In The Application
This instant application is a continuation of US Application Serial No. 16/211,166 filed December 5, 2018, now patent Number No 12393571 (dated 08/19/2025).
Information Concerning Drawings
Drawings
The applicant’s drawings submitted on 06/30/2025 are accepted for examination purposes.
Acknowledgement Of References Cited By Applicant
As required by M.P.E.P. 609(C), the applicant’s submission of the Information Disclosure Statement dated October 7, 2025 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending. As required by M.P.E.P 609 C (2), copy of the PTOL-1449 initialed and dated by the examiner is attached to the instant office action.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 2,19 and 20 are rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claims 2 and 19
i) As per claims 2 and 19, the claims recite “… for each of the requests to update the element(s), preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s) and for each of the requests to update the element(s), preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the approved tenant(s) having read access to the respective element(s) … “. The two conditions used in the claim limitation are contradictory which are joined by the AND operator and thus will always produce false result. Thus, the claims 2 and 19 are rendered indefinite. The applicant needs to amend the language of the claim limitation to overcome the 35 U.S.C. 112(b) rejection for the claims 2 and 19.
For this office action, Examiner assumes the claim limitation for the claims 2 and 19 to be “… for each of the requests to update the element(s), preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s) or for each of the requests to update the element(s), preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the approved tenant(s) having read access to the respective element(s) … “.
The dependent claim 20 is also rejected as it is dependent on the parent claim 19.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-6, 9-13 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Nesmyanovich et al (US PGPUB 20110219046) in view of Srivastava, Kumar S (US PGPUB 20180196851).
As per claim 1:
Nesmyanovich teaches:
“A method of operating a multidimensional multitenant system, said method comprising” (Paragraph [0003] (a method for a plurality of tenants (multitenant), with each data set comprising a plurality of data elements (multidimensional) and the method comprises))
“storing metadata describing tenants, said metadata associating each of the tenants with a set of users” (Paragraph [0021] (the foundation layer also includes the shared core metadata for the database where the common core objects are shared among tenants (metadata describing tenants) and the common core data elements will typically encompass at least basic personal information about a tenant's clients (tenant’s set of users)))
“receiving requests from users to create objects, each of the requests originating from a respective user associated with a respective one of the tenants of a respective one of the plurality of tenant types” (Paragraph [0041] and Fig. 4 (the method maintains, for a plurality of tenants, a plurality of translation maps, which use the shared metadata where each translation map corresponds to a particular tenant (a respective one of the tenants of a respective one of the plurality of tenant types), a system implementing the method receives data sets, such as the legacy table (receiving requests from users to create objects), from one of the tenants and the legacy table comprises a plurality of data elements relating to a client of the tenant (respective user associated with a respective one of the tenants) from whom the data set originated))
“and each specifying elements and additional, approved one or ones of the tenants ("approved tenant(s)") such that each of the elements is associated with one or more of the approved tenant(s)” (Paragraph [0031] (within the RDBMS, each tenant's objects are logically separated from other tenants' objects and the data elements corresponding to the attributes of the industry-specific objects and the tenant-specific objects being stored in the tenant tables accessible only by the tenant (approved one or ones of the tenants ("approved tenant(s)")) with whom that tenant table is associated))
“each of the approved tenant(s) is associated with a specified access type for the respective element” (Paragraph [0041] (the tenant-related data elements are stored in at least one tenant-specific table that is accessible only by the tenant (is associated with a specified access type for the respective element) with whom the tenant-related data elements originated))
“and each of the elements is associated with only one of the approved tenant(s) of a given one of the tenant types such that the elements of the objects, collectively, are associated with approved tenant(s) of different tenant type” (Paragraph [0035] (in the exemplary metadata attribute information table a value "2" denotes a tenant-related attribute corresponding to Tenant 1, and the value "3" denotes a tenant-related attribute corresponding to Tenant 2., although only the domain_id, attribute name and data type are shown in the exemplary metadata attribute table for ease of illustration, but the metadata attribute information table in accordance with an aspect of the present invention may contain information about all data elements etc. and keeps all logical associations between tenants and their objects and maintains secure separation of the data elements corresponding to each tenant (are associated with approved tenant(s) of different tenant type)))
“creating the objects and updating the metadata according to the requests” (Paragraph [0040] (when the tenant administrator is creating an extended attribute, the system creates a new record in the metadata attribute table, identified by the tenant domain_id attribute and also adds a new column to the object extension table in the tenant schema))
“receiving requests to update the elements of the objects, and for each of the requests, updating the respective element(s) and metadata according to the respective request” (Paragraph [0036] and Paragraph [0041] (receiving and storing data for multiple tenants in a single system and each tenant's data can be modified independently from that of any other tenants because the system uses metadata to support a dedicated set of tenant-specific tables for each tenant))
“receiving requests to access the elements of the objects, and for each of the requests, providing access to the respective element(s) according to the respective request” (Paragraph [0031] and Paragraph [0041] (receives request for accessing data sets, such as the legacy table from one of the tenants, the data elements corresponding to the attributes of the industry-specific objects and the tenant-specific objects being stored in the tenant tables accessible only by the tenant with whom that tenant table is associated)).
Nesmyanovich does not EXPLICITLY disclose: metadata associating each of the tenants with one of a plurality of tenant types; wherein the access types comprise read access and read/write access; after determining that the respective request originates from one of users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having read/write access to the respective element(s); after determining that the respective request originates from one of the users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having any of: read and read/write access to the respective element(s).
However, in an analogous art, Srivastava teaches:
“metadata associating each of the tenants with one of a plurality of tenant types” (Paragraph [0019] (the data tenants are associated with metadata stored in the tenant info store which includes data tenant identifiers, data tenant types, data tenant roles, and other configuration information related to the data tenant))
“wherein the access types comprise read access and read/write access” (Paragraph [0013] (a data tenant is an account controlled by a user or entity with certain permissions where these permissions can allow modification, addition, deletion, or access to specific data stores))
“after determining that the respective request originates from one of users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having read/write access to the respective element(s)” (Paragraph [0019] and Paragraph [0020] (the data tenants of the dataset management system are associated with metadata stored in the tenant info store which includes data tenant identifiers, data tenant types, data tenant roles, and other configuration information related to the data tenant (approved tenant(s) for the respective element(s)) that may be used to define data tenants' permissions and access to data stores and the data stored in the tenant data store can be added and modified (read/write access) by the data tenant))
“after determining that the respective request originates from one of the users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having any of: read and read/write access to the respective element(s)” (Paragraph [0019] and Paragraph [0020] (the data tenants of the dataset management system are associated with metadata stored in the tenant info store which includes data tenant identifiers, data tenant types, data tenant roles, and other configuration information related to the data tenant (approved tenant(s) for the respective element(s)) that may be used to define data tenants' permissions and access to data stores and the data stored in the tenant data store can be added and modified (having any of: read and read/write access) by the data tenant)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to take the teachings of Srivastava and apply them on teachings of Nesmyanovich for the method “metadata associating each of the tenants with one of a plurality of tenant types; wherein the access types comprise read access and read/write access; after determining that the respective request originates from one of users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having read/write access to the respective element(s); after determining that the respective request originates from one of the users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having any of: read and read/write access to the respective element(s)”. One would be motivated as the dataset management system stores metadata associated with data tenants where the metadata includes the data tenant types, roles, and identifiers and the data tenant information may be modified, added, or deleted via configuration requests received by the dataset management system (Srivastava, Paragraph [0014]).
As per claim 3:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 1 above.
Nesmyanovich further teaches:
“the metadata describing the tenants is stored at a first table” (Paragraph [0034] (a single metadata attribute information table, which is part of the shared metadata stores information about each tenant data model, logically separated by the domain_id attribute)).
Also, Srivastava further teaches:
“the tenant type for each of the users is determined from the first table” (Paragraph [0014] (the dataset management system stores metadata associated with data tenants and it includes the data tenant type)).
As per claim 4:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 3 above.
Nesmyanovich further teaches:
“information regarding the approved tenants for the objects is stored at a second table” (Paragraph [0031] (each tenant's objects are logically separated from other tenants' objects, with the data elements corresponding to the attributes of the common core objects being stored in the core table(s))).
As per claim 5:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 4 above.
Nesmyanovich further teaches:
“updating the second table as the requests to update one or more of the elements are approved” (Paragraph [0031] (each tenant's data can be modified independently from that of any other tenants because the system uses metadata to support a dedicated set of tenant-specific tables for each tenant)).
As per claim 6:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 5 above.
Srivastava further teaches:
“the second table comprises information regarding the access types, whereby each of the approved tenants is associated with one of the access types” (Paragraph [0013] and Paragraph [0014] (the dataset management system stores metadata associated with data tenants where a data tenant is an account on the dataset management system controlled by a user or entity with certain permissions which can allow modification, addition, deletion, or access (access types) to specific data stores)).
As per claim 9:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 1 above.
Nesmyanovich further teaches:
“at least some of the elements comprise multiple data points” (Paragraph [0041] (a method for receiving and storing data for multiple tenants in a single system)).
As per claim 10:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 1 above.
Nesmyanovich further teaches:
“the approved tenants having read access include the tenants contributing to the element” (Paragraph [0031] (the data elements corresponding to the attributes of the industry-specific objects and the tenant-specific objects being stored in the tenant tables accessible only by the tenant with whom that tenant table is associated)).
As per claim 11:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 1 above.
Nesmyanovich further teaches:
“the access types further comprise no access, controller access, and unrestricted access, wherein only one of the approved tenants is associated with the controller access for a given element of a given object” (Paragraph [0035] and Paragraph [0036] (a metadata attribute information table will contain information about all data elements, its data types, relationship between hierarchy levels, storage attributes, security access etc. and the tenants do not access data in the tenant-specific customer tables or the core tables directly to maintain proper data manipulation and security so that each tenant has access only to its own data and is restricted from accessing other tenants' data)).
As per claim 12:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 1 above.
Nesmyanovich further teaches:
“for each of the elements, at most one tenant of a given tenant type is provided with read/write access” (Paragraph [0031] (the tenant-specific objects being stored in the tenant tables accessible only by the tenant with whom that tenant table is associated)).
As per claim 13:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 1 above.
Nesmyanovich further teaches:
“creating a new object by performing one or more of joining, unionizing, or intersecting two or more of the objects” (Paragraph [0037] (even within the same industry, different tenants may have different unique needs, depending upon the details of their operation, where the tenant's tenant schema which is a clone of the industry-specific schema template is modified (by performing one or more of joining, unionizing, or intersecting two or more of the objects) to more effectively meet that particular tenant's needs, without affecting the data model as used by other tenants))
“and carrying over access rules from the two or more of the objects to the new object” (Paragraph [0021] (the common core objects are shared among tenants in the sense that the data elements corresponding to the attributes of the core objects are stored in a common format and all tenants will have access to the table or tables containing the data elements corresponding to the attributes of the common core objects; however tenants will only have access to their own data elements and not to the data elements of other tenants (carrying over access rules from the two or more of the objects))).
As per claim 17:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 1 above.
Nesmyanovich further teaches:
“A non-transitory computer readable non-transitory storage medium storing instructions thereon, the instructions when executed by a processor cause the processor to perform the method” (Paragraph [0054] (the invention can take the form of a computer program product accessible from a computer usable or computer readable medium providing program code for use by or in connection with a computer or any instruction execution system)).
As per claim 18:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 1 above.
Nesmyanovich further teaches:
“A computer system, comprising” (Paragraph [0003] (receiving and storing data for multiple tenants in a single system comprises))
“a computer processor” (Paragraph [0003] (maintaining, in a database system executing in memory by a processor of a computer))
“and a non-transitory computer readable non-transitory storage medium storing instructions thereon, the instructions when executed by a processor cause the processor to perform the method” (Paragraph [0054] (the invention can take the form of a computer program product accessible from a computer usable or computer readable medium providing program code for use by or in connection with a computer or any instruction execution system)).
Claims 2 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Nesmyanovich et al (US PGPUB 20110219046) in view of Srivastava, Kumar S (US PGPUB 20180196851) and in further view of Bahrenburg et al (US PGPUB 20210226788).
As per claim 2:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 1 above.
Nesmyanovich further teaches:
“for each of the requests to update the element(s), preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s)” (Paragraph [0036] and Paragraph [0041] (a set of methods is used to maintain proper data manipulation and security, so that each tenant has access only to its own data and is restricted from accessing other tenants' data (preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s))).
Also, Srivastava further teaches:
“or for each of the requests to update the element(s), preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the approved tenant(s) having read access to the respective element(s)” (Paragraph [0013] (a data tenant is an account on the dataset management system controlled by a user or entity with certain permissions where these permissions can allow modification, addition, deletion, or access to specific data stores))
“for each of the requests to update the element(s), updating the element(s) according to the respective request after determining that the respective request originates from any one of the users of any one of the approved tenant(s) for the respective element(s) having write access to the respective element(s)” (Paragraph [0013] (a data tenant is an account on the dataset management system controlled by a user or entity with certain permissions where these permissions can allow modification to specific data stores))
“for each of the requests to access the element(s), providing access to the element(s) according to the respective request after determining that the respective request originates from any one of the users of any one of the approved tenant(s) for the respective element(s) having any of: read and read/write access to the respective element” (Paragraph [0013] (a data tenant is an account on the dataset management system controlled by a user or entity with certain permissions where these permissions can allow access to specific data stores))
“and preventing, on an element by element, read and write access to all of the users associated with a respective tenant of a respective tenant type different from the tenant type of the respective tenant associated with the respective element” (Paragraph [0019] (the data tenants of the dataset management system are associated with metadata stored in the tenant info store which includes data tenant identifiers, data tenant types, and other configuration information related to the data tenant and the data stored in the tenant info store (respective data tenant types) may be used to define data tenants' permissions and access to data stores)).
Nesmyanovich and Srivastava do not explicitly teach: EXPLICITLY disclose: “for each of the requests to access the element(s), preventing access to the element(s) of the objects, after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s).
However, in an analogous art, Bahrenburg teaches:
“for each of the requests to access the element(s), preventing access to the element(s) of the objects, after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s)” (Paragraph [0044] and Paragraph [0047] (each of the tenants may access permissions information in the registry to verify that an authenticated tenant is a trusted tenant (approved tenant, a trusted tenant is a tenant that is authorized to access data of the target tenant and tenants that are not identified as trusted tenants are not authorized to access data of the corresponding tenant)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to take the teachings of Bahrenburg and apply them on teachings of Nesmyanovich and Srivastava for the method “for each of the requests to access the element(s), preventing access to the element(s) of the objects, after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s)”. One would be motivated as the set of permissions may indicate a set of trusted tenants that is trusted by the corresponding tenant, each of the trusted tenants may be represented within the registry by a corresponding tenant identifier, in addition, for each tenant in the set of trusted tenants, the registry may indicate a set of contexts that are trusted and the registry may indicate, for each of the trusted tenants, data that is accessible from the target tenant (Bahrenburg, Paragraph [0041]).
As per claim 19:
Nesmyanovich teaches:
“A method of operating a multidimensional multitenant system, said method comprising” (Paragraph [0003] (a method for a plurality of tenants (multitenant), with each data set comprising a plurality of data elements (multidimensional) and the method comprises))
“storing metadata describing tenants, said metadata associating each of the tenants with a set of users” (Paragraph [0021] (the foundation layer also includes the shared core metadata for the database where the common core objects are shared among tenants (metadata describing tenants) and the common core data elements will typically encompass at least basic personal information about a tenant's clients (tenant’s set of users)))
“receiving requests from users to create objects, each of the requests originating from a respective user associated with a respective one of the tenants of a respective one of the plurality of tenant types” (Paragraph [0041] and Fig. 4 (the method maintains, for a plurality of tenants, a plurality of translation maps, which use the shared metadata where each translation map corresponds to a particular tenant (a respective one of the tenants of a respective one of the plurality of tenant types), a system implementing the method receives data sets, such as the legacy table (receiving requests from users to create objects), from one of the tenants and the legacy table comprises a plurality of data elements relating to a client of the tenant (respective user associated with a respective one of the tenants) from whom the data set originated))
“and each specifying elements and additional, approved one or ones of the tenants ("approved tenant(s)") such that each of the elements is associated with one or more of the approved tenant(s)” (Paragraph [0031] (within the RDBMS, each tenant's objects are logically separated from other tenants' objects and the data elements corresponding to the attributes of the industry-specific objects and the tenant-specific objects being stored in the tenant tables accessible only by the tenant (approved one or ones of the tenants ("approved tenant(s)")) with whom that tenant table is associated))
“each of the approved tenant(s) is associated with a specified access type for the respective element” (Paragraph [0041] (the tenant-related data elements are stored in at least one tenant-specific table that is accessible only by the tenant (is associated with a specified access type for the respective element) with whom the tenant-related data elements originated))
“and each of the elements is associated with only one of the approved tenant(s) of a given one of the tenant types such that the elements of the objects, collectively, are associated with approved tenant(s) of different tenant type” (Paragraph [0035] (in the exemplary metadata attribute information table a value "2" denotes a tenant-related attribute corresponding to Tenant 1, and the value "3" denotes a tenant-related attribute corresponding to Tenant 2., although only the domain_id, attribute name and data type are shown in the exemplary metadata attribute table for ease of illustration, but the metadata attribute information table in accordance with an aspect of the present invention may contain information about all data elements etc. and keeps all logical associations between tenants and their objects and maintains secure separation of the data elements corresponding to each tenant (are associated with approved tenant(s) of different tenant type)))
“creating the objects and updating the metadata according to the requests” (Paragraph [0040] (when the tenant administrator is creating an extended attribute, the system creates a new record in the metadata attribute table, identified by the tenant domain_id attribute and also adds a new column to the object extension table in the tenant schema))
“receiving requests to update the elements of the objects, and for each of the requests, updating the respective element(s) and metadata according to the respective request” (Paragraph [0036] and Paragraph [0041] (receiving and storing data for multiple tenants in a single system and each tenant's data can be modified independently from that of any other tenants because the system uses metadata to support a dedicated set of tenant-specific tables for each tenant))
“receiving requests to access the elements of the objects, and for each of the requests, providing access to the respective element(s) according to the respective request” (Paragraph [0031] and Paragraph [0041] (receives request for accessing data sets, such as the legacy table from one of the tenants, the data elements corresponding to the attributes of the industry-specific objects and the tenant-specific objects being stored in the tenant tables accessible only by the tenant with whom that tenant table is associated))
“for each of the requests to update the element(s), preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s)” (Paragraph [0036] and Paragraph [0041] (a set of methods is used to maintain proper data manipulation and security, so that each tenant has access only to its own data and is restricted from accessing other tenants' data (preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s))).
Nesmyanovich does not EXPLICITLY disclose: metadata associating each of the tenants with one of a plurality of tenant types; wherein the access types comprise read access and read/write access; after determining that the respective request originates from one of users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having read/write access to the respective element(s); after determining that the respective request originates from one of the users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having any of: read and read/write access to the respective element(s); or for each of the requests to update the element(s), preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the approved tenant(s) having read access to the respective element(s); for each of the requests to access the element(s), preventing access to the element(s) of the objects, after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s); for each of the requests to update the element(s), updating the element(s) according to the respective request after determining that the respective request originates from any one of the users of any one of the approved tenant(s) for the respective element(s) having write access to the respective element(s); for each of the requests to access the element(s), providing access to the element(s) according to the respective request after determining that the respective request originates from any one of the users of any one of the approved tenant(s) for the respective element(s) having any of: read and read/write access to the respective element; and preventing, on an element by element, read and write access to all of the users associated with a respective tenant of a respective tenant type different from the tenant type of the respective tenant associated with the respective element.
However, in an analogous art, Srivastava teaches:
“metadata associating each of the tenants with one of a plurality of tenant types” (Paragraph [0019] (the data tenants are associated with metadata stored in the tenant info store which includes data tenant identifiers, data tenant types, data tenant roles, and other configuration information related to the data tenant))
“wherein the access types comprise read access and read/write access” (Paragraph [0013] (a data tenant is an account controlled by a user or entity with certain permissions where these permissions can allow modification, addition, deletion, or access to specific data stores))
“after determining that the respective request originates from one of users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having read/write access to the respective element(s)” (Paragraph [0019] and Paragraph [0020] (the data tenants of the dataset management system are associated with metadata stored in the tenant info store which includes data tenant identifiers, data tenant types, data tenant roles, and other configuration information related to the data tenant (approved tenant(s) for the respective element(s)) that may be used to define data tenants' permissions and access to data stores and the data stored in the tenant data store can be added and modified (read/write access) by the data tenant))
“after determining that the respective request originates from one of the users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having any of: read and read/write access to the respective element(s)” (Paragraph [0019] and Paragraph [0020] (the data tenants of the dataset management system are associated with metadata stored in the tenant info store which includes data tenant identifiers, data tenant types, data tenant roles, and other configuration information related to the data tenant (approved tenant(s) for the respective element(s)) that may be used to define data tenants' permissions and access to data stores and the data stored in the tenant data store can be added and modified (having any of: read and read/write access) by the data tenant))
“or for each of the requests to update the element(s), preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the approved tenant(s) having read access to the respective element(s)” (Paragraph [0013] (a data tenant is an account on the dataset management system controlled by a user or entity with certain permissions where these permissions can allow modification, addition, deletion, or access to specific data stores))
“for each of the requests to update the element(s), updating the element(s) according to the respective request after determining that the respective request originates from any one of the users of any one of the approved tenant(s) for the respective element(s) having write access to the respective element(s)” (Paragraph [0013] (a data tenant is an account on the dataset management system controlled by a user or entity with certain permissions where these permissions can allow modification to specific data stores))
“for each of the requests to access the element(s), providing access to the element(s) according to the respective request after determining that the respective request originates from any one of the users of any one of the approved tenant(s) for the respective element(s) having any of: read and read/write access to the respective element” (Paragraph [0013] (a data tenant is an account on the dataset management system controlled by a user or entity with certain permissions where these permissions can allow access to specific data stores))
“and preventing, on an element by element, read and write access to all of the users associated with a respective tenant of a respective tenant type different from the tenant type of the respective tenant associated with the respective element” (Paragraph [0019] (the data tenants of the dataset management system are associated with metadata stored in the tenant info store which includes data tenant identifiers, data tenant types, and other configuration information related to the data tenant and the data stored in the tenant info store (respective data tenant types) may be used to define data tenants' permissions and access to data stores)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to take the teachings of Srivastava and apply them on teachings of Nesmyanovich for the method “metadata associating each of the tenants with one of a plurality of tenant types; wherein the access types comprise read access and read/write access; after determining that the respective request originates from one of users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having read/write access to the respective element(s); after determining that the respective request originates from one of the users associated with, according to the metadata, one of the approved tenant(s) for the respective element(s) having any of: read and read/write access to the respective element(s); or for each of the requests to update the element(s), preventing updates to the element(s) after determining that the respective request originates from: one of the users of one of the approved tenant(s) having read access to the respective element(s); for each of the requests to update the element(s), updating the element(s) according to the respective request after determining that the respective request originates from any one of the users of any one of the approved tenant(s) for the respective element(s) having write access to the respective element(s); for each of the requests to access the element(s), providing access to the element(s) according to the respective request after determining that the respective request originates from any one of the users of any one of the approved tenant(s) for the respective element(s) having any of: read and read/write access to the respective element; and preventing, on an element by element, read and write access to all of the users associated with a respective tenant of a respective tenant type different from the tenant type of the respective tenant associated with the respective element”. One would be motivated as the dataset management system stores metadata associated with data tenants where the metadata includes the data tenant types, roles, and identifiers and the data tenant information may be modified, added, or deleted via configuration requests received by the dataset management system (Srivastava, Paragraph [0014]).
Nesmyanovich and Srivastava do not explicitly teach: EXPLICITLY disclose: “for each of the requests to access the element(s), preventing access to the element(s) of the objects, after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s).
However, in an analogous art, Bahrenburg teaches:
“for each of the requests to access the element(s), preventing access to the element(s) of the objects, after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s)” (Paragraph [0044] and Paragraph [0047] (each of the tenants may access permissions information in the registry to verify that an authenticated tenant is a trusted tenant (approved tenant, a trusted tenant is a tenant that is authorized to access data of the target tenant and tenants that are not identified as trusted tenants are not authorized to access data of the corresponding tenant)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to take the teachings of Bahrenburg and apply them on teachings of Nesmyanovich and Srivastava for the method “for each of the requests to access the element(s), preventing access to the element(s) of the objects, after determining that the respective request originates from: one of the users of one of the tenants other than the approved tenant(s) for the respective element(s)”. One would be motivated as the set of permissions may indicate a set of trusted tenants that is trusted by the corresponding tenant, each of the trusted tenants may be represented within the registry by a corresponding tenant identifier, in addition, for each tenant in the set of trusted tenants, the registry may indicate a set of contexts that are trusted and the registry may indicate, for each of the trusted tenants, data that is accessible from the target tenant (Bahrenburg, Paragraph [0041]).
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Nesmyanovich et al (US PGPUB 20110219046) in view of Srivastava, Kumar S (US PGPUB 20180196851) and in further view of Szeto et al (US PGPUB 20190286832).
As per claim 7:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 6 above.
Nesmyanovich and Srivastava do not EXPLICITLY disclose: the second table comprises presaved ratification status values for each of the approved tenants; the decision to update, not update, allow access to, and deny access to the elements is made in accordance with a retrieved presaved ratification status value for the respective user for the respective request from the table, including such that responsive to a ratification status value indicting a vetoed status from any of the approved tenants, denying access to the element(s) associated with a receptive request.
However, in an analogous art, Szeto teaches:
“the second table comprises presaved ratification status values for each of the approved tenants” (Paragraph [0014] (after receiving approvals (ratification status) from the authorized user(s), the system may generate a profile for the user for granting permission and accessing the data objects for each tenant in the multi-tenant data store))
“the decision to update, not update, allow access to, and deny access to the elements is made in accordance with a retrieved presaved ratification status value for the respective user for the respective request from the table, including such that responsive to a ratification status value indicting a vetoed status from any of the approved tenants, denying access to the element(s) associated with a receptive request” (Paragraph [0014] and Paragraph [0043] (the access control system may identify approvers in charge of granting or denying access to the data objects, and may forward the request to these authorized approvers, the approvers may send the approvals to the system based on the requests and if the approver rejects the access request, the requesting user may not be granted access to the requested data objects)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to take the teachings of Szeto and apply them on teachings of Nesmyanovich and Srivastava for the method “the second table comprises presaved ratification status values for each of the approved tenants; the decision to update, not update, allow access to, and deny access to the elements is made in accordance with a retrieved presaved ratification status value for the respective user for the respective request from the table, including such that responsive to a ratification status value indicting a vetoed status from any of the approved tenants, denying access to the element(s) associated with a receptive request”. One would be motivated as a user working in a multi-tenant environment may desire to update on data within the multi-tenant environment may enable an enhanced experience for customers and additional users (Szeto, Paragraph [0004]).
As per claim 8:
Nesmyanovich, Srivastava and Szeto teach the method as specified in the parent claim 7 above.
Szeto further teaches:
“the ratification status values are selected from a plurality of ratification status values comprising pending, ratified, and vetoed, further comprising” (Paragraph [0014] (if the data objects correspond to more than one tenant, the request may be sent to an authorized user for each tenant, where each tenant can approve or deny access to the corresponding requested data object(s)))
“responsive to a ratification status value indicting a pending status, waiting for the ratification status value for the tenant to change” (Paragraph [0074] and Paragraph [0091] (may receive an approval message that indicates granted access to data objects that are stored in the multi-tenant data store, may determine one or more approval users associated with data objects and the access control server may receive an approval message that indicates granted access (ratification status value) to data objects that are stored in the multi-tenant data store)).
Claims 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Nesmyanovich et al (US PGPUB 20110219046) in view of Srivastava, Kumar S (US PGPUB 20180196851) and in further view of Agrawal et al (US PGPUB 20110302212).
As per claim 14:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 13 above.
Nesmyanovich and Srivastava do not EXPLICITLY disclose: allowing creation of the new object in spite of violating normal rules if the new object represents a temporary result that is not exposed to any tenant.
However, in an analogous art, Agrawal further teaches:
“allowing creation of the new object in spite of violating normal rules if the new object represents a temporary result that is not exposed to any tenant” (Paragraph [0027] (the operations analyzer may also analyze system and custom validation rules relating to the object before the object can be saved and made available to tenant where the system validation rules are universal to all of the tenants in the multi-tenant database system or other databases)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to take the teachings of Agrawal and apply them on teachings of Nesmyanovich and Srivastava for the method “allowing creation of the new object in spite of violating normal rules if the new object represents a temporary result that is not exposed to any tenant”. One would be motivated as the operations analyzer can determine an amount of time or processing power used to perform the actions and can analyze the performance or efficiency of the CRUD operations (Agarwal, Paragraph [0034]).
As per claim 15:
Nesmyanovich, Srivastava and Agarwal teach the method as specified in the parent claim 14 above.
Agrawal further teaches:
“causing creation of the new object to fail if any of the normal rules is violated and if the new object represents a temporary result that is exposed to any tenant” (Paragraph [0029] (the operations analyzer validates the object to determine which rules are affecting the object and are violated and the operation is failed as an unexpected action is triggered and error is generated to the tenant or user)).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable Nesmyanovich et al (US PGPUB 20110219046) in view of Srivastava, Kumar S (US PGPUB 20180196851) and in further view of Ensey et al (US PGPUB 20180181720).
As per claim 16:
Nesmyanovich and Srivastava teach the method as specified in the parent claim 1 above.
Nesmyanovich and Srivastava do not EXPLICITLY disclose: the tenant types comprise providers, patients, and insurers.
However, in an analogous art, Ensey further teaches:
“the tenant types comprise providers, patients, and insurers” (Paragraph [0116] and Paragraph [0133] (the clinical decision support (CDS) system including the rules engine, the CDS applications, population health applications, partner applications, CDS user experience (UX), a CDS multi-tenant platform, the batch flow is provided via a cloud-based application to service multiple tenants such as hospitals, ambulatory care centers, insurers, billing etc.)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to take the teachings of Ensey and apply them on teachings of Nesmyanovich and Srivastava for “the tenant types comprise providers, patients, and insurers”. One would be motivated as it provides systems and methods to facilitate clinical problem and guideline-based clinical care through problem-oriented organization of clinical information, care plans, pathways, and goals (Ensey, Paragraph [0037]).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Nesmyanovich et al (US PGPUB 20110219046) in view of Srivastava, Kumar S (US PGPUB 20180196851) and in further view of Bahrenburg et al (US PGPUB 20210226788), Szeto et al (US PGPUB 20190286832) and Agrawal et al (US PGPUB 20110302212).
As per claim 20:
Nesmyanovich, Srivastava and Bahrenburg teach the method as specified in the parent claim 19 above.
Nesmyanovich further teaches:
“the metadata describing the tenants is stored at a first table” (Paragraph [0034] (a single metadata attribute information table, which is part of the shared metadata stores information about each tenant data model, logically separated by the domain_id attribute))
“information regarding the approved tenants for the objects is stored at a second table” (Paragraph [0031] (each tenant's objects are logically separated from other tenants' objects, with the data elements corresponding to the attributes of the common core objects being stored in the core table(s)))
“the second table is updated as the requests to update one or more of the elements are approved” (Paragraph [0031] (each tenant's data can be modified independently from that of any other tenants because the system uses metadata to support a dedicated set of tenant-specific tables for each tenant))
“at least some of the elements comprise multiple data points” (Paragraph [0041] (a method for receiving and storing data for multiple tenants in a single system))
“the approved tenants having read access include the tenants contributing to the element” (Paragraph [0031] (the data elements corresponding to the attributes of the industry-specific objects and the tenant-specific objects being stored in the tenant tables accessible only by the tenant with whom that tenant table is associated)).
“the access types further comprise no access, controller access, and unrestricted access, wherein only one of the approved tenants is associated with the controller access for a given element of a given object” (Paragraph [0035] and Paragraph [0036] (a metadata attribute information table will contain information about all data elements, its data types, relationship between hierarchy levels, storage attributes, security access etc. and the tenants do not access data in the tenant-specific customer tables or the core tables directly to maintain proper data manipulation and security so that each tenant has access only to its own data and is restricted from accessing other tenants' data))
“for each of the elements, at most one tenant of a given tenant type is provided with read/write access” (Paragraph [0031] (the tenant-specific objects being stored in the tenant tables accessible only by the tenant with whom that tenant table is associated))
“and further comprising: creating a new object by performing one or more of joining, unionizing, or intersecting two or more of the objects” (Paragraph [0037] (even within the same industry, different tenants may have different unique needs, depending upon the details of their operation, where the tenant's tenant schema which is a clone of the industry-specific schema template is modified (by performing one or more of joining, unionizing, or intersecting two or more of the objects) to more effectively meet that particular tenant's needs, without affecting the data model as used by other tenants))
“and carrying over access rules from the two or more of the objects to the new object” (Paragraph [0021] (the common core objects are shared among tenants in the sense that the data elements corresponding to the attributes of the core objects are stored in a common format and all tenants will have access to the table or tables containing the data elements corresponding to the attributes of the common core objects; however tenants will only have access to their own data elements and not to the data elements of other tenants (carrying over access rules from the two or more of the objects))).
Also, Srivastava further teaches:
“the tenant type for each of the users is determined from the first table” (Paragraph [0014] (the dataset management system stores metadata associated with data tenants and it includes the data tenant type))
“the second table comprises information regarding the access types, whereby each of the approved tenants is associated with one of the access types” (Paragraph [0013] and Paragraph [0014] (the dataset management system stores metadata associated with data tenants where a data tenant is an account on the dataset management system controlled by a user or entity with certain permissions which can allow modification, addition, deletion, or access (access types) to specific data stores)).
Nesmyanovich, Srivastava and Bahrenburg do not EXPLICITLY disclose: the second table comprises presaved ratification status values for each of the approved tenants; the decision to update, not update, allow access to, and deny access to the elements is made in accordance with a retrieved presaved ratification status value for the respective user for the respective request from the table, including such that responsive to a ratification status value indicting a vetoed status from any of the approved tenants, denying access to the element(s) associated with a receptive request; the ratification status values are selected from a plurality of ratification status values comprising pending, ratified, and vetoed, further comprising; responsive to a ratification status value indicting a pending status, waiting for the ratification status value for the tenant to change; allowing creation of the new object in spite of violating normal rules if the new object represents a temporary result that is not exposed to any tenant; causing creation of the new object to fail if any of the normal rules is violated and if the new object represents a temporary result that is exposed to any tenant.
However, in an analogous art, Szeto teaches:
“the second table comprises presaved ratification status values for each of the approved tenants” (Paragraph [0014] (after receiving approvals (ratification status) from the authorized user(s), the system may generate a profile for the user for granting permission and accessing the data objects for each tenant in the multi-tenant data store))
“the decision to update, not update, allow access to, and deny access to the elements is made in accordance with a retrieved presaved ratification status value for the respective user for the respective request from the table, including such that responsive to a ratification status value indicting a vetoed status from any of the approved tenants, denying access to the element(s) associated with a receptive request” (Paragraph [0014] and Paragraph [0043] (the access control system may identify approvers in charge of granting or denying access to the data objects, and may forward the request to these authorized approvers, the approvers may send the approvals to the system based on the requests and if the approver rejects the access request, the requesting user may not be granted access to the requested data objects))
“the ratification status values are selected from a plurality of ratification status values comprising pending, ratified, and vetoed, further comprising” (Paragraph [0014] (if the data objects correspond to more than one tenant, the request may be sent to an authorized user for each tenant, where each tenant can approve or deny access to the corresponding requested data object(s)))
“responsive to a ratification status value indicting a pending status, waiting for the ratification status value for the tenant to change” (Paragraph [0074] and Paragraph [0091] (may receive an approval message that indicates granted access to data objects that are stored in the multi-tenant data store, may determine one or more approval users associated with data objects and the access control server may receive an approval message that indicates granted access (ratification status value) to data objects that are stored in the multi-tenant data store)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to take the teachings of Szeto and apply them on teachings of Nesmyanovich, Srivastava and Bahrenburg for the method “the second table comprises presaved ratification status values for each of the approved tenants; the decision to update, not update, allow access to, and deny access to the elements is made in accordance with a retrieved presaved ratification status value for the respective user for the respective request from the table, including such that responsive to a ratification status value indicting a vetoed status from any of the approved tenants, denying access to the element(s) associated with a receptive request; the ratification status values are selected from a plurality of ratification status values comprising pending, ratified, and vetoed, further comprising; responsive to a ratification status value indicting a pending status, waiting for the ratification status value for the tenant to change”. One would be motivated as a user working in a multi-tenant environment may desire to update on data within the multi-tenant environment may enable an enhanced experience for customers and additional users (Szeto, Paragraph [0004]).
Nesmyanovich, Srivastava, Bahrenburg and Szeto do not EXPLICITLY disclose: allowing creation of the new object in spite of violating normal rules if the new object represents a temporary result that is not exposed to any tenant; causing creation of the new object to fail if any of the normal rules is violated and if the new object represents a temporary result that is exposed to any tenant.
However, in an analogous art, Agrawal further teaches:
“allowing creation of the new object in spite of violating normal rules if the new object represents a temporary result that is not exposed to any tenant” (Paragraph [0027] (the operations analyzer may also analyze system and custom validation rules relating to the object before the object can be saved and made available to tenant where the system validation rules are universal to all of the tenants in the multi-tenant database system or other databases))
It would have been obvious to one of ordinary skill in the art before the effective filing date to take the teachings of Agrawal and apply them on teachings of Nesmyanovich, Srivastava, Bahrenburg and Szeto for the method “allowing creation of the new object in spite of violating normal rules if the new object represents a temporary result that is not exposed to any tenant”. One would be motivated as the operations analyzer can determine an amount of time or processing power used to perform the actions and can analyze the performance or efficiency of the CRUD operations (Agarwal, Paragraph [0034]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Levine et al, (US PGPUB 20190095532), Disclosed are examples of systems, apparatus, methods and computer program products for providing run-time querying of multi-tenant non-relational database objects. A database system maintains a multi-tenant non-relational database associated with a number of enterprises, a number of records, and a number of data objects for each of the enterprises, each data object having at least one composite key field. A request is received during runtime to query data related to a data object, and the system determines that the data object is defined to be used in associated with a non-relational database. The system then retrieves a metadata model of the data object, determines that the request includes at least one composite key field for the data object, and processes the requery to query data in synchronous fashion.
Mandelstein et al, (US PGPUB 20130238641), A method, computer program product and system for managing tenant-specific data sets in a multi-tenant system, by receiving a request to convert a data set in a physical data store from a first type of multi-tenant deployment to a second type of multi-tenant deployment, retrieving tenant identification metadata identifying a tenant making the request, modifying the data set in the physical data store based on the second type of multi-tenant deployment.
Mathrubootham et al, (US PGPUB 20130031496), Methods and systems are provided for associating objects in a database. An exemplary method involves identifying one or more objects in the database that are likely to be related to a first object in the database that is based on data obtained from a local application associated with a user and displaying the identified objects on a client device associated with the user. In exemplary embodiments, the identified objects are displayed in response to selection of a graphical user interface element enabling indication of a second object from among the one or more objects, wherein the first object is associated with the second object in the database after receiving indication of the second object.
Efendiyev et al, (US PGPUB 20190236297), , a method of verifying a multi-factor administrator action may be performed. The method may include receiving, from a first user, an authentication request that indicates a requested access, where the first user has administrative privileges to perform the requested access. The method may further include identifying a second user that has administrative privileges to approve the requested access. A verification request may be to the second user. In response to receiving an approval message from the second user within a particular amount of time, an authentication response that indicates that the first user is authorized to perform the requested access..
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KAMAL K DEWAN whose telephone number is (571) 272-2196. The examiner can normally be reached on Mon-Fri 8:00 AM – 5:00 PM (EST). If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, TONY MAHMOUDI can be reached on 571-272-4078. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Kamal K Dewan/
Examiner, Art Unit 2163
/TONY MAHMOUDI/Supervisory Patent Examiner, Art Unit 2163
Prosecution Insights