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 11/20/2025 has been entered.
DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In virtue of the RCE filed 12/18/2025 and Amendment filed on 11/20/2025, wherein claims 1, 9, 10, 17, 18 are amended; claims 6, 7, 11, 12 are canceled; no claims are added. Thus, claims 1-5, 8-10, 13-20 are now pending, wherein claims 1, 10, 18 are recited in independent form.
Claim Interpretation
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art, without importing limitations from the specification. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is only limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
Response to Arguments
In the response of 11/20/2025 Applicant amends the claims such that the scope of the claims is altered in such a manner that a new grounds of rejection are applicable to the claims.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 18-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 18, claim 18 is amended to recite “A method for cellular communications observability of a cellular network system, the method comprising: generating data from a cellular network employing clusters created using a containerized application; collecting, using a platform as a service (PaaS) an observability framework (OBF)…”. The amendment comprises replacing OBF layer with observability framework (OBF). This amendment introduces language which fails to particularly point out and distinctly claim that which the Applicant regards as the invention with respect to the framework (what does it provide observation of? What constitutes the framework? what does claim 18, which is a method employing the use of OBF framework, require by the limitations?). Applicant as introduced the observability framework without adequately claiming the composition and details of the element. An observability framework has no well accepted meaning nor is well understood by one of ordinary skill in the art such that the term particularly points out and distinctly claim that which the Applicant regards as the invention. To overcome the rejection Applicant must add details to the claims which define the composition and functionality of an observability framework such that one of ordinary skill in the art would understand the metes and bounds of the terms use in context of the claim. Therefore claim 18 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, based on the added language. Dependent claims 19-20 depend on claim 18, and inherits the limitations noted above and fail to add any limitations which overcome the rejection. Therefore claims 18-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, based on the added language.
Claim Rejections - 35 USC § 103
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.
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.
Claim(s) 1-5, 8-10, 13-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 11,616,713 (D1) in view of US 2020/0028756 (D2) further in view of US 2022/0200869 (D3) further in view of US 2014/0351011 (D4).
Regarding Claim 1, as to the limitation “A cellular network system comprising” D1 teaches a method for cellular communications observability of a cellular network system, (see d1 Col 2 ln 23-28,) disclosing processing trace data of virtual network functions of a telecommunication network via a plurality of stream processing systems. In particular, examples of the present disclosure configure network functions to provide trace data (or "probe data"), which may comprise logs, events, packets, and metadata for correlation; d1 also discloses employing containerized applications (i.e. containerized VNFs) to deploy a cellular network that utilizes clusters for virtual network functions of the cellular network; (see d1 Col 2 ln 57-64) suggesting that it should also be noted that in accordance with the present disclosure, the term "virtual network function" (or "VNF"), may refer to both virtual machine (VM)-based VNFs, e.g., VNFs deployed as VMs, and containerized or container-based (VNFs), e.g., VNFs deployed as containers, such as within a Kubernetes infrastructure, or the like, also referred to as "cloud-native network functions" (CNFs). Col 6 ln 9-14, Network 105 may also include an additional NFVI 111. For instance, unit 121 may be hosted on NFVI 111, which may comprise host devices having the same or similar physical components as NFVI 113. In addition, NFVI 111 may reside in a same location or in different locations from NFVI 113. D1 suggests identifying a plurality of domains (i.e. domain/zones) of the cellular network, wherein the plurality of domains and comprise a core of the cellular network, physical hardware components of the cellular network, and the clusters; (see d1 Col 11 ln 41-43) wherein the CVES-HV format builds upon the VES-HV format and defines a set of new fields to support easy querying and filtering of trace data for troubleshooting. D1 suggests (see d1 Col 12 ln 8-11, 55-60) that the VES-HV header may already include fields for information such as event name, domain, event Id event type, nfc Naming Code, source Id, source Name, reporting Entity Id, reporting Entity Name, sequence number. It should be noted that insofar as stream processing systems 218 and 228 may correlate, aggregate, and define additional trace data (such as aggregate KPIs), the stream processing systems 218 and 228 may subscribe to multiple topics from different VNFs within the respective zones. D1 also suggest (see d1 Col 16 ln 1-4) that a VNF may support several Web API calls in a secure manner, each of which may have an option to be applied globally (as a flag) or a particular cluster/location ( e.g., with a fully qualified domain name (FQDN)) on-demand.) Format for the trace data includes domain or data is collected from particular zones.
As to the limitation “first storage configured to collect the data associated with operations of a cellular network and to store the data for a maximum threshold amount of time” d1 suggests collecting (i.e. storing), using an observability layer (see d1 Fig 2 & 3, Data Distribution Platform 236) of the cellular network, the data from the plurality of domains of the cellular network, (see d1 Col 2 ln 37-52) wherein the present disclosure may comprise a probing architecture in which virtual network functions (VNFs) are configured as the primary source of probing information (trace data). Data may be collected and written to a "shared message bus," or data distribution platform, e.g., Apache Kafka, Apache Pulsar. D1 also suggests (see d1 Col 18 ln 55-61), At step 320, the first stream processing system obtains the trace data of the plurality of VNFs in the first region, where the trace data is obtained from a data distribution platform of the telecommunication network, where the trace data is published in accordance with a topic to the data distribution platform by the plurality of VNFs, and where the first stream processing system comprises a subscriber to the topic, wherein the observability layer (Fig 2 & 3, Data Distribution Platform 236) is located on a public network of the cellular network and connected to at least one of the virtual network functions of the cellular network; (see d1 Col 4 ln 16-20) wherein the network 105 may alternatively or additional comprise components of a cellular core network, such as a Public Land Mobile Network (PLMN), a General Packet Radio Service (GPRS) core 20 network. D1 also suggests (see d1 Col 18 ln 55-61), At step 320, the first stream processing system obtains the trace data of the plurality of VNFs in the first region, where the trace data is obtained from a data distribution platform of the telecommunication network; wherein it is disclosed aggregating (i.e. a first storage storing data), by the observability layer (Fig 2 & 3, Data Distribution Platform 236), the data according to configuration information (i.e. schema) of the clusters (i.e. VNFs per location); (see d1 Col 3, ln 5-14) wherein all trace data is stored in open databases, or "data lakes," with open schemas and data formats. To deliver session related events, the present disclosure defines an extension of Open Network Automation Platform (ONAP) High Volume Virtual Event Streaming (HV-VES) event format schema/format to include primary keys and secondary keys used in troubleshooting. All trace data that is generated, transformed, stored, etc. is enforced to remain compatible with this schema. D1 also suggests (see d1 Col 8 ln 47-57) that the probe server may then forward the raw packets to a collector. A centralized service may then analyze the raw packets to generate performance indicators, logs, etc. As such, these VNFs may be configured, e.g., via probe configuration service 192, to collect, generate, create, transmit, and/or otherwise process probe/trace data, which may include packets, performance indicators, events, and/or logs. D1 suggests ingesting (i.e. process, filtering, joining, aggregating, sampling) the data in real-time from the observability layer using a streaming platform data store of the cellular network, (see d1 Col 8-9 ln 64-67, 1-8) wherein an associated one of the stream processing system(s) 196 (e.g., one that is assigned to the same zone as the VNF and the one of the data distribution platform(s) 194) may be configured as a "subscriber" to the "topic," and may thus obtain the trace data from the VNF (and similarly from other VNFs in the same zone, from the same or different topics). The one of the stream processing system(s) 196 from the same zone may additionally process the trace data from the VNF (and from other VNFs in the same zone), such as filtering, joining, aggregating, sampling, etc., and may generate KPIs, events, and/or logs, which may be added to the trace data. D1 also suggests (see d1 Col 18 ln 55-61), At step 320, the first stream processing system obtains the trace data of the plurality of VNFs in the first region, where the trace data is obtained from a data distribution platform of the telecommunication network, wherein the data is stored in a specified area of the streaming platform data store according to the configuration information and a type of the data; (see d1 Col 13 ln 50-54), Storage element(s) 250 and archive element(s) 260 manage storage retention as per configured policies ( e.g., number of hours/days of retention per type of trace data, per VNF type, etc.).
As to the limitation “wherein first use applications requiring data to be not older than the maximum threshold amount of time retrieve data directly from the first storage” d1 suggests receiving, at the streaming platform data store and from an application associated with the cellular network, a request for real-time data from short term storage; (see d1 Col 14 ln 9-24) wherein applications 299 may include automated services, as well as one or more user applications, e.g., for visualizing trace data, managing the collection and processing of trace data via the architecture 200, querying the trace data. The troubleshooting application may enable an operator to enter a request for all of the packets (e.g., trace data) 20 associated with the subscriber's connection setup, service requests, handover, etc., with appropriate timestamps. In case the raw packets are not available, the architecture 200 may still provide events and/or logs (e.g., trace data), which can be used to troubleshoot service issues and distributing (i.e. retrieve) the data (i.e. trace data, metrics, performance indicators) to the application (i.e. requesting application) from the streaming platform data store based on the request. D1 suggests (see d1 Col 14 ln 29-37) the application may direct the request to architecture 200 via 30 API 280 as a query/command such as: "RETRIEVE all messages/events for time in [t1,t2] where Fl=x and F2=y ... ", where t2 can be current time/ongoing/future time, t1 can be 30 days prior or older, etc. In one example, auxiliary queries may be generated based on results. It should be noted that the stream processing systems 218, 228, and 238 enable stream processing (including partial processing of queries, or processing of sub-queries. D1 also suggest (see d1 Col 15, ln 28-30) performance indicators may be included in trace data (e.g., as configured via the architecture 200, not necessarily in connection with any particular troubleshooting request). One or more of applications 299 may enable an operator to retrieve metrics for specific calls, generate batch mode reports, and so forth. D1 teaches on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network (see Col 8-9 ln 64-67, 1-8 & Col 18 ln 55-61) and storage/search of historical events (see d1 Col 13 ln 55-57). However, D1 is silent on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage.
D2 teaches, in the same field of endeavor, collecting network performance data from a number of network devices, Abstract. D2 also teaches on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network for short term storage that is separate from long term storage. (see d1 para. 0024) wherein system 100 includes the performance data storage layer 114 further storing at least a portion of the performance data portion 110 in the responsive memory location in response to an identified trigger event 113. For example, where a trigger event 113 is identified, in certain embodiments the performance data storage layer 114 may store a portion of the performance data portion 110 (e.g., performance data related to the trigger event 113) in the responsive memory location (e.g., a high performance database) where it would otherwise be sent to long-term storage.
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify D1 per D2 to include that using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage. It would have been advantageous as discussed above and thus have been motivation for one of ordinary skill in the art to combine d1 with d1, as it would allow the modified system to provide flexible storage options which allows for optimization of the storage layers (see d2 para. 0004). Therefore the prior art includes the element claimed although not necessarily in a single reference; with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. Wherein, one of ordinary skill in the art would have combined the elements as claimed by known methods, and that in combination, each element merely performed the same function as it does separately. Therefore, one of ordinary skill in the art would have recognized that the results of the combination were predictable, as both are exercised in the same field of endeavor (wireless communication) for similar purposes (data collection) using known techniques in a similar manner separate as together.
As to the limitation “maximum threshold amount of time” D1 teaches on ingesting the data in real-time from the observability layer and on the storage platform having export data platforms that vendor agnostic (see d1 Col 3 ln 1-5, Col 18 ln 55-61). d3 teaches, in the same field of endeavor, methods and systems for managing a plurality of cloud assets, Abstract.
D3, in an analogous art, teaches the system wherein the real data transport layer collects and stores data from a minimum of one day to a maximum of 7 days see D3 para. 01520 teaches utilizing a streaming service with a limited period of 1 to 7 days for time sensitive use cases to access data on a real time basis (see D3 paras 0564 and 0074 ) as well as accessing data in near real time.
It would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2 with d3 in order to provide the technical features to enable configuring the real data transport layer which collects and stores data in a time limited manner, as taught by d1-d2, and to do so for a minimum of one day to a maximum of 7 days, to improve performance for time sensitive use cases to access data on a real-time basis.
Furthermore, one of ordinary skill in the art would have been motivated in order to perform threat detection, requirement compliance and provide results of such operations in substantially real-time (see d3 paras. 0074 and 0564). Referring to the limitation “maximum threshold” d3, in an analogous art, teaches the system wherein the real data transport layer collects and stores data from a minimum of one day to a maximum of 7 days (see D3 para. 0152) suggesting utilizing a streaming service with a limited period of 1 to 7 days for time sensitive use cases to access data on a real time basis (see D3 paras 0564 and 0074) suggesting accessing data in near real time.
It would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2 with d3 in order to configure the real data transport layer which collects and stores data, as taught by d1-d2, to do so for a minimum of one day to a maximum of 7 days, for time sensitive use cases to access data on a real-time basis.
Wherein, one of ordinary skill in the art would have been motivated in order to perform threat detection, requirement compliance and provide results of such operations in substantially real-time (see D3 paras 0074 and 0564).
Regarding thresholds, D4, in an analogous art, teaches the system wherein the data lake layer collects and stores data from a minimum of 12 months (see D4 paras. 0017, 0060) teaches collecting data for a minimum of one year for storage (see d4 para. 0074) for use cases which do not need the data on a real time basis.
Furthermore, it would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2-d3 with D4 in order to provide the techniques which configure the data lake layer which collects and stores data, as taught by d1 in view of d2 in view of d3, do so for a minimum of one year for storage (see d4 para. 0074), as taught by D4.
One of ordinary skill in the art would have been motivated in order to improve performance in a computationally efficient scalable and accurate manner further permitting planning and revenue management based on said forecasting (see D4 para. 0079) which teaches forecasting processes as more efficient and effective in predicting effect, enabling more expedient software deployment and business execution on greater data sets in planning and revenue management (see d4 para. 0079 and 0013).
Regarding claim 2, as to the limitation “The system of claim 1, further comprising a data bus for collecting data on a real time basis on a cloud network where the core of the cellular network is running” d1 in view of d2 in view of d3 in view of d4 discloses a data bus for collecting data on a real time basis (see d1 col. 10 ln 47- col. 11 line 40) n a cloud network where the core of the cellular network is running (see d2 para. 0034).
D2 teaches, in the same field of endeavor, collecting network performance data from a number of network devices, Abstract. D2 also teaches on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network for short term storage that is separate from long term storage. (see d1 para. 0024) wherein system 100 includes the performance data storage layer 114 further storing at least a portion of the performance data portion 110 in the responsive memory location in response to an identified trigger event 113. For example, where a trigger event 113 is identified, in certain embodiments the performance data storage layer 114 may store a portion of the performance data portion 110 (e.g., performance data related to the trigger event 113) in the responsive memory location (e.g., a high performance database) where it would otherwise be sent to long-term storage.
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify D1 per D2 to include that using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage. It would have been advantageous as discussed above and thus have been motivation for one of ordinary skill in the art to combine d1 with d1, as it would allow the modified system to provide flexible storage options which allows for optimization of the storage layers (see d2 para. 0004). Therefore the prior art includes the element claimed although not necessarily in a single reference; with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. Wherein, one of ordinary skill in the art would have combined the elements as claimed by known methods, and that in combination, each element merely performed the same function as it does separately. Therefore, one of ordinary skill in the art would have recognized that the results of the combination were predictable, as both are exercised in the same field of endeavor (wireless communication) for similar purposes (data collection) using known techniques in a similar manner separate as together.
Regarding claim 3, as to the limitation “The system of claim 2, wherein the data bus collects and stores data from a minimum of one day to a maximum of 7 days for time sensitive use cases to access data on a real time basis” d1 in view of d2 in view of d3 in view of d4 discloses a minimum of one day to a maximum of 7 days (see d3 para. 0152, 0564, 0074).
It would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2 with d3 in order to provide the technical features to enable configuring the real data transport layer which collects and stores data in a time limited manner, as taught by d1-d2, and to do so for a minimum of one day to a maximum of 7 days, to improve performance for time sensitive use cases to access data on a real-time basis.
Furthermore, one of ordinary skill in the art would have been motivated in order to perform threat detection, requirement compliance and provide results of such operations in substantially real-time (see d3 paras. 0074 and 0564). Referring to the limitation “maximum threshold” d3, in an analogous art, teaches the system wherein the real data transport layer collects and stores data from a minimum of one day to a maximum of 7 days (see D3 para. 0152) suggesting utilizing a streaming service with a limited period of 1 to 7 days for time sensitive use cases to access data on a real time basis (see D3 paras 0564 and 0074) suggesting accessing data in near real time.
It would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2 with d3 in order to configure the real data transport layer which collects and stores data, as taught by d1-d2, to do so for a minimum of one day to a maximum of 7 days, for time sensitive use cases to access data on a real-time basis.
Wherein, one of ordinary skill in the art would have been motivated in order to perform threat detection, requirement compliance and provide results of such operations in substantially real-time (see D3 paras 0074 and 0564).
Regarding claim 4, as to the limitation “The system of claim 1, further comprising a data lake for collecting data on a cloud network where the core of the cellular network is running” d1 in view of d2 in view of d3 in view of d4 discloses comprising a data lake for collecting data (see d1 col 3 lines 1-21; d2 para. 0039).
Regarding claim 5, as to the limitation “The system of claim 4, wherein the data lake collects and stores data from a minimum of 12 months for use cases which do not need the data on a real time basis” d1 in view of d2 in view of d3 in view of d4 discloses storing data from a minimum of 12 months for use cases which do not need the data on a real time basis (see d4 para. 0017, 0060, 0074).
Furthermore, it would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2-d3 with D4 in order to provide the techniques which configure the data lake layer which collects and stores data, as taught by d1 in view of d2 in view of d3, do so for a minimum of one year for storage (see d4 para. 0074), as taught by D4.
One of ordinary skill in the art would have been motivated in order to improve performance in a computationally efficient scalable and accurate manner further permitting planning and revenue management based on said forecasting (see D4 para. 0079) which teaches forecasting processes as more efficient and effective in predicting effect, enabling more expedient software deployment and business execution on greater data sets in planning and revenue management (see d4 para. 0079 and 0013).
Regarding claim 8, as to the limitation “The system of claim 1, wherein the applications comprise at least one of security, automation, analytics, and assurance” d1 in view of d2 in view of d3 in view of d4 discloses applications at least related to at least one of security, automation, analytics, and assurance (see d1 col 14 ln 9-24).
Regarding claim 9, as to the limitation “The system of claim 1, further comprising: a core, transport, radio access network, PNF, or network functions virtualization infrastructure (NFVI) that generates the data” d1 in view of d2 in view of d3 in view of d4 discloses at least NFVI (see d1 col 6 lns 9-14).
Regarding Claim 10, as to the limitation “A 5G cellular system for cellular communications observability, the system comprising:” D1 teaches a method for cellular communications observability of a cellular network system, (see d1 Col 2 ln 23-28,) disclosing processing trace data of virtual network functions of a telecommunication network via a plurality of stream processing systems. In particular, examples of the present disclosure configure network functions to provide trace data (or "probe data"), which may comprise logs, events, packets, and metadata for correlation; d1 also discloses employing containerized applications (i.e. containerized VNFs) to deploy a cellular network that utilizes clusters for virtual network functions of the cellular network; (see d1 Col 2 ln 57-64) suggesting that it should also be noted that in accordance with the present disclosure, the term "virtual network function" (or "VNF"), may refer to both virtual machine (VM)-based VNFs, e.g., VNFs deployed as VMs, and containerized or container-based (VNFs), e.g., VNFs deployed as containers, such as within a Kubernetes infrastructure, or the like, also referred to as "cloud-native network functions" (CNFs). Col 6 ln 9-14, Network 105 may also include an additional NFVI 111. For instance, unit 121 may be hosted on NFVI 111, which may comprise host devices having the same or similar physical components as NFVI 113. In addition, NFVI 111 may reside in a same location or in different locations from NFVI 113. D1 suggests identifying a plurality of domains (i.e. domain/zones) of the cellular network, wherein the plurality of domains and comprise a core of the cellular network, physical hardware components of the cellular network, and the clusters; (see d1 Col 11 ln 41-43) wherein the CVES-HV format builds upon the VES-HV format and defines a set of new fields to support easy querying and filtering of trace data for troubleshooting. D1 suggests (see d1 Col 12 ln 8-11, 55-60) that the VES-HV header may already include fields for information such as event name, domain, event Id event type, nfc Naming Code, source Id, source Name, reporting Entity Id, reporting Entity Name, sequence number. It should be noted that insofar as stream processing systems 218 and 228 may correlate, aggregate, and define additional trace data (such as aggregate KPIs), the stream processing systems 218 and 228 may subscribe to multiple topics from different VNFs within the respective zones. D1 also suggest (see d1 Col 16 ln 1-4) that a VNF may support several Web API calls in a secure manner, each of which may have an option to be applied globally (as a flag) or a particular cluster/location ( e.g., with a fully qualified domain name (FQDN)) on-demand.) Format for the trace data includes domain or data is collected from particular zones.
As to the limitation “first storage configured to collect the data associated with operations of a cellular network and to store the data for a maximum threshold amount of time” d1 suggests collecting (i.e. storing), using an observability layer (see d1 Fig 2 & 3, Data Distribution Platform 236) of the cellular network, the data from the plurality of domains of the cellular network, (see d1 Col 2 ln 37-52) wherein the present disclosure may comprise a probing architecture in which virtual network functions (VNFs) are configured as the primary source of probing information (trace data). Data may be collected and written to a "shared message bus," or data distribution platform, e.g., Apache Kafka, Apache Pulsar. D1 also suggests (see d1 Col 18 ln 55-61), At step 320, the first stream processing system obtains the trace data of the plurality of VNFs in the first region, where the trace data is obtained from a data distribution platform of the telecommunication network, where the trace data is published in accordance with a topic to the data distribution platform by the plurality of VNFs, and where the first stream processing system comprises a subscriber to the topic, wherein the observability layer (Fig 2 & 3, Data Distribution Platform 236) is located on a public network of the cellular network and connected to at least one of the virtual network functions of the cellular network; (see d1 Col 4 ln 16-20) wherein the network 105 may alternatively or additional comprise components of a cellular core network, such as a Public Land Mobile Network (PLMN), a General Packet Radio Service (GPRS) core 20 network. D1 also suggests (see d1 Col 18 ln 55-61), At step 320, the first stream processing system obtains the trace data of the plurality of VNFs in the first region, where the trace data is obtained from a data distribution platform of the telecommunication network; wherein it is disclosed aggregating (i.e. a first storage storing data), by the observability layer (Fig 2 & 3, Data Distribution Platform 236), the data according to configuration information (i.e. schema) of the clusters (i.e. VNFs per location); (see d1 Col 3, ln 5-14) wherein all trace data is stored in open databases, or "data lakes," with open schemas and data formats. To deliver session related events, the present disclosure defines an extension of Open Network Automation Platform (ONAP) High Volume Virtual Event Streaming (HV-VES) event format schema/format to include primary keys and secondary keys used in troubleshooting. All trace data that is generated, transformed, stored, etc. is enforced to remain compatible with this schema. D1 also suggests (see d1 Col 8 ln 47-57) that the probe server may then forward the raw packets to a collector. A centralized service may then analyze the raw packets to generate performance indicators, logs, etc. As such, these VNFs may be configured, e.g., via probe configuration service 192, to collect, generate, create, transmit, and/or otherwise process probe/trace data, which may include packets, performance indicators, events, and/or logs. D1 suggests ingesting (i.e. process, filtering, joining, aggregating, sampling) the data in real-time from the observability layer using a streaming platform data store of the cellular network, (see d1 Col 8-9 ln 64-67, 1-8) wherein an associated one of the stream processing system(s) 196 (e.g., one that is assigned to the same zone as the VNF and the one of the data distribution platform(s) 194) may be configured as a "subscriber" to the "topic," and may thus obtain the trace data from the VNF (and similarly from other VNFs in the same zone, from the same or different topics). The one of the stream processing system(s) 196 from the same zone may additionally process the trace data from the VNF (and from other VNFs in the same zone), such as filtering, joining, aggregating, sampling, etc., and may generate KPIs, events, and/or logs, which may be added to the trace data. D1 also suggests (see d1 Col 18 ln 55-61), At step 320, the first stream processing system obtains the trace data of the plurality of VNFs in the first region, where the trace data is obtained from a data distribution platform of the telecommunication network, wherein the data is stored in a specified area of the streaming platform data store according to the configuration information and a type of the data; (see d1 Col 13 ln 50-54), Storage element(s) 250 and archive element(s) 260 manage storage retention as per configured policies ( e.g., number of hours/days of retention per type of trace data, per VNF type, etc.).
As to the limitation “wherein first use applications requiring data to be not older than the maximum threshold amount of time retrieve data directly from the first storage” d1 suggests receiving, at the streaming platform data store and from an application associated with the cellular network, a request for real-time data from short term storage; (see d1 Col 14 ln 9-24) wherein applications 299 may include automated services, as well as one or more user applications, e.g., for visualizing trace data, managing the collection and processing of trace data via the architecture 200, querying the trace data. The troubleshooting application may enable an operator to enter a request for all of the packets (e.g., trace data) 20 associated with the subscriber's connection setup, service requests, handover, etc., with appropriate timestamps. In case the raw packets are not available, the architecture 200 may still provide events and/or logs (e.g., trace data), which can be used to troubleshoot service issues and distributing (i.e. retrieve) the data (i.e. trace data, metrics, performance indicators) to the application (i.e. requesting application) from the streaming platform data store based on the request. D1 suggests (see d1 Col 14 ln 29-37) the application may direct the request to architecture 200 via 30 API 280 as a query/command such as: "RETRIEVE all messages/events for time in [t1,t2] where Fl=x and F2=y ... ", where t2 can be current time/ongoing/future time, t1 can be 30 days prior or older, etc. In one example, auxiliary queries may be generated based on results. It should be noted that the stream processing systems 218, 228, and 238 enable stream processing (including partial processing of queries, or processing of sub-queries. D1 also suggest (see d1 Col 15, ln 28-30) performance indicators may be included in trace data (e.g., as configured via the architecture 200, not necessarily in connection with any particular troubleshooting request). One or more of applications 299 may enable an operator to retrieve metrics for specific calls, generate batch mode reports, and so forth. D1 teaches on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network (see Col 8-9 ln 64-67, 1-8 & Col 18 ln 55-61) and storage/search of historical events (see d1 Col 13 ln 55-57). However, D1 is silent on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage.
D2 teaches, in the same field of endeavor, collecting network performance data from a number of network devices, Abstract. D2 also teaches on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network for short term storage that is separate from long term storage. (see d1 para. 0024) wherein system 100 includes the performance data storage layer 114 further storing at least a portion of the performance data portion 110 in the responsive memory location in response to an identified trigger event 113. For example, where a trigger event 113 is identified, in certain embodiments the performance data storage layer 114 may store a portion of the performance data portion 110 (e.g., performance data related to the trigger event 113) in the responsive memory location (e.g., a high performance database) where it would otherwise be sent to long-term storage.
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify D1 per D2 to include that using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage. It would have been advantageous as discussed above and thus have been motivation for one of ordinary skill in the art to combine d1 with d1, as it would allow the modified system to provide flexible storage options which allows for optimization of the storage layers (see d2 para. 0004). Therefore the prior art includes the element claimed although not necessarily in a single reference; with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. Wherein, one of ordinary skill in the art would have combined the elements as claimed by known methods, and that in combination, each element merely performed the same function as it does separately. Therefore, one of ordinary skill in the art would have recognized that the results of the combination were predictable, as both are exercised in the same field of endeavor (wireless communication) for similar purposes (data collection) using known techniques in a similar manner separate as together.
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify D1 per D2 to include that using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage. It would have been advantageous as discussed above, as it would allow the modified system to provide flexible storage options which allows for optimization of the storage layers (see d2 para. 0004).
As to the limitation “maximum threshold amount of time” D1 teaches on ingesting the data in real-time from the observability layer and on the storage platform having export data platforms that vendor agnostic (see d1 Col 3 ln 1-5, Col 18 ln 55-61). d3 teaches, in the same field of endeavor, methods and systems for managing a plurality of cloud assets, Abstract.
D3, in an analogous art, teaches the system wherein the real data transport layer collects and stores data from a minimum of one day to a maximum of 7 days see D3 para. 01520 teaches utilizing a streaming service with a limited period of 1 to 7 days for time sensitive use cases to access data on a real time basis (see D3 paras 0564 and 0074) as well as accessing data in near real time.
It would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2 with d3 in order to provide the technical features to enable configuring the real data transport layer which collects and stores data in a time limited manner, as taught by d1-d2, and to do so for a minimum of one day to a maximum of 7 days, to improve performance for time sensitive use cases to access data on a real-time basis.
Furthermore, one of ordinary skill in the art would have been motivated in order to perform threat detection, requirement compliance and provide results of such operations in substantially real-time (see d3 paras. 0074 and 0564). Referring to the limitation “maximum threshold” d3, in an analogous art, teaches the system wherein the real data transport layer collects and stores data from a minimum of one day to a maximum of 7 days (see D3 para. 0152) suggesting utilizing a streaming service with a limited period of 1 to 7 days for time sensitive use cases to access data on a real time basis (see D3 paras 0564 and 0074) suggesting accessing data in near real time.
It would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2 with d3 in order to configure the real data transport layer which collects and stores data, as taught by d1-d2, to do so for a minimum of one day to a maximum of 7 days, for time sensitive use cases to access data on a real-time basis.
Wherein, one of ordinary skill in the art would have been motivated in order to perform threat detection, requirement compliance and provide results of such operations in substantially real-time (see D3 paras 0074 and 0564).
Regarding thresholds, D4, in an analogous art, teaches the system wherein the data lake layer collects and stores data from a minimum of 12 months (see D4 paras. 0017, 0060) teaches collecting data for a minimum of one year for storage (see d4 para. 0074) for use cases which do not need the data on a real time basis.
Furthermore, it would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2-d3 with D4 in order to provide the techniques which configure the data lake layer which collects and stores data, as taught by d1 in view of d2 in view of d3, do so for a minimum of one year for storage (see d4 para. 0074), as taught by D4.
One of ordinary skill in the art would have been motivated in order to improve performance in a computationally efficient scalable and accurate manner further permitting planning and revenue management based on said forecasting (see D4 para. 0079) which teaches forecasting processes as more efficient and effective in predicting effect, enabling more expedient software deployment and business execution on greater data sets in planning and revenue management (see d4 para. 0079 and 0013).
Regarding claim 13, as to the limitation “The system of claim 10, further comprising a data bus for collecting data on a real time basis on a cloud network where the core of the cellular network is running” d1 in view of d2 in view of d3 in view of d4 discloses a data bus for collecting data on a real time basis (see d1 col. 10 ln 47- col. 11 line 40) in a cloud network where the core of the cellular network is running (see d2 para. 0034).
D2 teaches, in the same field of endeavor, collecting network performance data from a number of network devices, Abstract. D2 also teaches on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network for short term storage that is separate from long term storage. (see d1 para. 0024) wherein system 100 includes the performance data storage layer 114 further storing at least a portion of the performance data portion 110 in the responsive memory location in response to an identified trigger event 113. For example, where a trigger event 113 is identified, in certain embodiments the performance data storage layer 114 may store a portion of the performance data portion 110 (e.g., performance data related to the trigger event 113) in the responsive memory location (e.g., a high performance database) where it would otherwise be sent to long-term storage.
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify D1 per D2 to include that using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage. It would have been advantageous as discussed above and thus have been motivation for one of ordinary skill in the art to combine d1 with d1, as it would allow the modified system to provide flexible storage options which allows for optimization of the storage layers (see d2 para. 0004). Therefore the prior art includes the element claimed although not necessarily in a single reference; with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. Wherein, one of ordinary skill in the art would have combined the elements as claimed by known methods, and that in combination, each element merely performed the same function as it does separately. Therefore, one of ordinary skill in the art would have recognized that the results of the combination were predictable, as both are exercised in the same field of endeavor (wireless communication) for similar purposes (data collection) using known techniques in a similar manner separate as together.
Regarding claim 14, as to the limitation “The system of claim 13, wherein the data bus collects and stores data from a minimum of one day to a maximum of 7 days for time sensitive use cases to access data on a real time basis” d1 in view of d2 in view of d3 in view of d4 discloses a minimum of one day to a maximum of 7 days (see d3 para. 0152, 0564, 0074).
It would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2 with d3 in order to provide the technical features to enable configuring the real data transport layer which collects and stores data in a time limited manner, as taught by d1-d2, and to do so for a minimum of one day to a maximum of 7 days, to improve performance for time sensitive use cases to access data on a real-time basis.
Furthermore, one of ordinary skill in the art would have been motivated in order to perform threat detection, requirement compliance and provide results of such operations in substantially real-time (see d3 paras. 0074 and 0564). Referring to the limitation “maximum threshold” d3, in an analogous art, teaches the system wherein the real data transport layer collects and stores data from a minimum of one day to a maximum of 7 days (see D3 para. 0152) suggesting utilizing a streaming service with a limited period of 1 to 7 days for time sensitive use cases to access data on a real time basis (see D3 paras 0564 and 0074) suggesting accessing data in near real time.
It would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2 with d3 in order to configure the real data transport layer which collects and stores data, as taught by d1-d2, to do so for a minimum of one day to a maximum of 7 days, for time sensitive use cases to access data on a real-time basis.
Wherein, one of ordinary skill in the art would have been motivated in order to perform threat detection, requirement compliance and provide results of such operations in substantially real-time (see D3 paras 0074 and 0564).
Regarding claim 15, as to the limitation “The system of claim 10, wherein the second storage comprises a data lake for collecting data on a cloud network where the core of the cellular network is running” d1 in view of d2 in view of d3 in view of d4 discloses comprising a data lake for collecting data (see d1 col 3 lines 1-21; d2 para. 0039).
D2 teaches, in the same field of endeavor, collecting network performance data from a number of network devices, Abstract. D2 also teaches on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network for short term storage that is separate from long term storage. (see d1 para. 0024) wherein system 100 includes the performance data storage layer 114 further storing at least a portion of the performance data portion 110 in the responsive memory location in response to an identified trigger event 113. For example, where a trigger event 113 is identified, in certain embodiments the performance data storage layer 114 may store a portion of the performance data portion 110 (e.g., performance data related to the trigger event 113) in the responsive memory location (e.g., a high performance database) where it would otherwise be sent to long-term storage.
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify D1 per D2 to include that using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage. It would have been advantageous as discussed above and thus have been motivation for one of ordinary skill in the art to combine d1 with d1, as it would allow the modified system to provide flexible storage options which allows for optimization of the storage layers (see d2 para. 0004). Therefore the prior art includes the element claimed although not necessarily in a single reference; with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. Wherein, one of ordinary skill in the art would have combined the elements as claimed by known methods, and that in combination, each element merely performed the same function as it does separately. Therefore, one of ordinary skill in the art would have recognized that the results of the combination were predictable, as both are exercised in the same field of endeavor (wireless communication) for similar purposes (data collection) using known techniques in a similar manner separate as together.
Regarding claim 16, as to the limitation “The system of claim 15, wherein the data lake collects and stores data from a minimum of 12 months for use cases which do not need the data on a real time basis” d1 in view of d2 in view of d3 in view of d4 discloses storing data from a minimum of 12 months for use cases which do not need the data on a real time basis (see d4 para. 0017, 0060, 0074).
Furthermore, it would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2-d3 with D4 in order to provide the techniques which configure the data lake layer which collects and stores data, as taught by d1 in view of d2 in view of d3, do so for a minimum of one year for storage (see d4 para. 0074), as taught by D4.
One of ordinary skill in the art would have been motivated in order to improve performance in a computationally efficient scalable and accurate manner further permitting planning and revenue management based on said forecasting (see D4 para. 0079) which teaches forecasting processes as more efficient and effective in predicting effect, enabling more expedient software deployment and business execution on greater data sets in planning and revenue management (see d4 para. 0079 and 0013).
Regarding claim 17, as to the limitation “The system of claim 10, wherein a streaming platform data bus is disposed to collect the data and is configured to transfers the data to the second storage” d1 in view of d2 in view of d3 in view of d4 discloses data bus is disposed to collect the data and is configured to transfers the data to the second storage (see d2 para. 0024).
D2 teaches, in the same field of endeavor, collecting network performance data from a number of network devices, Abstract. D2 also teaches on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network for short term storage that is separate from long term storage. (see d1 para. 0024) wherein system 100 includes the performance data storage layer 114 further storing at least a portion of the performance data portion 110 in the responsive memory location in response to an identified trigger event 113. For example, where a trigger event 113 is identified, in certain embodiments the performance data storage layer 114 may store a portion of the performance data portion 110 (e.g., performance data related to the trigger event 113) in the responsive memory location (e.g., a high performance database) where it would otherwise be sent to long-term storage.
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify D1 per D2 to include that using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage. It would have been advantageous as discussed above and thus have been motivation for one of ordinary skill in the art to combine d1 with d1, as it would allow the modified system to provide flexible storage options which allows for optimization of the storage layers (see d2 para. 0004). Therefore the prior art includes the element claimed although not necessarily in a single reference; with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. Wherein, one of ordinary skill in the art would have combined the elements as claimed by known methods, and that in combination, each element merely performed the same function as it does separately. Therefore, one of ordinary skill in the art would have recognized that the results of the combination were predictable, as both are exercised in the same field of endeavor (wireless communication) for similar purposes (data collection) using known techniques in a similar manner separate as together.
Regarding Claim 18, as to the limitation “A method for cellular communications observability of a cellular network system, the method comprising: generating data from a cellular network employing clusters created using a containerized application; collecting, using a platform as a service (PaaS) observability framework (OBF), the data and store the data for a maximum threshold amount of time; ingesting and processing streaming data in real-time, using a streaming platform data store, and distributing the data to applications requesting such data, wherein the streaming platform extends completely over the PaaS OBF so that all data collected by the OBF platform is available to the streaming platform data store; storing the data in a data storage for a term greater than the maximum threshold amount of time; and wherein first use applications requiring data to be not older than the maximum threshold amount of time retrieve data directly from the PaaS OBF, which second use applications retrieve data from the data storage” D1 teaches a method for cellular communications observability of a cellular network system, (see d1 Col 2 ln 23-28,) disclosing processing trace data of virtual network functions of a telecommunication network via a plurality of stream processing systems. In particular, examples of the present disclosure configure network functions to provide trace data (or "probe data"), which may comprise logs, events, packets, and metadata for correlation; d1 also discloses employing containerized applications (i.e. containerized VNFs) to deploy a cellular network that utilizes clusters for virtual network functions of the cellular network; (see d1 Col 2 ln 57-64) suggesting that it should also be noted that in accordance with the present disclosure, the term "virtual network function" (or "VNF"), may refer to both virtual machine (VM)-based VNFs, e.g., VNFs deployed as VMs, and containerized or container-based (VNFs), e.g., VNFs deployed as containers, such as within a Kubernetes infrastructure, or the like, also referred to as "cloud-native network functions" (CNFs). Col 6 ln 9-14, Network 105 may also include an additional NFVI 111. For instance, unit 121 may be hosted on NFVI 111, which may comprise host devices having the same or similar physical components as NFVI 113. In addition, NFVI 111 may reside in a same location or in different locations from NFVI 113. D1 suggests identifying a plurality of domains (i.e. domain/zones) of the cellular network, wherein the plurality of domains and comprise a core of the cellular network, physical hardware components of the cellular network, and the clusters; (see d1 Col 11 ln 41-43) wherein the CVES-HV format builds upon the VES-HV format and defines a set of new fields to support easy querying and filtering of trace data for troubleshooting. D1 suggests (see d1 Col 12 ln 8-11, 55-60) that the VES-HV header may already include fields for information such as event name, domain, event Id event type, nfc Naming Code, source Id, source Name, reporting Entity Id, reporting Entity Name, sequence number. It should be noted that insofar as stream processing systems 218 and 228 may correlate, aggregate, and define additional trace data (such as aggregate KPIs), the stream processing systems 218 and 228 may subscribe to multiple topics from different VNFs within the respective zones. D1 also suggest (see d1 Col 16 ln 1-4) that a VNF may support several Web API calls in a secure manner, each of which may have an option to be applied globally (as a flag) or a particular cluster/location ( e.g., with a fully qualified domain name (FQDN)) on-demand.) Format for the trace data includes domain or data is collected from particular zones.
As to the limitation “first storage configured to collect the data associated with operations of a cellular network and to store the data for a maximum threshold amount of time” d1 suggests collecting (i.e. storing), using an observability layer (see d1 Fig 2 & 3, Data Distribution Platform 236) of the cellular network, the data from the plurality of domains of the cellular network, (see d1 Col 2 ln 37-52) wherein the present disclosure may comprise a probing architecture in which virtual network functions (VNFs) are configured as the primary source of probing information (trace data). Data may be collected and written to a "shared message bus," or data distribution platform, e.g., Apache Kafka, Apache Pulsar. D1 also suggests (see d1 Col 18 ln 55-61), At step 320, the first stream processing system obtains the trace data of the plurality of VNFs in the first region, where the trace data is obtained from a data distribution platform of the telecommunication network, where the trace data is published in accordance with a topic to the data distribution platform by the plurality of VNFs, and where the first stream processing system comprises a subscriber to the topic, wherein the observability layer (Fig 2 & 3, Data Distribution Platform 236) is located on a public network of the cellular network and connected to at least one of the virtual network functions of the cellular network; (see d1 Col 4 ln 16-20) wherein the network 105 may alternatively or additional comprise components of a cellular core network, such as a Public Land Mobile Network (PLMN), a General Packet Radio Service (GPRS) core 20 network. D1 also suggests (see d1 Col 18 ln 55-61), At step 320, the first stream processing system obtains the trace data of the plurality of VNFs in the first region, where the trace data is obtained from a data distribution platform of the telecommunication network; wherein it is disclosed aggregating (i.e. a first storage storing data), by the observability layer (Fig 2 & 3, Data Distribution Platform 236), the data according to configuration information (i.e. schema) of the clusters (i.e. VNFs per location); (see d1 Col 3, ln 5-14) wherein all trace data is stored in open databases, or "data lakes," with open schemas and data formats. To deliver session related events, the present disclosure defines an extension of Open Network Automation Platform (ONAP) High Volume Virtual Event Streaming (HV-VES) event format schema/format to include primary keys and secondary keys used in troubleshooting. All trace data that is generated, transformed, stored, etc. is enforced to remain compatible with this schema. D1 also suggests (see d1 Col 8 ln 47-57) that the probe server may then forward the raw packets to a collector. A centralized service may then analyze the raw packets to generate performance indicators, logs, etc. As such, these VNFs may be configured, e.g., via probe configuration service 192, to collect, generate, create, transmit, and/or otherwise process probe/trace data, which may include packets, performance indicators, events, and/or logs. D1 suggests ingesting (i.e. process, filtering, joining, aggregating, sampling) the data in real-time from the observability layer using a streaming platform data store of the cellular network, (see d1 Col 8-9 ln 64-67, 1-8) wherein an associated one of the stream processing system(s) 196 (e.g., one that is assigned to the same zone as the VNF and the one of the data distribution platform(s) 194) may be configured as a "subscriber" to the "topic," and may thus obtain the trace data from the VNF (and similarly from other VNFs in the same zone, from the same or different topics). The one of the stream processing system(s) 196 from the same zone may additionally process the trace data from the VNF (and from other VNFs in the same zone), such as filtering, joining, aggregating, sampling, etc., and may generate KPIs, events, and/or logs, which may be added to the trace data. D1 also suggests (see d1 Col 18 ln 55-61), At step 320, the first stream processing system obtains the trace data of the plurality of VNFs in the first region, where the trace data is obtained from a data distribution platform of the telecommunication network, wherein the data is stored in a specified area of the streaming platform data store according to the configuration information and a type of the data; (see d1 Col 13 ln 50-54), Storage element(s) 250 and archive element(s) 260 manage storage retention as per configured policies ( e.g., number of hours/days of retention per type of trace data, per VNF type, etc.).
As to the limitation “wherein first use applications requiring data to be not older than the maximum threshold amount of time retrieve data directly from the first storage” d1 suggests receiving, at the streaming platform data store and from an application associated with the cellular network, a request for real-time data from short term storage; (see d1 Col 14 ln 9-24) wherein applications 299 may include automated services, as well as one or more user applications, e.g., for visualizing trace data, managing the collection and processing of trace data via the architecture 200, querying the trace data. The troubleshooting application may enable an operator to enter a request for all of the packets (e.g., trace data) 20 associated with the subscriber's connection setup, service requests, handover, etc., with appropriate timestamps. In case the raw packets are not available, the architecture 200 may still provide events and/or logs (e.g., trace data), which can be used to troubleshoot service issues and distributing (i.e. retrieve) the data (i.e. trace data, metrics, performance indicators) to the application (i.e. requesting application) from the streaming platform data store based on the request. D1 suggests (see d1 Col 14 ln 29-37) the application may direct the request to architecture 200 via 30 API 280 as a query/command such as: "RETRIEVE all messages/events for time in [t1,t2] where Fl=x and F2=y ... ", where t2 can be current time/ongoing/future time, t1 can be 30 days prior or older, etc. In one example, auxiliary queries may be generated based on results. It should be noted that the stream processing systems 218, 228, and 238 enable stream processing (including partial processing of queries, or processing of sub-queries. D1 also suggest (see d1 Col 15, ln 28-30) performance indicators may be included in trace data (e.g., as configured via the architecture 200, not necessarily in connection with any particular troubleshooting request). One or more of applications 299 may enable an operator to retrieve metrics for specific calls, generate batch mode reports, and so forth. D1 teaches on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network (see Col 8-9 ln 64-67, 1-8 & Col 18 ln 55-61) and storage/search of historical events (see d1 Col 13 ln 55-57). However, D1 is silent on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage.
D2 teaches, in the same field of endeavor, collecting network performance data from a number of network devices, Abstract. D2 also teaches on ingesting the data in real-time from the observability layer using a streaming platform data store of the cellular network for short term storage that is separate from long term storage. (see d1 para. 0024) wherein system 100 includes the performance data storage layer 114 further storing at least a portion of the performance data portion 110 in the responsive memory location in response to an identified trigger event 113. For example, where a trigger event 113 is identified, in certain embodiments the performance data storage layer 114 may store a portion of the performance data portion 110 (e.g., performance data related to the trigger event 113) in the responsive memory location (e.g., a high performance database) where it would otherwise be sent to long-term storage.
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify D1 per D2 to include that using a streaming platform data store of the cellular network a second storage in communication with the first storage to store the data for a term greater than the maximum threshold amount of time and second use applications retrieve data from the second storage. It would have been advantageous as discussed above and thus have been motivation for one of ordinary skill in the art to combine d1 with d1, as it would allow the modified system to provide flexible storage options which allows for optimization of the storage layers (see d2 para. 0004). Therefore the prior art includes the element claimed although not necessarily in a single reference; with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. Wherein, one of ordinary skill in the art would have combined the elements as claimed by known methods, and that in combination, each element merely performed the same function as it does separately. Therefore, one of ordinary skill in the art would have recognized that the results of the combination were predictable, as both are exercised in the same field of endeavor (wireless communication) for similar purposes (data collection) using known techniques in a similar manner separate as together.
As to the limitation “maximum threshold amount of time” and “PaaS” D1 teaches on ingesting the data in real-time from the observability layer and on the storage platform having export data platforms that vendor agnostic (see d1 Col 3 ln 1-5, Col 18 ln 55-61). D3 teaches, in the same field of endeavor, methods and systems for managing a plurality of cloud assets, Abstract.
D3, in an analogous art, teaches the system wherein the real data transport layer collects and stores data from a minimum of one day to a maximum of 7 days see D3 para. 01520 teaches utilizing a streaming service with a limited period of 1 to 7 days for time sensitive use cases to access data on a real time basis (see D3 paras 0564 and 0074 ) as well as accessing data in near real time and PaaS (see d3 para. 0091).
It would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2 with d3 in order to provide the technical features to enable configuring the real data transport layer which collects and stores data in a time limited manner, as taught by d1-d2, and to do so for a minimum of one day to a maximum of 7 days, to improve performance for time sensitive use cases to access data on a real-time basis.
Furthermore, one of ordinary skill in the art would have been motivated in order to perform threat detection, requirement compliance and provide results of such operations in substantially real-time (see d3 paras. 0074 and 0564). Referring to the limitation “maximum threshold” d3, in an analogous art, teaches the system wherein the real data transport layer collects and stores data from a minimum of one day to a maximum of 7 days (see D3 para. 0152) suggesting utilizing a streaming service with a limited period of 1 to 7 days for time sensitive use cases to access data on a real time basis (see D3 paras 0564 and 0074) suggesting accessing data in near real time.
It would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2 with d3 in order to configure the real data transport layer which collects and stores data, as taught by d1-d2, to do so for a minimum of one day to a maximum of 7 days, for time sensitive use cases to access data on a real-time basis.
Wherein, one of ordinary skill in the art would have been motivated in order to perform threat detection, requirement compliance and provide results of such operations in substantially real-time (see D3 paras 0074 and 0564).
Regarding thresholds, D4, in an analogous art, teaches the system wherein the data lake layer collects and stores data from a minimum of 12 months (see D4 paras. 0017, 0060) teaches collecting data for a minimum of one year for storage (see d4 para. 0074) for use cases which do not need the data on a real time basis.
Furthermore, it would have been obvious for a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify d1-d2-d3 with D4 in order to provide the techniques which configure the data lake layer which collects and stores data, as taught by d1 in view of d2 in view of d3, do so for a minimum of one year for storage (see d4 para. 0074), as taught by D4.
One of ordinary skill in the art would have been motivated in order to improve performance in a computationally efficient scalable and accurate manner further permitting planning and revenue management based on said forecasting (see D4 para. 0079) which teaches forecasting processes as more efficient and effective in predicting effect, enabling more expedient software deployment and business execution on greater data sets in planning and revenue management (see d4 para. 0079 and 0013).
Regarding claim 19, as to the limitation “The method of claim 18, wherein all of the data are collected at a single point or single database and on a common network/server location” d1 in view of d2 in view of d3 in view of d4 discloses data are collected at a single point or single database and on a common network/server location (see d1 col 2 lns 50-54).
Regarding claim 20, as to the limitation “The method of claim 18, wherein the streaming platform data store is a Kafka bus” d1 in view of d2 in view of d3 in view of d4 suggests a Kafka bus (see d1 col 2 lns 50-54).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NATHAN SCOTT TAYLOR whose telephone number is (571)270-3189. The examiner can normally be reached on Mon. - Thurs. 9:00-4:00.
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, JINSONG HU can be reached on 5712723965. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NATHAN S TAYLOR/Primary Examiner, Art Unit 2643