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 . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
DETAILED ACTION
The following NON-FINAL Office Action is in response communication filed on 5/13/2026.
Priority
The Examiner has noted the Applicants claiming Priority from Provisional Application 63/462,878 filed 04/28/2023.
Status of Claims
Claims 1, 4, 6-10, 13, 15-19, 22, 24-33 are currently pending.
Claims 2-3, 5, 11-12, 14, 20-21, 23 are cancelled.
Claims 1, 4, 7-10, 13, 16-19, 22, 25-30 are currently amended.
Claims 31-33 are newly added.
Claims 1, 4, 6-10, 13, 15-19, 22, 24-33 are currently under examination and have been rejected as follows.
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/13/2026 has been entered.
IDS
The information disclosure statements filed on 8/30/2024, 6/30/2025, 8/26/2025, 10/30/2025, 1/19/2026, 3/30/2026, 4/30/2026, 6/17/2026 comply with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and are considered by the Examiner.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Response to Amendment
The previously pending rejections under 35 USC 101 will be maintained. The 101 rejection is updated in view of the amendments.
The rejection under 35 USC 103 will be maintained. The 103 rejection is updated in view of the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Response to Arguments
Regarding Applicant’s remarks pertaining to 35 USC 101:
Step 2A Prong 1:
Applicant argues on page 16 of remarks 5/13/2026:
“Claim 1 does not recite any of the enumerated methods of organizing human activity…. While some of the claim recitations may relate to generating a stream of enriched usage data useable in contracts or business relations, those contracts and/or business relations are not recited in the claim. See, e.g., MPEP § 2106.04(a)(2)(1).”
Examiner respectfully disagrees. The claims may recite (literally) or describe or set forth an abstract idea to be directed to a judicial exception. The claims as amended still recite, describe, or set forth monitoring, measuring, evaluating, and communicating customer usage of provided resources and services by an enterprise, including examples such as “enrich raw usage data with corresponding enrichment metadata”, “extracting a stream of raw usage data representative of resource usage for a first cloud resource”, “generate a first chunk of enriched usage data”, “generating and transmitting a first stream of enriched usage data”. The claims as amended fall within agreements in the form of contracts and business relations as they pertain to commercial or legal interactions under the larger abstract grouping of Certain Methods of Organizing Human Activity (MPEP 2106.04(a)(2) II). Accordingly, the claims are directed to an abstract idea.
Step 2A Prong 2:
Applicant argues on page 18 of remarks 5/13/2026:
“Claim 1 recites a specific manner of reducing end-to-end latency and improving the computational efficiency of generating enriched usage data for cloud resources that provides a specific improvement over prior systems. See, e.g., Specification at [0007], [0149], [0150], [0167], [0168], and [0202].”
Examiner respectfully disagrees. It does not appear that any new additional computer-based elements were presented with the amendments to the claims. The functions of the previously presented additional elements include examples such as storing enrichment metadata, executing data enrichment, extracting raw cloud usage data for specified time intervals, selecting specific sets of enrichment metadata, joining raw usage data with enrichment metadata, and generating and transmitting streams of enriched cloud usage data. The additional elements and their functions are recited at a high level of generality (i.e. as a generic computer performing functions of gathering statistics; monitoring, organizing, aggregating, merging, and communicating data, etc.) such that they still amount to no more than mere instructions to apply the exception using generic computer components. While these functions may mitigate latency for preparing priced usage and invoices, insufficient technical details are provided for how raw data is extracted and enriched, how join operations are performed, etc. and thus how technical process steps are removed such that the latency is reduced by the additional elements’ functions, rendering an improvement over existing technology unclear. Therefore, these functions can be viewed as not meaningfully different than a business method or mathematical algorithm being applied on a general-purpose computer as tested per MPEP 2106.05(f)(2)(i).
Step 2B:
Applicant argues on page 20 of remarks 5/13/2026:
“…The chunk-wise enrichment process substantially reduces latency over prior systems (see, e.g., Specification at [0149] and [0202]), with a specific end-to-end latency that can be selected based on the configured chunk size (see, e.g., Specification at [0167] and [0168]).”
Examiner respectfully disagrees. As submitted above, while these functions may mitigate latency for preparing priced usage and invoices, insufficient technical details are provided for how raw data is extracted and enriched, how join operations are performed, etc. and thus how technical process steps are removed such that the latency is reduced, and specifically how selecting configured chunk sizes reduces latency, by the additional elements’ functions, rendering an improvement over existing technology unclear.
Applicant argues on page 20 of remarks 5/13/2026:
“Even if one or more additional elements are well-understood, routine, conventional activity when considered individually, the combination of additional elements may amount to an inventive concept….
“Because none of the four [Berkheimer test] options above are satisfied, the Examiner has failed to demonstrate that the elements recited in claim 1 are well-understood, routine, conventional activity.”
Examiner respectfully disagrees. Examiner’s original eligibility analysis did not rely upon establishing well-understood, routine, or conventional activities recited in the claims. The Berkheimer conventionality test is one option for examination among MPEP 2106.05(a)-(h), but not required. However, assuming arguendo, further evidence would be required to demonstrate conventionality of the additional, computer-based elements, Examiner would further rely on MPEP 2106.05(d) guidelines to demonstrate that said additional elements are also well-understood, routine, conventional. In such case, Examiner would rely as evidence on Applicant’s own Specification. Applicant Specification ¶ [0144] describes the general function of the additional elements cloud resource and cloud service system: “With some subscription plan management (SPM) cloud service systems, service teams generate regularly occurring reports on usage of cloud resources by customers The cloud resources may be grouped in compartments of the cloud service system that are accessible by designated customers associated with those compartments. The compartments define boundaries that may contain computer resources, database resources, block volume resources, and any other tools or services that might be made available by the cloud host to their customers associated with their respective compartments.” Applicant Specification ¶ [0151] goes on the describe the improvement to the business process, such as “de-serialize the processing and instead process the usage data immediately as it is streamed from the service teams by joining the customer raw resource usage data with entities comprising small metadata units representative of historic time series enrichment data”, and ¶ [0152]: “The entities comprising the small metadata units stored in the entity maps can be utilized to ensure that the raw resource usage data received from the service teams is properly enriched by joining the usage data with metadata units contained in the entity maps having time windows associated therewith that match the times of the use of the resources as indicated in the raw usage data.” However, these and other examples in the specification describe well known, routine or conventional cloud computing techniques such as extracting customer usage data from a cloud service, joining the raw data with metadata to create enriched data, and performing these functions in specific time intervals. The functions are recited in the claims and the specification at a high level of generality (see Applicant Specification ¶ [0243]: “In accordance with various embodiments, the teachings herein can be implemented using one or more computer, computing device, machine, or microprocessor, including one or more processors, memory and/or computer readable storage media programmed according to the teachings herein. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art”).
Furthermore, primary reference Moustafa and secondary reference Dageville reinforce the conventionality of technology described above (see 103 rejection below) as well as additional references Surendran et al., Sundaram et al., Glickman et al., Pinheiro et al., among others (see art made of record in conclusion).
Accordingly, the previously pending rejections under 35 USC 101 will be maintained. The 101 rejection is updated in view of the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Regarding Applicant’s remarks pertaining to 35 USC 103:
Applicant argues on page 24 of remarks 5/13/2026:
“…Thus, Dageville discusses using the most recent (active or future) pricing plan to generate incremental monetizer records. However, Dageville does not teach or disclose selecting a set of enrichment metadata based on determining that the first usage time parameter corresponds to a prior time window, either explicitly or inherently. Dageville does not disclose selecting any pricing plan other than the current pricing plan, "[b]ecause the data in the table 404F is at a daily granularity for generation of usage reports," Dageville at [0088].”
Examiner considers the claims as amended but finds the argument unpersuasive. Dageville continues at ¶ [0088] to disclose additional granularity options, such as monthly, and that “It should be noted that the incremental interval may be any appropriate time period (e.g., hour, two hours, a day, etc.) Examiner notes additional support from Dageville at ¶ [0057] disclosing selecting cloud usage data by time intervals, including prior time intervals: “The usage level for the set of jobs during the current incremental interval may be combined with a usage level of all previous incremental intervals of the current billing interval to generate a cumulative usage record. An invoice for the billing interval may be generated based on the cumulative usage record.”
Applicant argues on page 24 of remarks 5/13/2026:
“Moustafa does not remedy the deficiencies of Dageville. Moustafa is directed to monitoring data usage of AI applications to identify ethical divergences in data streams. However, as the Office acknowledged in its rejection of claim 1, Moustafa is silent regarding features relating to time windows, and thus could not teach or disclose selecting the first set of enrichment metadata based on determining that the first usage time parameter corresponds to the prior time window, as claimed.”
Examiner considers the claims as amended but finds the argument unpersuasive.
Although Moustafa teaches storing a dataset comprising enrichment metadata, extracting raw usage data from cloud resources, resource identification parameters, usage time parameters, and generating enriched metadata. Examiner relies upon Dageville to remedy the deficiencies of Moustafa, including storing unmodifiable datasets, and joining multiple raw usage data and enrichment metadata datasets as “chunks” with distinct and different time windows.
Examiner notes the additional amended claim limitations and presents additional support from Moustafa (Fig. 23, ¶ [0050], [0065], [0133], [0163], [0354]) and Dageville (¶ [0025], [0057], [0088], [0089], [0121]) which disclose the amended features. See 103 rejection section below for citations and additional details.
Accordingly, the rejection under 35 USC 103 will be maintained. The rejection is updated in view of the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4, 6-10, 13, 15-19, 22, 24-33 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1, 4, 6-9, 28, 31 are directed to a method or process which is a statutory category.
Claims 10, 13, 15-18, 29, 32 are directed to a system or machine which is a statutory category.
Claims 19, 22, 24-27, 30, 33 are directed to a non-transitory computer readable storage medium or article of manufacture which is a statutory category.
Step 2A Prong One: The claims recite, describe, or set forth a judicial exception of an abstract idea (see MPEP 2106.04(a)). Specifically, the claims recite, describe or set forth agreements in the form of contracts and business relations, including: “enrich raw usage data with corresponding enrichment metadata”, “extracting a stream of raw usage data representative of resource usage for a first cloud resource of the cloud service system, a first chunk of raw usage data for the first cloud resource”, “the first chunk of raw usage data comprising (a) a first resource identification parameter that identifies the first cloud resource from among a plurality of cloud resources available in the cloud service system, and (b) a first usage time parameter corresponding to usage of the first cloud resource”, “selecting the first set of enrichment metadata based on determining that (a) the first cloud resource is within the set of cloud resources and (b) the first usage time parameter corresponds to the prior time window”, “performing a database join operation on the first set of enrichment metadata and the first chunk of raw usage data to generate a first chunk of enriched usage data”, and “generating and transmitting a first stream of enriched usage data comprising the first chunk of enriched usage data”. Monitoring, measuring, evaluating, and communicating customer usage of provided resources and services by an enterprise fall within agreements in the form of contracts and business relations as they pertain to commercial or legal interactions under the larger abstract grouping of Certain Methods of Organizing Human Activity (MPEP 2106.04(a)(2) II). Accordingly, the claims are directed to an abstract idea.
Step 2A Prong Two: Independent claims 1, 10, 19 recite the following additional elements: “cloud resource”, “cloud service system”, “system”, “computer”, “processor device”, “non-transitory memory”, “non-transitory computer readable storage medium”, and “computer system”. The functions of these additional elements include storing enrichment metadata, executing data enrichment, extracting raw cloud usage data for specified time intervals, selecting specific sets of enrichment metadata, joining raw usage data with enrichment metadata, and generating and transmitting streams of enriched cloud usage data. The additional elements are recited at a high level of generality (i.e. as a generic computer performing functions of gathering statistics; monitoring, aggregating, merging, and communicating data, etc.) such that they amount to no more than mere instructions to apply the exception using generic computer components. Therefore, these functions can be viewed as not meaningfully different than a business method or mathematical algorithm being applied on a general-purpose computer as tested per MPEP 2106.05(f)(2)(i). The claims are directed to an abstract idea and the judicial exception does not integrate the abstract idea into a practical application.
Step 2B: According to MPEP 2106.05(f)(1), considering whether the claim recites only the idea of a solution or outcome i.e., the claims fail to recite the technological details of how the actual technological solution to the actual technological problem is accomplished. The recitation of claim limitations that attempt to cover an entrepreneurial and thus abstract solution to an entrepreneurial problem with no technological details on how the technological result is accomplished and no description of the mechanism for accomplishing the result do not provide significantly more than the judicial exception.
Dependent claims 6, 15, 24 recite the additional element “consumer processor device”. The additional element is also recited at a high level of generality (i.e. as a generic computer performing functions of processing and organizing data, being associated with a cloud service system, streaming usage data, etc.) such that it amounts to no more than mere instructions to apply the exception using generic computer components. Dependent claims 2-5, 7-9, 11-14, 16-18, 20-23, 25-30 do not appear to provide further additional computer-based elements, let alone for such additional computer-based elements to integrate the abstract idea into practical application (Step 2A prong two) or providing significantly more (Step 2B).
Further, dependent claims 3-4, 7-9, 12-13, 16-18, 21-22, 25-30 merely incorporate the additional elements recited in claims 1, 10, 19 along with further narrowing of the abstract idea of claims 1, 10, 19 and their execution of the abstract idea. Specifically, the dependent claims narrow the “cloud resource”, “cloud service system”, “system”, “computer”, “processor device”, “non-transitory memory”, “non-transitory computer readable storage medium”, and “computer system” to capabilities such as selecting, joining, generating, indicating, associating, comprising, receiving, refreshing, storing, and adding various forms of data such as enrichment metadata, usage time parameters, time windows, time-series data, datasets, enriched usage data, streams, use times, boundary identification parameters, resource identification parameters, item values, etc. which, when evaluated per MPEP 2106.05(f)(2) represent mere invocation of computers to perform existing processes. Therefore, the additional elements recited in the claimed invention individually and in combination fail to integrate a judicial exception into a practical application (Step 2A prong two) and for the same reasons they also fail to provide significantly more (Step 2B). Thus, claims 1, 4, 6-10, 13, 15-19, 22, 24-33 are reasoned to be patent ineligible.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
REJECTIONS BASED ON PRIOR ART
Examiner Note: Some rejections will contain bracketed comments preceded by an “EN” that will denote an examiner note. This will be placed to further explain a rejection.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 of this title, 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.
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.
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.
Claims 1, 4, 6-10, 13, 15-19, 22, 24-33 are rejected under 35 U.S.C. 103 as being unpatentable over:
Moustafa US 20220335340 A1, hereinafter Moustafa in view of
Dageville US 20230316348 A1, hereinafter Dageville. As per,
Regarding Claims 1, 10, 19:
Moustafa teaches:
(Claim 1) A method, comprising:
(Claim 10) A system, comprising:
(Claim 19) A non-transitory computer readable storage medium having instructions thereon, which when performed in a computer system including a processor device operatively coupled the non-transitory computer readable storage medium cause the computer to perform steps comprising:
storing a [..] dataset comprising (a) [..] enrichment metadata [..] for a set of cloud resources of a cloud service system and (b) [..] enrichment metadata [..] for the set of cloud resources, [..] (Moustafa ¶ [0106]: The ADM system 600 includes an example resource manager 642 and an example distributed datastore 644, which includes an example metadata storage 646, and an example raw data store 648. ¶ [0057]: the ADM system may evaluate (e.g., continuously evaluate) data within one or more non target data streams to establish a baseline pattern (e.g., a nominal pattern, etc.) of one or more data streams being consumed by other Al application nodes over time. ¶ [0065]: the ADM system may utilize a number of types of attributes to classify data and metadata. For example, sensor inputs, times and dates, classifications of visual objects in a video feed, chains of receivership, blockchaining for security, among other attributes to support a trusted “paper trail” for data use and ownership); and
[..]
the [..] enrichment process comprising:
[..]
extracting, from a stream of raw usage data representative of resource usage for a first cloud resource of the cloud service system, [..] raw usage data for the first cloud resource (See Moustafa Fig. 14 element 1438: Central Node/Cloud (DDI Manager) [EN: cloud service system]. ¶ [0325]: The example machine readable instructions and / or the example operations 2500 of FIG. 25 begin at block 2502, at which the data usage monitoring circuitry 1300 instantiates / deploys a DDI node. For example, the resource manager orchestration circuitry 1304 can orchestrate resources in the edge environment to instantiate a DDI node…. In some examples, the DDI node is a virtual node [EN: cloud resource] that is instantiated within another physical node. For example, the resource manager orchestration circuitry 1304 can deploy a virtual DDI node into the AI application node that is to be tracked. ¶ [0326]: At block 2504, the data usage monitoring circuitry 1300 ingests network traffic [EN: raw usage data] (e.g., ingests data in data streams in the network traffic) at the DDI node. For example, the interface circuitry 1302 (FIG. 13) can ingest [EN: extract] data, such as video data or audio data. [Also see Fig. 25 element 2504: Ingest network traffic at DDI node over period of time; and Figs. 13, 14, 25 and related text]), the [..] raw usage data comprising:
(a) a resource identification parameter that identifies the first cloud resource from among a plurality of cloud resources available in the cloud service system (Moustafa ¶ [0050]: In some examples, the content type of a data stream, a sensitive attribute of a data stream, a security level of a data stream, a source location of a source node sourcing the data stream, etc., may be described as such characteristics within the data stream. For example, flags associated with such characteristics may be in the headers of data packets within the data stream. In some examples, data within the data stream may be tagged with metadata describing such characteristics. In some examples, data analysis logic within one or more nodes with access to the data stream may determine such data stream characteristics (e.g., characteristics regarding the content type of a data stream, a sensitive attribute of a data stream, a security level of a data stream, a source location of a data stream [EN: resource ID parameter], etc.) by analyzing the data in the data stream (e.g., analyzing a data payload within one or more data packets in the data stream). [Also see Fig. 23 element 2302: determine a service type attribute of the AI application node; and element 2304: determine a usage context of the AI application node; and related text]), and
(b) a [..] usage time parameter that indicates the reported [..] time (Moustafa ¶ [0065]: the ADM system may utilize a number of types of attributes [EN: parameters] to classify data and metadata. For example, sensor inputs, times and dates, classifications of visual objects in a video feed, chains of receivership, blockchaining for security, among other attributes to support a trusted “paper trail” for data use and ownership);
[..]
performing a [..] operation on the [..] set of enrichment metadata and the [..] raw usage data to generate [..] enriched usage data (Moustafa ¶ [0354]: At block 2904, the data usage monitoring circuitry 1300, based on policy 1322, may tag data in the target data stream with metadata for tracking. For example, the DRM circuitry 1318 may tag data in the target data stream with metadata tags corresponding to tracking information about the time, date, source location, ownership of the data, identification of target AI application node attempting the consumption, and / or other types of tags); and
generating and transmitting a [..] stream of enriched usage data comprising the [..] enriched usage data (Moustafa mid-¶ [0163]: For example, a first one of the edge switches 804 may observe 10% of the edge network environment 800 and a second one of the edge switches 804 may observe 90% of the edge network environment 800, which may become the basis for the differences in data outputs generated by the algorithms 638 executed by the first and second one of the devices. In some such examples, the first one of the devices may transmit and/or otherwise propagate data outputs from its execution of the algorithms 638 to the second one of the devices),
extracting, from the stream of raw usage data representative of resource usage for a first
cloud resource of the cloud service system [..] raw usage data for the first cloud resource (Moustafa ¶ [0133]: In the illustrated example , the ADM system 600 includes the metadata / data enrichment manager 640 to schedule and / or execute metadata creation and / or post processing routines intended to extract context and meaning from the source stream / files to enhance source files to decrease noise and / or clarify / focus subjects of interest), the [..] raw usage data comprising:
(a) a [..] resource identification parameter that identifies the first cloud resource from among the plurality of cloud resources available in the cloud service system (Moustafa ¶ [0050]: In some examples, the content type of a data stream, a sensitive attribute of a data stream, a security level of a data stream, a source location of a source node [EN: cloud resource among a plurality of resources] sourcing the data stream, etc., may be described as such characteristics within the data stream. For example, flags associated with such characteristics may be in the headers of data packets within the data stream. In some examples, data within the data stream may be tagged with metadata describing such characteristics. In some examples, data analysis logic within one or more nodes with access to the data stream may determine such data stream characteristics (e.g., characteristics regarding the content type of a data stream, a sensitive attribute of a data stream, a security level of a data stream, a source location of a data stream [EN: resource ID parameter], etc.) by analyzing the data in the data stream (e.g., analyzing a data payload within one or more data packets in the data stream). [Also see Fig. 23 element 2302: determine a service type attribute of the AI application node; and element 2304: determine a usage context of the AI application node; and related text]), and
(b) a [..] usage time parameter corresponding to usage of the [..] cloud resource, wherein the [..] usage time parameter corresponds to the current time window (Moustafa ¶ [0065]: the ADM system may utilize a number of types of attributes [EN: parameters] to classify data and metadata. For example, sensor inputs, [EN: current] times and dates, classifications of visual objects in a video feed, chains of receivership, blockchaining for security, among other attributes to support a trusted “paper trail” for data use and ownership);
[..]
performing a [..] operation on the [..] set of enrichment metadata and the [..] raw usage data to generate [..] enriched usage data (Moustafa ¶ [0354]: At block 2904, the data usage monitoring circuitry 1300, based on policy 1322, may tag data in the target data stream with metadata for tracking. For example, the DRM circuitry 1318 may tag data in the target data stream with metadata tags corresponding to tracking information about the time, date, source location, ownership of the data, identification of target AI application node attempting the consumption, and / or other types of tags); and
generating and transmitting a [..] stream of enriched usage data comprising the [..] enriched usage data (Moustafa mid-¶ [0163]: For example, a first one of the edge switches 804 may observe 10% of the edge network environment 800 and a second one of the edge switches 804 may observe 90% of the edge network environment 800, which may become the basis for the differences in data outputs generated by the algorithms 638 executed by the first and second one of the devices. In some such examples, the first one of the devices may transmit and/or otherwise propagate data outputs from its execution of the algorithms 638 to the second one of the devices).
Although Moustafa teaches storing a dataset comprising enrichment metadata, extracting raw usage data from cloud resources, resource identification parameters, usage time parameters, and generating enriched metadata, Moustafa does not specifically teach storing unmodifiable datasets, nor joining multiple raw usage data and enrichment metadata datasets as “chunks” with distinct and different time windows.
However, Dageville in analogous art of enriching cloud usage data teaches or suggests:
storing a semi-immutable dataset that prevents modification of data once stored in the semi-immutable dataset (Dageville mid-¶ [0025]: In particular embodiments, to load data into the cloud computing platform 110, data tables may be horizontally partitioned into large, immutable files which may be analogous to blocks or pages in a traditional database system),
the semi-immutable dataset comprising (a) a first set of enrichment metadata corresponding to a prior time window for a set of cloud resources of a cloud service system and (b) a second set of enrichment metadata corresponding to a current time window for the set of cloud resources, wherein the prior time window is earlier than the current time window, and wherein the first set of enrichment metadata is different from the second set of enrichment metadata (Dageville end ¶ [0057]: The usage level for the set of jobs during the current incremental interval [EN: current time window] may be combined with a usage level of all previous incremental intervals [EN: prior time windows] of the current billing interval to generate a cumulative usage record. An invoice for the billing interval may be generated based on the cumulative usage record. Mid-¶ [0088]: For example, if the incremental interval is a day, then there are on average 30 incremental intervals during a billing interval (a month in the current example). Thus, during each incremental interval [EN: different time periods], the monetizer 405 may monitor the usage level of each monetized listing during that incremental interval and store the usage of each monetized listing during that incremental interval in table 404F as an incremental monetizer record. More specifically, the monetizer 405 may read unprocessed data from the table 404E, and perform an enrichment to normalize the data in the table 404E, since the data in table 404E is at a daily granularity and only has the query counts, while the data in table 404F needs to have the fields from the pricing plan... It should be noted that the incremental interval may be any appropriate time period (e.g., hour, two hours, a day, etc…. For example, the monetizer 405's reading of raw data from the stream of the table 404A, extraction of the listing usage information, and storage of the result into table 404C may occur every 15 mins as data from the Job DPO 430 is imported every 15 mins, Meanwhile, the merging of the metadata received from the listing import DPO 440 into the table 404B may occur every hour as data from the listing import DPO 440 is imported once an hour));
executing, during the current time window, a chunk-wise enrichment process to enrich raw usage data with corresponding enrichment metadata (Dageville mid-¶ [0057]: The data warehousing and analysis module may calculate a usage level for a set of jobs processed using
the monetized data listing during a current incremental interval of a current billing interval. ¶ [0088]: …More specifically, the monetizer 405 may read unprocessed [EN: raw] data from the table 404E, and perform an enrichment to normalize the data in the table 404E, since the data in table 404E is at a daily granularity and only has the query counts, while the data in table 404F needs to have the fields from the pricing plan... It should be noted that the incremental interval [EN: chunk] may be any appropriate time period (e.g., hour, two hours, a day, etc…. For example, the monetizer 405's reading of raw data from the stream of the table 404A, extraction of the listing usage information, and storage of the result into table 404C may occur every 15 mins as data from the Job DPO 430 is imported every 15 mins, Meanwhile, the merging of the metadata received from the listing import DPO 440 into the table 404B may occur every hour as data from the listing import DPO 440 is imported once an hour)), the chunk-wise enrichment process comprising:
configuring a selected chunk size for the chunk-wise enrichment process based on a target end-to-end latency (Dageville end-¶ [0089]: the monetizer 405 may perform these tasks simultaneously and at any appropriate interval (e.g., on an hourly basis) and may tune the interval as necessary based on data volume and latency change);
[..]
selecting the first set of enrichment metadata based on determining that (a) the first cloud
resource is within the set of cloud resources and (b) the first usage time parameter corresponds to the prior time window (Dageville ¶ [0027]: Query processing 130 may handle query execution within elastic clusters of virtual machines, referred to herein as virtual warehouses or data warehouses…. The virtual warehouses 131 may be one or more virtual machines operating on the cloud computing platform 110. End- ¶ [0057]: The usage level for the set of jobs during the current incremental interval may be combined with a usage level of all previous incremental intervals of the current billing interval to generate a cumulative usage record. Mid-¶ [0085]: …the monetizer 405 may schedule a price plan extraction task to run at regular intervals (e.g., every hour or more frequently) which will retrieve all the latest versions of the metadata for each monetized listing from the table 404B. This task may run at any appropriate interval (e.g., on an hourly basis). The monetizer 405 may then determine for each monetized listing, whether there is a price entry for the current month in table 404D. Mid-¶ [0086]: For each identified monetized listing (identified based on import IDs), the monetizer 405 may look up the corresponding entry in the listing import DPO 440, and obtain the pricing plan for that monetized listing. If the monetizer 405 determines that the job ID corresponds to the first query [EN: see Fig. 1A query processing with set of ‘virtual warehouse’ cloud resources] in the current billing interval, then the monetizer 405 may add a fixed price charge and then add a per-query charge for each subsequent use of the monetized listing);
performing a database join operation on the first set of enrichment metadata and the first chunk of raw usage data to generate a first chunk of enriched usage data (Dageville mid-¶ [0012]: Data cleaning, de-identification, aggregation, joining, and other forms of data enrichment need to be performed by the owner of data before it is shareable with another party. Mid-¶ [0016]: In addition, participants in a private ecosystem data exchange may work together to join their datasets [EN: chunks of raw data] together to jointly create a useful data product [EN: chunk of enriched data] that any one of them alone would not be able to produce. Once these joined datasets are created, they may be listed on the data exchange or on the data marketplace. End-¶ [0033]: In addition, database operations (joining, aggregating, analysis, etc.) ascribed to a user (consumer or provider) shall be understood to include performing of such actions by the cloud computing service 112 in response to an instruction from that user);
[..]
extracting [..] raw usage data having the selected chunk size (Dageville end-¶ [0089]: …the monetizer 405 may perform these tasks simultaneously and at any appropriate interval (e.g., on an hourly basis) and may tune [EN: select] the interval as necessary based on data volume [EN: size] and latency change);
selecting the second set of enrichment metadata based on determining that (a) the first cloud resource is within the set of cloud resources and (b) the second usage time parameter corresponds to the current time window (Dageville ¶ [0027]: Query processing 130 may handle query execution within elastic clusters of virtual machines, referred to herein as virtual warehouses or data warehouses…. The virtual warehouses 131 may be one or more virtual machines operating on the cloud computing platform 110. Mid-¶ [0085]: …the monetizer 405 may schedule a price plan extraction task to run at regular intervals (e.g., every hour or more frequently) which will retrieve all the latest versions [EN: multiple sets] of the metadata for each monetized listing from the table 404B. This task may run at any appropriate interval (e.g., on an hourly basis). The monetizer 405 may then determine for each monetized listing, whether there is a price entry for the current month in table 404D. Mid-¶ [0086]: For each identified [EN: multiple] monetized listing (identified based on import IDs), the monetizer 405 may look up the corresponding entry in the listing import DPO 440, and obtain the pricing plan for that monetized listing. If the monetizer 405 determines that the job ID corresponds to the first query [EN: see Fig. 1A query processing with set of ‘virtual warehouse’ cloud resources] in the current billing interval, then the monetizer 405 may add a fixed price charge and then add a per-query charge for each subsequent [EN: multiple] use of the monetized listing);
performing a database join operation on the second set of enrichment metadata and the second chunk of raw usage data to generate a second chunk of enriched usage data (Dageville mid-¶ [0012]: Data cleaning, de-identification, aggregation, joining, and other forms of data enrichment need to be performed by the owner of data before it is shareable with another party. Mid-¶ [0016]: In addition, participants in a private ecosystem data exchange may work together to join their datasets [EN: chunks of raw data] together to jointly create a useful data product [EN: chunk of enriched data] that any one of them alone would not be able to produce. Once these joined datasets are created, they may be listed on the data exchange or on the data marketplace. End-¶ [0033]: In addition, database operations (joining, aggregating, analysis, etc.) ascribed to a user (consumer or provider) shall be understood to include performing of such actions by the cloud computing service 112 in response to an instruction from that user);
[..].
Dageville and Moustafa are found as analogous art of enriching cloud usage data. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Moustafa’s data usage monitoring system, apparatus, and method to have included Dageville’s teachings around data enrichment applied to specific chunks of data streams and time windows. The benefit of these additional features would have reduced costs and latency for customers (Dageville ¶ [0012]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Moustafa in view of Dageville (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of enriching cloud usage data. In such combination each element would have merely performed the same function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Moustafa in view of Dageville above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claims 2, 11, 20: cancelled.
Regarding Claims 3, 12, 21: cancelled.
Regarding Claims 4, 13, 22: Moustafa / Dageville teaches all the limitations of claims 1, 10, 19 above.
Although Moustafa teaches enriching streams of usage data with metadata, Moustafa does not specifically teach determining a specific time window for the enrichment.
However, Dageville in analogous art of enriching cloud usage data teaches or suggests:
wherein selecting the second set of enrichment metadata is further based on determining that the second usage time parameter corresponds to the current time window (Dageville mid-¶ [0088]: For example, if the incremental interval is a day, then there are on average 30 incremental intervals during a billing interval (a month in the current example). Thus, during each incremental interval [EN: different time periods], the monetizer 405 may monitor the usage level of each monetized listing during that incremental interval and store the usage of each monetized listing during that incremental interval in table 404F as an incremental monetizer record. More specifically, the monetizer 405 may read unprocessed data from the table 404E, and perform an enrichment to normalize the data in the table 404E, since the data in table 404E is at a daily granularity and only has the query counts, while the data in table 404F needs to have the fields from the pricing plan... It should be noted that the incremental interval may be any appropriate time period (e.g., hour, two hours, a day, etc…. For example, the monetizer 405's reading of raw data from the stream of the table 404A, extraction of the listing usage information, and storage of the result into table 404C may occur every 15 mins as data from the Job DPO 430 is imported every 15 mins, Meanwhile, the merging of the metadata received from the listing import DPO 440 into the table 404B may occur every hour as data from the listing import DPO 440 is imported once an hour)).
Rationales to have modified / combined Moustafa / Dageville are above in claim 1, 10, 19 and reincorporated.
Regarding Claims 5, 14, 23: cancelled.
Regarding Claims 6, 15, 24: Moustafa / Dageville teaches all the limitations of claims 1, 10, 19 above.
Moustafa further teaches:
wherein the first cloud resource is held in a first cloud boundary of the cloud service system available to an associated consumer processor device affiliated with the first cloud boundary, wherein the first chunk of raw usage data comprises a boundary identification parameter that identifies the first cloud boundary holding the first cloud resource (Moustafa ¶ [0085]: It should be understood that some of the devices in 410 are multi-tenant devices where Tenant 1 may function within a tenant1 ‘slice' while a Tenant 2 may function within a tenant2 slice…. A trusted multi-tenant device may further contain a tenant specific cryptographic key such that the combination of key and slice may be considered a “root of trust” (RoT) or tenant specific RoT. A RoT may further be computed dynamically composed using a DICE ([EN: consumer] Device Identity Composition Engine) architecture. Mid-¶ [0086]: Cloud computing nodes often use containers [EN: cloud boundaries], FaaS engines, servlets, servers, or other computation abstraction that may be partitioned according to a DICE layering and fan-out structure [EN: boundary identification parameter] to support a RoT context for each), and
wherein selecting the first set of enrichment metadata is further based on the boundary identification parameter (Moustafa ¶ [0354]: At block 2904, the data usage monitoring circuitry 1300, based on policy 1322, may tag data in the target data stream with metadata for tracking. For example, the DRM circuitry 1318 may tag data in the target data stream with metadata tags corresponding to tracking information about the time, date, source location, ownership of the data, identification of target AI application node attempting the consumption, and / or other types of tags [EN: boundary identification parameters discussed in previous limitation]).
Regarding Claims 7, 16, 25: Moustafa / Dageville teaches all the limitations of claims 1, 10, 19 above.
Moustafa further teaches:
refreshing the semi-immutable dataset by:
receiving updated value data representative of an updated value of an item of the first set of enrichment metadata or the second set of enrichment metadata (Moustafa ¶ [0114]: In the illustrated example, the ADM system 600 includes the data publishing manager 618 to implement publish - subscribe messaging. For example, a subscriber (e.g., a data subscriber, a device subscriber, etc.) may coordinate with the scheduler 620 to subscribe to [EN: and thus receive] changes, updates, etc., of data of the metadata storage 646, the raw datastore 648, and / or one (s) of the data sources 604 [EN: first or second]);
[..]
storing the updated value data [..] in the semi-immutable dataset by adding the updated value data [..] to the semi-immutable dataset as a third set of enrichment metadata (Moustafa ¶ [0294]: If, at block 2010, the data usage monitoring circuitry 1300 determines to update the baseline data based on the outputs, control proceeds to block 2012. At block 2012, the data usage monitoring circuitry 1300 updates the base line data in a datastore based on the outputs. ¶ [0410]: …wherein the instructions… instantiate a first super node in the edge environment, and deploy a second instantiation of the machine learning model to the first super node, execute the second instantiation of the machine learning model based on a first plurality of data streams within network traffic ingested at the first super node to generate one or more second outputs, the one or more second outputs including values representative of data stream characteristics and values representative of AI application node characteristics, share the one or more second outputs with a second super node in the edge environment, obtain one or more third outputs from the second super node, the one or more third outputs generated from a third instantiation of the machine learning model executed at the second super node based on a second plurality of data streams within network traffic ingested at the second super node, the one or more third outputs including values representative of data stream characteristics and values [EN: metadata] representative of AI application node characteristics, and train the machine learning model using at least one of the one or more second outputs or the one or more third outputs to build a consensus nominal data stream pattern).
Although Moustafa teaches receiving and storing updated enrichment metadata as a third set of enrichment metadata, Moustafa does not specifically teach associating the update with a time window or storing updated time window data.
However, Dageville in analogous art of enriching cloud usage data teaches or suggests:
associating the updated value of the item with an updated time window defined by updated time window data (Dageville end-¶ [0035]: Other information included in the metadata 204 may be metadata for use by business intelligence tools, text description of data contained in the table, keywords associated with the table to facilitate searching, a link (e.g., URL) to documentation related to the shared data, and a refresh interval indicating how frequently the shared data is updated along with the date [EN: time window] the data was last updated. ¶ [0080]: updated on: this field provides a timestamp of the last update);
storing the updated value data in association with the updated time window data in the dataset by adding [..] the updated time window data to the dataset [..] (Dageville end-¶ [0035]: Other information included in the metadata 204 may be metadata for use by business intelligence tools, text description of data contained in the table, keywords associated with the table to facilitate searching, a link (e.g., URL) to documentation related to the shared data, and a refresh interval indicating how frequently the shared data is updated along with the date [EN: time window] the data was last updated. ¶ [0080]: updated on: this field provides a timestamp of the last update).
Dageville and Moustafa are found as analogous art of enriching cloud usage data. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Moustafa’s data usage monitoring system, apparatus, and method to have included Dageville’s teachings around associating updates with a time window and storing updated time window data. The benefit of these additional features would have reduced costs and latency for customers (Dageville ¶ [0012]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Moustafa in view of Dageville (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of enriching cloud usage data. In such combination each element would have merely performed the same function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Moustafa in view of Dageville above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claims 8, 17, 26: Moustafa / Dageville teaches all the limitations of claims 7, 16, 25 above.
Moustafa further teaches:
performing a [..] operation on the [..] set of enrichment metadata and the [..] raw usage data to generate [..] enriched usage data, wherein the [..] stream of enriched usage data comprises [..] enriched usage data (Moustafa ¶ [0354]: At block 2904, the data usage monitoring circuitry 1300, based on policy 1322, may tag data in the target data stream with metadata for tracking. For example, the DRM circuitry 1318 may tag data in the target data stream with metadata tags [EN: updated values] corresponding to tracking information about the time, date, source location, ownership of the data, identification of target AI application node attempting the consumption, and / or other types of tags).
Although Moustafa teaches storing a dataset comprising enrichment metadata, extracting raw usage data from a cloud resource, resource identification parameters, usage time parameters, and generating enriched metadata, Moustafa does not specifically teach multiple raw usage data and enrichment metadata datasets as “chunks” with distinct and different time windows.
However, Dageville in analogous art of enriching cloud usage data teaches or suggests:
performing a database join operation on the third set of enrichment metadata and a third
chunk of raw usage data extracted from the stream of raw usage data to generate a third chunk of enriched usage data, wherein the first stream of enriched usage data comprises the third chunk of enriched usage data (Dageville mid-¶ [0012]: Data cleaning, de-identification, aggregation, joining, and other forms of data enrichment need to be performed by the owner of data before it is shareable with another party. Mid-¶ [0016]: In addition, participants in a private ecosystem data exchange may work together to join their datasets [EN: chunks of raw data] together to jointly create a useful data product [EN: chunk of enriched data] that any one of them alone would not be able to produce. Once these joined datasets are created, they may be listed on the data exchange or on the data marketplace. End-¶ [0033]: In addition, database operations (joining, aggregating, analysis, etc.) ascribed to a user (consumer or provider) shall be understood to include performing of such actions by the cloud computing service 112 in response to an instruction from that user. Mid-¶ [0085]: …the monetizer 405 may schedule a price plan extraction task to run at regular intervals (e.g., every hour or more frequently) which will retrieve all the latest versions [EN: multiple sets, first, second, third, etc.] of the metadata for each monetized listing from the table 404B.)
Rationales to have modified / combined Moustafa / Dageville are above in claims 3, 12, 21 and reincorporated.
Regarding Claims 9, 18, 27: Moustafa / Dageville teaches all the limitations of claims 1, 10, 19 above.
Moustafa further teaches:
wherein the semi-immutable dataset comprises an entity map dataset (Moustafa mid-¶ [0056]: In some examples, the ADM system may utilize Artificial Intelligence / Machine Learning (AI / ML) modeling techniques and / or data graph techniques to map, associate, and / or otherwise correlate relevant datasets to one another. For example, in order to determine whether consumption / usage of the data in the data stream is ethical, comparisons of the target AI application node's consumption / usage (or attempts thereof) of the data stream to (known ethical) baseline / nominal consumption / usages from other Al application nodes may be implemented through the AI / ML modeling techniques and / or data graph techniques).
Regarding Claims 28, 29, 30: Moustafa / Dageville teaches all the limitations of claims 1, 10, 19 above.
Although Moustafa teaches storing a dataset comprising enrichment metadata and generating enriched metadata, Moustafa does not specifically teach selecting enrichment data by distinguishing between time windows.
However, Dageville in analogous art of enriching cloud usage data teaches or suggests:
wherein the first set of enrichment data is further selected based on determining that the first usage time parameter does not correspond to the current time window (Dageville mid-¶ [0085]: …the monetizer 405 may schedule a price plan extraction task to run at regular intervals (e.g., every hour or more frequently) which will retrieve all the latest versions of the metadata for each monetized listing from the table 404B. This task may run at any appropriate interval (e.g., on an hourly basis). The monetizer 405 may then determine for each monetized listing, whether there is a price entry for the current month in table 404D. Mid-¶ [0086]: For each identified monetized listing (identified based on import IDs), the monetizer 405 may look up the corresponding entry in the listing import DPO 440, and obtain the pricing plan for that monetized listing. If the monetizer 405 determines that the job ID corresponds to the first query in the current billing interval [EN: distinguishing between time windows], then the monetizer 405 may add a fixed price charge and then add a per-query charge for each subsequent use of the monetized listing).
Dageville and Moustafa are found as analogous art of enriching cloud usage data. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Moustafa’s data usage monitoring system, apparatus, and method to have included Dageville’s teachings around distinguishing between time windows when generating enriched metadata. The benefit of these additional features would have reduced costs and latency for customers (Dageville ¶ [0012]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Moustafa in view of Dageville (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of enriching cloud usage data. In such combination each element would have merely performed the same function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Moustafa in view of Dageville above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claims 31, 32, 33: Moustafa / Dageville teaches all the limitations of claims 1, 10, 19 above.
Although Moustafa teaches storing a dataset comprising enrichment metadata and generating enriched metadata, Moustafa does not specifically teach auto-incrementing resource parameters or separating operations by a buffer time.
However, Dageville in analogous art of enriching cloud usage data teaches or suggests:
wherein the first resource identification parameter and the second resource identification parameter are generated based on an auto-incremented identification (Dageville mid-¶ [0088]: For example, if the incremental interval is a day, then there are on average 30 incremental intervals during a billing interval (a month in the current example). Thus, during each incremental interval, the monetizer 405 may monitor the usage level of each monetized listing during that incremental interval and store the usage of each monetized listing during that incremental interval in table 404F as an incremental monetizer record), and
wherein extracting the first chunk of raw usage data and extracting the second chunk of raw usage data are separated by at least a specified buffer time (Dageville mid-¶ [0121]: Although the method operations were described in a specific order, it should be understood that other operations may be performed in between described operations, described operations may be adjusted so that they occur at slightly different times or the described operations may be distributed in a system which allows the occurrence of the processing operations at various intervals associated with the processing).
Dageville and Moustafa are found as analogous art of enriching cloud usage data. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Moustafa’s data usage monitoring system, apparatus, and method to have included Dageville’s teachings around auto-incrementing resource parameters and separating operations by a buffer time. The benefit of these additional features would have reduced costs and latency for customers (Dageville ¶ [0012]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Moustafa in view of Dageville (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of enriching cloud usage data. In such combination each element would have merely performed the same function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Moustafa in view of Dageville above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
The following art is made of record and considered pertinent to Applicant’s disclosure:
Chasman; Mike et al. US 20200014659 A1, System and method for midserver facilitation of long-haul transport of telemetry for cloud-based services.
Pinheiro; Ralph Joseph et al. US 20220103618 A1, Data pipeline architecture.
Yanamandra; Sangeetha et al. US 20200117757 A1, Real-time monitoring and reporting systems and methods for information access platform.
Kothari; Ankit et al. US 20220091947 A1, Systems and methods for performing a technical recovery in a cloud environment.
Suttle; Scott et al. US 20230342179 A1, Compliance across multiple cloud environments.
Sundaram et al. US 20190166007 A1, Efficiency Indexes.
Surendran et al. US 20150172369 A1, Method and system for iterative pipeline.
Glickman; Matthew J. et al. US 20230385286 A1, Overlap results data generation on a cloud data platform
Ji; Chaoping et al. US 20210279109 A1, Method and apparatus for acquiring information.
Dageville; Benoit et al. US 20230316348 A1, Usage monitoring and usage based data pricing.
Jiang; Xiaoxiao et al. US 20180219784 A1, Traffic control platform.
Cooley; Shaun et al. US 20220150124 A1, Automatic discovery of automated digital systems through link salience.
Seetharaman; Ganesh et al. US 20180052861 A1, System and method for metadata-driven external interface generation of application programming interfaces.
Podder; Soumyajit US 20240320240 A1, System for consolidating data attributes for optimizing data processing and a method thereof.
Ferris; James Michael et al. US 20130304925 A1, Cloud deployment analysis featuring relative cloud resource importance.
Kisser; Lauren M et al. US 11720536 B1, Data enrichment as a service.
Cannaliato; Thomas James et al. US 9092502 B1, System and method for correlating cloud-based big data in real-time for intelligent analytics and multiple end uses.
Abdul Rasheed et al. WO 2021174104 A1, Modification of data in a time-series data lake.
S. Singh and Y. Liu, "A cloud service architecture for analyzing big monitoring data," in Tsinghua Science and Technology, vol. 21, no. 1, pp. 55-70, Feb. 2016, doi: 10.1109/TST.2016.7399283
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Any inquiry concerning this communication or earlier communications from the examiner should be directed to REED M. BOND whose telephone number is (571) 270-0585. The examiner can normally be reached Monday - Friday 8:00 am - 5:00 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, Patricia Munson can be reached at (571) 270-5396. 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.
/REED M. BOND/Examiner, Art Unit 3624 July 16, 2026
/HAMZEH OBAID/Primary Examiner, Art Unit 3624
Prosecution Insights