DETAILED ACTION
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 .
Response to Arguments
Applicant's arguments filed 10/29/2025 have been fully considered
35 USC § 103:
Regarding Applicant’s Argument (pages: 11-12): Examiner’s response:- Applicant’s arguments, with respect to the rejection(s) of under 35 USC § 102/103 have been fully considered. However, upon further consideration, a new ground(s) of rejection is made in view of US 20200327140 A1; Khillar; Shiv Prasad et al. (hereinafter Khillar). The examiner recommends further elaborating on "metadatabase set having a mapping relation " in the independent claims. The examiner believes amendments directed towards parameters/factors involved in the metadatabase will help push over the current prior art and push the application towards allowance. If the applicant would like further guidance for overcoming the prior art(s), please call the examiner at 571-272-5212.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4,11,14-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20110022642 A1; deMilo; David et al. (hereinafter Demilo) in view of US 20200327140 A1; Khillar; Shiv Prasad et al. (hereinafter Khillar).
Regarding claim 1, Demilo teaches A metadata management method, performed by a server, and comprising: receiving an account authentication request transmitted by a client, the account authentication request carrying cloud account information; (Demilo [FIG.1] shows corresponding flow for the client tenant system with corresponding request/metadata file/set transmitted related/binded to cloud and user/account information [0024] the enterprise system 160 includes a CPU 162, storage 164, and a memory 165. Further, the memory 165 includes a ticket response (TR) application 167 used to evaluate service requests submitted by users of the client system [0027] the routing application 244 may be configured to evaluate the storage parameters 205 received from client system 102 using the provider metadata table 246. More specifically, the routing application 244 may compare the requested storage parameters 205 with the capabilities advertised by the different cloud storage providers 230, and optionally, the registered storage polices 248, to select a particular cloud storage provider ) when the account authentication request is successfully verified, transmitting a metadata tenant set to the client, the metadata tenant set having a binding relation with the cloud account information; (Demilo [0022] the cloud service 130 may be determined dynamically using policies 142. For example, the file metadata 114 specified by the user may indicate a particular file type being uploaded, and the file upload tenant may select what cloud storage service 130 to send the file based on the file metadata 114. The application 122 may send the file metadata 114 to the storage broker 140, which in turn, stores the file metadata 114 in the enterprise database 180 (shown in FIG. 1 as file metadata 182) [0045] At step 535, the tenant application may store the metadata fields for the file in an enterprise database, along with a reference to the file in cloud storage. Thus, individuals within the enterprise have access to the file from the cloud storage service, without incurring the physical storage or maintenance requirements for storing the file directly. [FIG.1] shows corresponding flow for the client tenant system with corresponding request/metadata file/set transmitted related/binded to cloud and user/account information) in response to a tenant selection request transmitted by the client, transmitting a metadatabase set to the client, the tenant selection request carrying an identifier of a to-be-requested metadata tenant, the metadata tenant set comprising the to-be-requested metadata tenant, and the metadatabase set having a mapping relation with the to-be-requested metadata tenant; (Demilo [0012] link to the file and the metadata may be stored in an enterprise database. Thus, the user interface provide by the tenant application allows the user to transfer files to a cloud storage service suitable for the needs of a particular case. As noted, demand for storage capacity is only part of the problem. In order for files to be searched, located, retrieved, or intelligently mined for knowledge, meaningful metadata should be associated with files stored in "the cloud." Accordingly, in one embodiment, the broker collects and stores the metadata attributes (along with a reference to the file stored in the cloud) in an enterprise database. At the same time, the file itself may be transmitted to the cloud storage service directly [0034] sends the file 276' to the storage cloud 280, the policy router 270 may update the index table 292 to reflect that file 276' was sent to cloud storage service 280 for storage. More generally, the index table 292 may include a file ID and a customer ID (or application ID) for each file sent to a cloud storage provider. Further, the policy router 270 may send an update of the index table 292 to the application which sent a given file for storage. That is, each time a file is written to cloud storage, the policy router 270 may return a message to the application submitting the storage request 275. Such a message may be used to update a list of files sent to cloud storage over the policy router 270 [0038] a collection of metadata attributes 405 to associate with files uploaded to cloud storage using the example service request tenant application described relative to FIG. 1... [FIG.1] shows corresponding flow for the client tenant system with corresponding request/metadata file/set transmitted and enterprise database acting as a metadatabase set having a mapping relations) and in response to a database query request transmitted by the client, transmitting a metadata table set to the client, the database query request carrying an identifier of a to-be-requested metadatabase, the metadatabase set comprising the to-be-requested metadatabase, and the metadatabase set having a mapping relation with the to-be-requested metadatabase. (Demilo [0027] or storing a file using one of the cloud storage providers 230. The registered storage policy 248 may be based on the particular client system 102 making the request to store the file 112 or the particular storage parameters 205 included with the request. Further, in one embodiment, the routing device 240 may query multiple cloud storage providers 230 to identify the capabilities or characteristics of different cloud storage providers 230. For example, the cloud storage providers 230 may advertise service level and capability metadata 235.[0038] a collection of metadata attributes 405 to associate with files uploaded to cloud storage using the example service request tenant application described relative to FIG. 1. As shown, the interface 400 includes a name of "TSRT" for the tenant application being registered. The interface 400 also includes four attributes 405 for files uploaded using the "TSRT" application. Illustratively, the attributes 405 include a file name attribute, a case ID attribute, a file size attribute, and a file type attribute. In addition to a name, each attribute 405 also includes a data type, and optionally a default value and an indication of whether a given attribute is required. Further the interface 400 allows the user to add additional attributes using an add attribute button 406 or remove or edit a selected attribute using buttons 410. In this example, the metadata attributes 405 are consistent with what metadata would be useful for a tenant application used to upload files associated with service requests for computer hardware. Of course, one of ordinary skill in the art will recognize that the particular metadata attributes [FIG.1] shows corresponding flow and query process for the client tenant system with corresponding request/metadata file/set transmitted and enterprise database acting as a metadatabase set having a mapping relations) Demilo lacks explicitly and orderly teaching receiving a tenant selection request from the client, the tenant selection request carrying an identifier of a to-be-requested metadata tenant; receiving a database query request from the client, the database query request carrying an identifier of a to-be-requested metadatabase; However Khillar teaches receiving a tenant selection request from the client, the tenant selection request carrying an identifier of a to-be-requested metadata tenant; receiving a database query request from the client, the database query request carrying an identifier of a to-be-requested metadatabase (Khillar [0004] a plurality of clients and a plurality of tenant databases. The plurality of tenant databases may include a first tenant database of a first database type and a second tenant database of a second database type. The delegator receives a request from a client. The request is to perform a database related action and may identify a query type and tenant identifier. The delegator identifies a tenant database using the tenant identifier included in the request.[0007] The client may request and form a connection (such as a Hypertext Transmission Protocol/2 (HTTP/2) connection) to the delegator. The client may stream, communicate, or otherwise transmit a request including any queries to perform various database related actions to the delegator. The request may hold details of the SQL, parameters associated with a database connection, and tenant information. The request may indicate the query type and a tenant identifier. The request may various connection data corresponding to a database connection to the tenant database. The connection data may include a connection identifier (ID) (e.g., a connection string), login credentials corresponding to a user of the client (e.g., a username and/or password), a tenant identifier, a query type, a specific query, various placeholders and limits on return values, etc. [0033] The request is to perform a database related action and may identify a query type and tenant identifier. The delegator identifies a tenant database using the tenant identifier included in the request [0061] The database identifier 212 may be designed or implemented to identify a particular tenant database 208 from the subset of tenant databases 208 accessible by the client 202. The database identifier 212 may identify the tenant database 208 based on information included in the request. In instances where a user has access to one tenant database 208, the database identifier 212 may identify the tenant database 208 based on the tenant identifier from the request...[53-61] goes into further detail on the different corresponding identifiers of the tenant and database [FIG.2] shows corresponding overall visual of the system which embodies the corresponding selection requests) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Khillar's Multi-tenant database querying and requesting in order create a more efficient system (Khillar [0006] In some implementations, the delegator includes signature cache. The signature cache may be used by the delegator for storing various table metadata (e.g., characteristics or features) of the tenant databases. The delegator may store the table metadata in the cache until expiration of the database connection or alteration to a structure of a table corresponding to the table metadata. Such embodiments may expedite performance of various database related action at the tenant database by storing table metadata corresponding to the tenant database. Through storing table metadata, the delegator need not populate or otherwise retrieve tenant metadata at each instance the tenant database is accessed (which could slow performance). Rather, the delegator can use the table metadata stored in the cache for executing the database related actions.[0009] In some embodiments, the delegator may include a driver which uses table metadata for creating a prepared statement in accordance with the request. The table metadata may be unique for each SQL. The table metadata may also be referred to as signature data. The delegator may create table metadata for each SQL and store the table metadata in a cache. The delegator may clear the cache upon expiration or alteration of the corresponding tenant database. The delegator may use the cached table metadata for expediting performance of the database related functions.[0035] In some implementations, the delegator includes signature cache. The signature cache may be used by the delegator for storing various table metadata (e.g., characteristics or features) of the tenant databases. The delegator may store the table metadata in the cache until expiration of the database connection or alteration to a structure of a table corresponding to the table metadata. Such embodiments may expedite performance of various database related action at the tenant database by storing table metadata corresponding to the tenant database. )
Corresponding system claim 14 is rejected similarly as claim 1 above. Additional Limitations: Device with processor(s) and memory (Demilo [FIG.1 in conjunction with FIG.2A] shows the corresponding hardware components with memory and processor)
Corresponding product claim 20 is rejected similarly as claim 1 above. Additional Limitations: computer readable medium capable of reading and executing instructions (Demilo [0016] The application programs (e.g., the cloud storage management broker) disclosed herein may be distributed on a variety of computer-readable storage media. [FIG.1 in conjunction with FIG.2A] shows the corresponding hardware components capable of reading and executing computer readable instructions )
Regarding claim 2, Demilo and Khillar teach The management method according to claim 1, wherein after transmitting the metadata table set to the client, the method further comprises: in response to a data table query request transmitted by the client, transmitting a to-be-requested metadata table to the client, the data table query request carrying an identifier of the to-be-requested metadata table, and the metadata table set comprising the to-be-requested metadata table. (Demilo [0015] a cloud storage location, and instead rely on the policy router. In such a case, the tenant application may collect a set of attributes or requirements for that tenant application, and forward this information along with the file to be stored to the policy router. In turn, the policy router makes a decision of where to store the file. For example, the cloud storage policy router may evaluate the attributes against the advertised capabilities of multiple cloud storage routers. That is, the broker collects the appropriate metadata and the router selects the cloud storage service. Thus, the broker and storage policy router effectively operate as an end-to-end file exchange, where users submit files for storage with a set of requirements to the broker and the router can then locate those files at the best available cloud storage. [FIG.1] shows corresponding flow for the client tenant system with corresponding request/metadata file/set transmitted related/binded to cloud and user/acount information [0022] an interface allows the user to specify the file metadata 114 to associate with the file 112. Further, the file upload tenant 148 may provide a network link (e.g., a URL) used to upload the file 112 to the cloud storage service 130. The particular cloud service 130 may be specified as part of the configuration of the file upload tenant 140. Alternatively, the cloud service 130 may be determined dynamically using policies 142. For example, the file metadata 114 specified by the user may indicate a particular file type being uploaded, and the file upload tenant may select what cloud storage service 130 to send the file based on the file metadata 114. The application 122 may send the file metadata 114 to the storage broker 140, which in turn, stores the file metadata 114 in the enterprise database 180 (shown in FIG. 1 as file metadata 182). Thus, as shown, the enterprise database 180 includes the file metadata [47-48] elaborates on the matter [FIG.1] shows corresponding flow for the client tenant system with corresponding request/metadata file/set transmitted related/binded to cloud and user/account information)
Corresponding system claim 15 is rejected similarly as claim 2 above.
Regarding claim 3, Demilo and Khillar teach The management method according to claim 1, further comprising: when the account authentication request is successfully verified, transmitting a service tenant set to the client, the service tenant set having a binding relation with the cloud account information; and in response to a service selection request transmitted by the client, transmitting service processing information generated based on a to-be-requested service tenant, the service selection request carrying an identifier of the to-be-requested service tenant, and the service tenant set comprising the to-be-requested service tenant. (Demilo [0010] receiving a request to store the file using a cloud storage service. The request may be received by a tenant application hosted on a storage broker. The method may generally include identifying one or more metadata attributes to associate with the file, generating a user interface configured to prompt a user to supply values for the one or more metadata attributes, and generating a network link configured to allow the user to upload the file to the cloud storage service. The method may further include transmitting the network link and the user interface to the user's computer system, receiving the metadata [0012]The tenant application may be configured to generate a user interface with graphical interface components used specify metadata attributes to associate with a file uploaded to a cloud storage service. For example, the tenant application may provide a web service configured to generate the appropriate HTML content to render an interface on a web browser. In such a case, the HTML content may include form elements used to enter and submit the metadata to associate with a file stored in cloud storage by a particular tenant application. The broker may determine, based on the metadata (or the particular tenant application), an appropriate cloud storage vendor/location and provide an address for that location ... transfer files to a cloud storage service ... file itself may be transmitted to the cloud storage service directly. [13-15 and 21-29] elaborate on service data being sent in response to request and the corresponding connected steps [FIG.1] shows corresponding flow for the client tenant system with corresponding request/metadata file/set transmitted related/binded to cloud and user/account information)
Corresponding system claim 16 is rejected similarly as claim 3 above.
Regarding claim 4, Demilo and Khillar teach The management method according to claim 3, wherein transmitting the service processing information comprises: in response to a service selection request transmitted by the client, determining a to-be-requested metadata tenant set, the to-be-requested metadata tenant set having a mapping relation with the to-be-requested service tenant; obtaining a to-be-requested metadata table set having a mapping relation with the to-be-requested metadata tenant set; obtaining service data according to the to-be-requested metadata table set and processing the service data to obtain the service processing information; and transmitting the service processing information to the client. (Demilo [0010] transmitting the network link and the user interface to the user's computer system, receiving the metadata [0012]The tenant application may be configured to generate a user interface with graphical interface components used specify metadata attributes to associate with a file uploaded to a cloud storage service. For example, the tenant application may provide a web service configured to generate the appropriate HTML content to render an interface on a web browser. In such a case, the HTML content may include form elements used to enter and submit the metadata to associate with a file stored in cloud storage by a particular tenant application. The broker may determine, based on the metadata (or the particular tenant application), an appropriate cloud storage vendor/location and provide an address for that location ... transfer files to a cloud storage service ... file itself may be transmitted to the cloud storage service directly. [13] the cloud storage policy router may receive service level/capability advertisements from multiple cloud storage services, as well as provide a web-services style interface allowing a client application to upload a file along with requested storage attributes. When a user uploads a file and a set of storage requirements, the cloud storage policy router matches the requirements with the capabilities of different cloud storage providers. Once a cloud storage service is determined, the routing device then forwards the file to that cloud storage service...) [21-29 and 42-47] elaborate on service data being sent in response to request and the corresponding connected steps [FIG.1] shows corresponding flow for the client tenant system with corresponding request/metadata file/set transmitted related/binded to cloud and user/account information)
Corresponding system claim 17 is rejected similarly as claim 4 above.
Regarding claim 11, Demilo and Khillar teach The management method according to claim 2, wherein the data table query request further carries a another object parameter, and the another object parameter comprises query information; (Demilo [0014] the cloud storage policy router may select a cloud storage service based on the requirements...policy router may enforce a requirement that data files remain stored within a particular jurisdiction. Similarly, the policy may allow an enterprise to specify a variety of other business or regulatory processes related to where data records are stored and how they may be accessed...[0027] a provider metadata table 246, and registered storage policies 248. In one embodiment, the web services interface 242 allows the client system 102 to connect to the routing device 242 and provide it the storage parameters 205 indicating preferences for storing the file 112 with a cloud storage provider 130. Further, the routing application 244 may be configured to evaluate the storage parameters 205 received from client system 102 using the provider metadata table 246. More specifically, the routing application 244 may compare the requested storage parameters 205 with the capabilities advertised by the different cloud storage providers 230, and optionally, the registered storage polices 248, to select a particular cloud storage provider 120 to store the file 112. For example, the requested storage parameters 205 may indicate a minimum guaranteed service level availability (SLA) that the selected cloud storage provider 230 should have to be selected to store the file 112. Similarly, one of the registered storage policies 248 may indicate whether the file 112 should be encrypted before being stored by the cloud storage provider 230 or indicate what locations are allowed (or prohibited) for storing a file using one of the cloud storage providers 230. The registered storage policy 248 may be based on the particular client system 102 making the request to store the file 112 or the particular storage parameters 205 included with the request. Further, in one embodiment, the routing device 240 may query multiple cloud storage providers 230 to identify the capabilities or characteristics of different cloud storage providers 230. For example, the cloud storage providers 230 may advertise service level and capability metadata 235.[FIG.2A&2B] show the corresponding flow)
Claims 5-7 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Demilo in view of Abdul, Pala and US 20210303241 A1; PINNEY; Shaun (hereinafter Pinney).
Regarding claim 5, Demilo and Khillar teach The management method according to claim 1, further comprising: when the account authentication request is successfully verified, storing the cloud account information in a to-be-requested session, the to-be-requested session being created based on the account authentication request; (Demilo [0010] receiving a request to store the file using a cloud storage service. The request may be received by a tenant application hosted on a storage broker. The method may generally include identifying one or more metadata attributes to associate with the file, generating a user interface configured to prompt a user to supply values for the one or more metadata attributes, and generating a network link configured to allow the user to upload the file to the cloud storage service. [0014] the cloud storage policy router may select a cloud storage service based on the requirements for storage submitted with a file. For example, the requirements may allow an enterprise to specify any geopolitical, business, or regulatory requirements associated with storing data files faced by a given enterprise. For instance, the United States Patriot Act has resulted in some non-US localities to pass legislation forbidding data storage within the United States. (See, e.g., British Columbia, Freedom of Information and Protection of Privacy Act "FOIPPA," Oct. 21, 2004). In such a case, the cloud storage policy router may enforce a policy that prevents data files from being stored in a particular jurisdiction. Alternatively, the cloud storage policy router may enforce a requirement that data files remain stored within a particular jurisdiction [0021] a service request submitted to a computer hardware vendor (e.g., a configuration file associated with the user's computer hardware). And assume that the file download tenant 150 allows a user of the enterprise system 160 to access the file from the cloud storage service 130 and the associated file metadata as part of processing the service request. In such a case, the user may access the file upload tenant 148 to upload the file 112 to the cloud storage service 130. Once uploaded, the cloud storage service 130 may store the file 112 on a block storage device 132 (or some other form of physical storage [24-29] elaborate on the storage of the cloud account related to the request) obtaining the cloud account information from the to-be-requested session. (Demilo [0012] in order for files to be searched, located, retrieved, or intelligently mined for knowledge, meaningful metadata should be associated with files stored in "the cloud." Accordingly, in one embodiment, the broker collects and stores the metadata attributes (along with a reference to the file stored in the cloud) in an enterprise database. At the same time, the file itself may be transmitted to the cloud storage service directly. [0016] to send/retrieve files to/from cloud storage services using a tenant application registered with a management broker (or a cloud storage policy router). [0024] may retrieve the file 112' from the cloud storage service 130, allowing the service requested submitted by client system 102 to be processed. Further, if the file 112' is encrypted, the TR application may retrieve the appropriate encryption from the key service 170 and the key database 175. In this example, the TR application 167 retrieves the file 112' from the cloud service 130 directly. [30-36] further elaborates) Demilo lacks explicitly teaching when receiving a Remote Procedure Call (RPC) request However Pinney teaches when receiving a Remote Procedure Call (RPC) request (Pinney [0001] using remote procedure call (RPC) methods, and more particularly, a method and system for authenticating a user and authorizing the user to access multifunction printer-specific and/or cloud services on a multifunction printer with a user interface. [0003] using remote procedure call-based (RPC-based) methods for user and cloud service authentication to securely and seamlessly support MFP features, [5-7] elaborate on the matter) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Pinney in order to facilitate authentication to be securely and seamless (Pinney [0003] using remote procedure call-based (RPC-based) methods for user and cloud service authentication to securely and seamlessly support MFP features, [5-7] elaborate on the matter)
Corresponding system claim 18 is rejected similarly as claim 5 above.
Regarding claim 6, Demilo, Abdul, Pala and Pinney teach The management method according to claim 5, wherein receiving the account authentication request transmitted by a client comprises: receiving the account authentication request transmitted by the client through a to-be-requested communication interface, the to-be-requested communication interface being a communication interface supported by the client. (Demilo [0038] At step 310, the user may register metadata fields to supply for files uploaded to the cloud storage service identified at step 305. For example, FIG. 4A illustrates an example interface 400 for specifying a collection of metadata attributes 405 to associate with files uploaded to cloud storage using the example service request tenant application described relative to FIG. 1. As shown, the interface 400 includes a name of "TSRT" for the tenant application being registered. The interface 400 also includes...[FIG.4A-4C] shows a visual)
Corresponding system claim 19 is rejected similarly as claim 6 above.
Regarding claim 7, Demilo, Abdul, Pala and Pinney teach The management method according to claim 5, wherein receiving the account authentication request transmitted by a client comprises: receiving the account authentication request transmitted by the client, the account authentication request being generated after encapsulating the cloud account information by calling a first transmission method by the client; and calling a second transmission method to decapsulate the account authentication request to obtain the cloud account information, the second transmission method adopting a same protocol type as the first transmission method. (Demilo [FIG.1] shows the flow of receiving request, then encapsulating/storing via transmission process [0013] cloud storage policy router (or more simply just router or routing device) may act as a proxy for multiple cloud storage locations. In such a case, the cloud storage policy router may receive service level/capability advertisements from multiple cloud storage services, as well as provide a web-services style interface allowing a client application to upload a file along with requested storage attributes. When a user uploads a file and a set of storage requirements, the cloud storage policy router matches the requirements with the capabilities of different cloud storage providers. Once a cloud storage service is determined, the routing device then forwards the file to that cloud storage service. If no cloud is available that satisfies the requirements for a given file or application, the cloud storage policy router may simply fail the storage request. The routing device may notify the sender of the selected cloud storage service (as well as store the metadata attributes associated with the file uploaded to the cloud storage service). Thus, the cloud storage policy router may provide real time service negotiation and dynamic cloud storage management. [28-36] it is obvious and evident from these sections that their can be a plurality of transmission methods to store/encapsulating and retrieve/decapsulate data related to request which is linked to cloud account information)
Claims 8-10 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Demilo in view of Abdul, Pala and US 20230018975 A1; Sreenivasan; Balakrishnan et al. (hereinafter Sreenivasan).
Regarding claim 8, Demilo and Khillar teach The management method according to claim 1, further comprising: when the account authentication request is successfully verified, receiving a metadata table creating request transmitted by the client, the metadata table creating request carrying a first object parameter and the first object parameter comprising … performing parameter verification on the first object parameter carried in the metadata table creating request; and when the first object parameter passes verification (Demilo [0014] the cloud storage policy router may select a cloud storage service based on the requirements...policy router may enforce a requirement that data files remain stored within a particular jurisdiction. Similarly, the policy may allow an enterprise to specify a variety of other business or regulatory processes related to where data records are stored and how they may be accessed...[0027] a provider metadata table 246, and registered storage policies 248. In one embodiment, the web services interface 242 allows the client system 102 to connect to the routing device 242 and provide it the storage parameters 205 indicating preferences for storing the file 112 with a cloud storage provider 130. Further, the routing application 244 may be configured to evaluate the storage parameters 205 received from client system 102 using the provider metadata table 246. More specifically, the routing application 244 may compare the requested storage parameters 205 with the capabilities advertised by the different cloud storage providers 230, and optionally, the registered storage polices 248, to select a particular cloud storage provider 120 to store the file 112. For example, the requested storage parameters 205 may indicate a minimum guaranteed service level availability (SLA) that the selected cloud storage provider 230 should have to be selected to store the file 112. Similarly, one of the registered storage policies 248 may indicate whether the file 112 should be encrypted before being stored by the cloud storage provider 230 or indicate what locations are allowed (or prohibited) for storing a file using one of the cloud storage providers 230. The registered storage policy 248 may be based on the particular client system 102 making the request to store the file 112 or the particular storage parameters 205 included with the request. Further, in one embodiment, the routing device 240 may query multiple cloud storage providers 230 to identify the capabilities or characteristics of different cloud storage providers 230. For example, the cloud storage providers 230 may advertise service level and capability metadata 235.[FIG.2A&2B] show the corresponding flow) the combination lacks explicitly and orderly teaching metadata category information… creating a metadata table according to the metadata category information. However Sreenivasan teaches metadata category information… creating a metadata table according to the metadata category information. (Sreenivasan [0088] The database decomposition system 120 updates the category column in the metadata table 370 for each table listed in the metadata table 370 with one of {“OPERATIONAL TABLE”, “STATUS TABLE”, “TOOL SPECIFIC TABLE”}, which had been previously instantiated with a default value of “OPERATIONAL TABLE” in block 460 of FIG. 4. The category value of “OPERATIONAL TABLE” in the metadata table 370 indicates the table, represented as a record/row in the metadata table 370, is of operational category, indicating that the table represents a query/command operation of the monolith database 115. A table having a category value of “STATUS TABLE” in the metadata table 370 indicates that the table represents a status of a data object entity of the monolith database 115. A table having a category value of “TOOL SPECIFIC TABLE” in the metadata table 370 indicates that the table represents an entity, either an operation or a data object, that is specific to a certain tool used in the monolith database system 110, as in network interface, API, etc. Details of updating the category value in the metadata table 370 for tables are presented in block 940 of FIG. 9 and corresponding description. [0101] In block 940, the database decomposition system 120 updates values of the category column in the metadata table 370 based on unit query types for the tables involved in the transactions, as presented in the table-query tuples from block 930. The database decomposition system 120 determines new values of the category column in the metadata table 370 by use of a category modeling that determines a category value for a table based on the unit query types in the table-query tuples. [102-103 and 114] elaborate on the matter [FIG.4] shows visual) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Sreenivasan in order to improve the overall performance of the database via a unique metadata table integration (Sreenivsasan [AB] clustering on the distributed database regarding aspects of performance, scalability, and availability that improves the aspects of the distributed database over the monolith database is performed and the distributed database is checked for eventual consistency amongst the distributed database and one or more replicas of the distributed database before deployed to replace the monolith database.[0031] to improve confidence in analyzing data objects... 130 would be improved over the MDB system 110 [0106] The database decomposition system 120 has updated the metadata table 370 with a new category values based on modeling of the unit query patterns accessing each table listed in the metadata table 370. In operations of block 250 described in FIG. 12, the database decomposition system 120 finalize division of the transactions for operations in the distributed database 140 and completes NFR modeling to improve scalability and availability of the distributed database 140 over the monolith database 115.)
Regarding claim 9, Demilo and Khillar teach The management method according to claim 1, further comprising: when the account authentication request is successfully verified, receiving a metadata table update request transmitted by the client, the metadata table update request … comprising … table name information… performing parameter verification on the another object parameter… when the another object parameter passes verification, obtaining a metadata table according to the table name information; (Demilo [0014] the cloud storage policy router may select a cloud storage service based on the requirements...policy router may enforce a requirement that data files remain stored within a particular jurisdiction. Similarly, the policy may allow an enterprise to specify a variety of other business or regulatory processes related to where data records are stored and how they may be accessed...[0027] a provider metadata table 246, and registered storage policies 248. In one embodiment, the web services interface 242 allows the client system 102 to connect to the routing device 242 and provide it the storage parameters 205 indicating preferences for storing the file 112 with a cloud storage provider 130. Further, the routing application 244 may be configured to evaluate the storage parameters 205 received from client system 102 using the provider metadata table 246. More specifically, the routing application 244 may compare the requested storage parameters 205 with the capabilities advertised by the different cloud storage providers 230, and optionally, the registered storage polices 248, to select a particular cloud storage provider 120 to store the file 112. For example, the requested storage parameters 205 may indicate a minimum guaranteed service level availability (SLA) that the selected cloud storage provider 230 should have to be selected to store the file 112. Similarly, one of the registered storage policies 248 may indicate whether the file 112 should be encrypted before being stored by the cloud storage provider 230 or indicate what locations are allowed (or prohibited) for storing a file using one of the cloud storage providers 230. The registered storage policy 248 may be based on the particular client system 102 making the request to store the file 112 or the particular storage parameters 205 included with the request. Further, in one embodiment, the routing device 240 may query multiple cloud storage providers 230 to identify the capabilities or characteristics of different cloud storage providers 230. For example, the cloud storage providers 230 may advertise service level and capability metadata 235.[FIG.2A&2B] show the corresponding flow) Demilo lacks explicitly and orderly teaching the metadata table update request carrying a second object parameter and the second object parameter comprising metadata category information… carried in the metadata table update request; and deleting column information in the metadata table and updating the metadata table according to the metadata category information. However Sreenivasan teaches the metadata table update request carrying a another object parameter and the another object parameter comprising metadata category information… carried in the metadata table update request; and deleting column information in the metadata table and updating the metadata table according to the metadata category information. (Sreenivasan [0088] The database decomposition system 120 updates the category column in the metadata table 370 for each table listed in the metadata table 370 with one of {“OPERATIONAL TABLE”, “STATUS TABLE”, “TOOL SPECIFIC TABLE”}, which had been previously instantiated with a default value of “OPERATIONAL TABLE” in block 460 of FIG. 4. The category value of “OPERATIONAL TABLE” in the metadata table 370 indicates the table, represented as a record/row in the metadata table 370, is of operational category, indicating that the table represents a query/command operation of the monolith database 115. A table having a category value of “STATUS TABLE” in the metadata table 370 indicates that the table represents a status of a data object entity of the monolith database 115. A table having a category value of “TOOL SPECIFIC TABLE” in the metadata table 370 indicates that the table represents an entity, either an operation or a data object, that is specific to a certain tool used in the monolith database system 110, as in network interface, API, etc. Details of updating the category value in the metadata table 370 for tables are presented in block 940 of FIG. 9 and corresponding description. [0101] In block 940, the database decomposition system 120 updates values of the category column in the metadata table 370 based on unit query types for the tables involved in the transactions, as presented in the table-query tuples from block 930. The database decomposition system 120 determines new values of the category column in the metadata table 370 by use of a category modeling that determines a category value for a table based on the unit query types in the table-query tuples. [102-103 and 114] elaborate on the matter [FIG.4] shows visual) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Sreenivasan in order to improve the overall performance of the database via a unique metadata table integration (Sreenivsasan [AB] clustering on the distributed database regarding aspects of performance, scalability, and availability that improves the aspects of the distributed database over the monolith database is performed and the distributed database is checked for eventual consistency amongst the distributed database and one or more replicas of the distributed database before deployed to replace the monolith database.[0031] to improve confidence in analyzing data objects... 130 would be improved over the MDB system 110 [0106] The database decomposition system 120 has updated the metadata table 370 with a new category values based on modeling of the unit query patterns accessing each table listed in the metadata table 370. In operations of block 250 described in FIG. 12, the database decomposition system 120 finalize division of the transactions for operations in the distributed database 140 and completes NFR modeling to improve scalability and availability of the distributed database 140 over the monolith database 115.)
Regarding claim 10, Demilo and Khillar teach The management method according to claim 1, further comprising: when the account authentication request is successfully verified… performing parameter verification on the third object parameter (Demilo [0014] the cloud storage policy router may select a cloud storage service based on the requirements...policy router may enforce a requirement that data files remain stored within a particular jurisdiction. Similarly, the policy may allow an enterprise to specify a variety of other business or regulatory processes related to where data records are stored and how they may be accessed...[0027] a provider metadata table 246, and registered storage policies 248. In one embodiment, the web services interface 242 allows the client system 102 to connect to the routing device 242 and provide it the storage parameters 205 indicating preferences for storing the file 112 with a cloud storage provider 130. Further, the routing application 244 may be configured to evaluate the storage parameters 205 received from client system 102 using the provider metadata table 246. More specifically, the routing application 244 may compare the requested storage parameters 205 with the capabilities advertised by the different cloud storage providers 230, and optionally, the registered storage polices 248, to select a particular cloud storage provider 120 to store the file 112. For example, the requested storage parameters 205 may indicate a minimum guaranteed service level availability (SLA) that the selected cloud storage provider 230 should have to be selected to store the file 112. Similarly, one of the registered storage policies 248 may indicate whether the file 112 should be encrypted before being stored by the cloud storage provider 230 or indicate what locations are allowed (or prohibited) for storing a file using one of the cloud storage providers 230. The registered storage policy 248 may be based on the particular client system 102 making the request to store the file 112 or the particular storage parameters 205 included with the request. Further, in one embodiment, the routing device 240 may query multiple cloud storage providers 230 to identify the capabilities or characteristics of different cloud storage providers 230. For example, the cloud storage providers 230 may advertise service level and capability metadata 235.[FIG.2A&2B] show the corresponding flow) the combination lacks explicitly and orderly teaching receiving a metadata table deleting request transmitted by the client, the metadata table deleting request carrying a third object parameter and the third object parameter comprising metadata category information and table name information; … carried in the metadata table deleting request; and when the third object parameter passes verification, deleting a metadata table according to the table name information. However Sreenivasan teaches receiving a metadata table deleting request transmitted by the client, the metadata table deleting request carrying a third object parameter and the third object parameter comprising metadata category information and table name information; … carried in the metadata table deleting request; and when the third object parameter passes verification, deleting a metadata table according to the table name information. (Sreenivasan [0088] The database decomposition system 120 updates the category column in the metadata table 370 for each table listed in the metadata table 370 with one of {“OPERATIONAL TABLE”, “STATUS TABLE”, “TOOL SPECIFIC TABLE”}, which had been previously instantiated with a default value of “OPERATIONAL TABLE” in block 460 of FIG. 4. The category value of “OPERATIONAL TABLE” in the metadata table 370 indicates the table, represented as a record/row in the metadata table 370, is of operational category, indicating that the table represents a query/command operation of the monolith database 115. A table having a category value of “STATUS TABLE” in the metadata table 370 indicates that the table represents a status of a data object entity of the monolith database 115. A table having a category value of “TOOL SPECIFIC TABLE” in the metadata table 370 indicates that the table represents an entity, either an operation or a data object, that is specific to a certain tool used in the monolith database system 110, as in network interface, API, etc. Details of updating the category value in the metadata table 370 for tables are presented in block 940 of FIG. 9 and corresponding description. [0101] In block 940, the database decomposition system 120 updates values of the category column in the metadata table 370 based on unit query types for the tables involved in the transactions, as presented in the table-query tuples from block 930. The database decomposition system 120 determines new values of the category column in the metadata table 370 by use of a category modeling that determines a category value for a table based on the unit query types in the table-query tuples. [102-103 and 114] elaborate on the matter [FIG.4] shows visual) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Sreenivasan in order to improve the overall performance of the database via a unique metadata table integration (Sreenivsasan [AB] clustering on the distributed database regarding aspects of performance, scalability, and availability that improves the aspects of the distributed database over the monolith database is performed and the distributed database is checked for eventual consistency amongst the distributed database and one or more replicas of the distributed database before deployed to replace the monolith database.[0031] to improve confidence in analyzing data objects... 130 would be improved over the MDB system 110 [0106] The database decomposition system 120 has updated the metadata table 370 with a new category values based on modeling of the unit query patterns accessing each table listed in the metadata table 370. In operations of block 250 described in FIG. 12, the database decomposition system 120 finalize division of the transactions for operations in the distributed database 140 and completes NFR modeling to improve scalability and availability of the distributed database 140 over the monolith database 115.)
Regarding claim 12, Demilo and Khillar teach teaches The management method according to claim 1, further comprising: the combination lacks explicitly and orderly teaching when receiving a first query request, determining a metadatabase corresponding to a metadatabase foreign key from a first metadata table according to the first query request, the first query request carrying a table identifier, and the table identifier being associated with the metadatabase foreign key; when receiving a second query request, determining a metadata table corresponding to a metadata table foreign key from a second metadata table according to the second query request, the second query request carrying a column, and the column being associated with the metadata table foreign key; when receiving a third query request, determining a metadata table corresponding to a metadata table foreign key from a third metadata table according to the third query request, the third query request carrying a subregion identifier, and the subregion identifier being associated with the metadata table foreign key; when receiving a another query request, determining a storage descriptor corresponding to a storage table foreign key from a another metadata table according to the another query request, the another query request carrying a subregion identifier, and the subregion identifier being associated with the storage table foreign key; when receiving a fifth query request, determining a storage descriptor corresponding to a storage table foreign key from a fifth metadata table according to the fifth query request, the fifth query request carrying a table identifier, and the table identifier being associated with the storage table foreign key; and when receiving a sixth query request, determining a metadatabase corresponding to a metadatabase foreign key from a sixth metadata table according to the sixth query request, the sixth query request carrying a function identifier, and the function identifier being associated with the metadatabase foreign key. However Sreenivasan teaches when receiving a first query request, determining a metadatabase corresponding to a metadatabase foreign key from a first metadata table according to the first query request, the first query request carrying a table identifier, and the table identifier being associated with the metadatabase foreign key; when receiving a second query request, determining a metadata table corresponding to a metadata table foreign key from a second metadata table according to the second query request, the second query request carrying a column, and the column being associated with the metadata table foreign key; (Sreenivasan [0029] The MDB system 110 includes an MDB 115 and an MDB application 113. As noted, the MDB system 110 is typically of monolithic and relational architecture, indicating that the MDB 115 includes all tables T1 . . . Tn, wherein n is a number of tables in the MDB 115, and that the MDB application 113 accesses the MDB 115 with transactions with a combination of queries Q1 . . . Qm, wherein m is a number of queries available in the MDB application 113. The MDB application 113 represents data service operations [0038] as being broken down to unit queries, and entities involved therein. The database decomposition system 120 further updates the metadata table 370 resulting from block 210 based on transaction heuristics data collected from operations of the MDB system 110... [0057] The database decomposition system 120 creates the graph model 350 to minimize the number of entities to be presented as a node for the DDB 140, while providing the functionalities equivalent to the MDB 115. The database decomposition system 120 analyzes each table of the MDB 115 for a sign indicating if a table is an intermediate table or an intersection table as being presented in the MDB 115, by examining columns, specifically for primary keys, surrogate keys, and/or foreign keys.[59-61] elaborates on the utilization of a metadatabase foreign key [87-94] further elaborate on the all the different queries and their ability to have different functions) when receiving a third query request, determining a metadata table corresponding to a metadata table foreign key from a third metadata table according to the third query request, the third query request carrying a subregion identifier, and the subregion identifier being associated with the metadata table foreign key; when receiving a another query request, determining a storage descriptor corresponding to a storage table foreign key from a another metadata table according to the another query request, the another query request carrying a subregion identifier, and the subregion identifier being associated with the storage table foreign key; (Sreenivasan [FIG.8] shows the corresponding flow [0029] The MDB system 110 includes an MDB 115 and an MDB application 113. As noted, the MDB system 110 is typically of monolithic and relational architecture, indicating that the MDB 115 includes all tables T1 . . . Tn, wherein n is a number of tables in the MDB 115, and that the MDB application 113 accesses the MDB 115 with transactions with a combination of queries Q1 . . . Qm, wherein m is a number of queries available in the MDB application 113. The MDB application 113 represents data service operations [0038] as being broken down to unit queries, and entities involved therein. The database decomposition system 120 further updates the metadata table 370 resulting from block 210 based on transaction heuristics data collected from operations of the MDB system 110... [0057] The database decomposition system 120 creates the graph model 350 to minimize the number of entities to be presented as a node for the DDB 140, while providing the functionalities equivalent to the MDB 115. The database decomposition system 120 analyzes each table of the MDB 115 for a sign indicating if a table is an intermediate table or an intersection table as being presented in the MDB 115, by examining columns, specifically for primary keys, surrogate keys, and/or foreign keys.[0059-61] elaborates on the utilization of a metadatabase foreign key [87-94] further elaborate on the all the different queries and their ability to have different functions) when receiving a fifth query request, determining a storage descriptor corresponding to a storage table foreign key from a fifth metadata table according to the fifth query request, the fifth query request carrying a table identifier, and the table identifier being associated with the storage table foreign key; and when receiving a sixth query request, determining a metadatabase corresponding to a metadatabase foreign key from a sixth metadata table according to the sixth query request, the sixth query request carrying a function identifier, and the function identifier being associated with the metadatabase foreign key. (Sreenivasan [0029] The MDB system 110 includes an MDB 115 and an MDB application 113. As noted, the MDB system 110 is typically of monolithic and relational architecture, indicating that the MDB 115 includes all tables T1 . . . Tn, wherein n is a number of tables in the MDB 115, and that the MDB application 113 accesses the MDB 115 with transactions with a combination of queries Q1 . . . Qm, wherein m is a number of queries available in the MDB application 113. The MDB application 113 represents data service operations [0038] as being broken down to unit queries, and entities involved therein. The database decomposition system 120 further updates the metadata table 370 resulting from block 210 based on transaction heuristics data collected from operations of the MDB system 110... [0057] The database decomposition system 120 creates the graph model 350 to minimize the number of entities to be presented as a node for the DDB 140, while providing the functionalities equivalent to the MDB 115. The database decomposition system 120 analyzes each table of the MDB 115 for a sign indicating if a table is an intermediate table or an intersection table as being presented in the MDB 115, by examining columns, specifically for primary keys, surrogate keys, and/or foreign keys.[0059-61] elaborates on the utilization of a metadatabase foreign key [87-94] further elaborate on the all the different queries and their ability to have different functions [FIG.8] shows the corresponding flow) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Sreenivasan in order to improve the overall performance of the database via a unique metadata table integration (Sreenivsasan [AB] clustering on the distributed database regarding aspects of performance, scalability, and availability that improves the aspects of the distributed database over the monolith database is performed and the distributed database is checked for eventual consistency amongst the distributed database and one or more replicas of the distributed database before deployed to replace the monolith database.[0031] to improve confidence in analyzing data objects... 130 would be improved over the MDB system 110 [0106] The database decomposition system 120 has updated the metadata table 370 with a new category values based on modeling of the unit query patterns accessing each table listed in the metadata table 370. In operations of block 250 described in FIG. 12, the database decomposition system 120 finalize division of the transactions for operations in the distributed database 140 and completes NFR modeling to improve scalability and availability of the distributed database 140 over the monolith database 115.)
Regarding claim 13, Demilo and Khillar teach The management method according to claim 1, further comprising: the combination lacks explicitly and orderly teaching when receiving a first query request, determining a metadatabase corresponding to a metadatabase foreign key from a first metadata table according to the first query request, the first query request carrying a table identifier, and the table identifier being associated with the metadatabase foreign key; when receiving a second query request, determining a metadata table corresponding to a metadata table foreign key from a second metadata table according to the second query request, the second query request carrying a column, and the column being associated with the metadata table foreign key. However Sreenvisasan teaches when receiving a first query request, determining a metadatabase corresponding to a metadatabase foreign key from a first metadata table according to the first query request, the first query request carrying a table identifier, and the table identifier being associated with the metadatabase foreign key; when receiving a second query request, determining a metadata table corresponding to a metadata table foreign key from a second metadata table according to the second query request, the second query request carrying a column, and the column being associated with the metadata table foreign key. (Sreenivasan [FIG.8] shows the corresponding flow [0029] The MDB system 110 includes an MDB 115 and an MDB application 113. As noted, the MDB system 110 is typically of monolithic and relational architecture, indicating that the MDB 115 includes all tables T1 . . . Tn, wherein n is a number of tables in the MDB 115, and that the MDB application 113 accesses the MDB 115 with transactions with a combination of queries Q1 . . . Qm, wherein m is a number of queries available in the MDB application 113. The MDB application 113 represents data service operations [0038] as being broken down to unit queries, and entities involved therein. The database decomposition system 120 further updates the metadata table 370 resulting from block 210 based on transaction heuristics data collected from operations of the MDB system 110... [0057] The database decomposition system 120 creates the graph model 350 to minimize the number of entities to be presented as a node for the DDB 140, while providing the functionalities equivalent to the MDB 115. The database decomposition system 120 analyzes each table of the MDB 115 for a sign indicating if a table is an intermediate table or an intersection table as being presented in the MDB 115, by examining columns, specifically for primary keys, surrogate keys, and/or foreign keys.[0059-61] elaborates on the utilization of a metadatabase foreign key [87-94] further elaborate on the all the different queries and their ability to have different functions) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Sreenivasan in order to improve the overall performance of the database via a unique metadata table integration (Sreenivsasan [AB] clustering on the distributed database regarding aspects of performance, scalability, and availability that improves the aspects of the distributed database over the monolith database is performed and the distributed database is checked for eventual consistency amongst the distributed database and one or more replicas of the distributed database before deployed to replace the monolith database.[0031] to improve confidence in analyzing data objects... 130 would be improved over the MDB system 110 [0106] The database decomposition system 120 has updated the metadata table 370 with a new category values based on modeling of the unit query patterns accessing each table listed in the metadata table 370. In operations of block 250 described in FIG. 12, the database decomposition system 120 finalize division of the transactions for operations in the distributed database 140 and completes NFR modeling to improve scalability and availability of the distributed database 140 over the monolith database 115.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARYAN D TOUGHIRY whose telephone number is (571)272-5212. The examiner can normally be reached Monday - Friday, 9 am - 5 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aleksandr Kerzhner can be reached at (571) 270-1760. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, 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.
/ARYAN D TOUGHIRY/Examiner, Art Unit 2165
/ALEKSANDR KERZHNER/Supervisory Patent Examiner, Art Unit 2165
Prosecution Insights