DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to communication received on 10/01/2025, claims 1, 3-8, 10-15 and 17-20 are pending of which claim 1 8 and 15 are amended.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 3-8, 10-15 and 17-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1 8 and 15 recite ”generating alarm information for the abnormal event; and pushing the alarm information to a target object of the abnormal event, wherein the target object is configured to exclude the target content from the data processing link to resolve the abnormal event.”
The specification provides no support for generating and pushing alarm information to a target object where the target object is configured to exclude the target content. The specification does not describe any way in which pushing alarm information configures the target object to exclude the target content. In as much as the target object is described as an operator i.e a human there is support for what comprises configuring a operator to exclude the target content. The is also no language with respect to excluding target content from the data processing link. In as much as the term excluded is recited in ¶168 such language recites that an abnormal event can be resolve and excluded, there is no recitation of resolving or excluding the target content.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 4, 7-9, 11, 14-16, 18 and 20 are rejected under 35 U.S.C. 102a2 as being anticipated by Zheng US 2022/0027431.
Regarding claims 1 8 and 15, Zheng teaches a device, non-transistory CRM executing instructions by an electronic device and a data detection method, performed by an electronic device, the method comprising: obtaining, in response to a detection trigger instruction, processing information of a plurality of processing nodes in a data processing link for a target content and a corresponding event trigger condition(administrator configure monitoring of a network specifying specific URL to be monitored and conditions and triggers for alerts and other action to be performed on monitored URLs., ¶s 38,126,169)
[0038] The systems and methods include a digital experience monitoring platform which does not require new hardware or software in the network. Rather, the digital experience monitoring platform leverages an existing cloud infrastructure, namely a distributed security cloud, lightweight connectors at the edge for access to applications, and an application at endpoints such as user devices. Such components are already in place in Zscaler's distributed security cloud. Also, these components perform inline processing, enabling a real-time collection of data for the digital experience monitoring platform. Advantageously, by leveraging existing infrastructure, the digital experience monitoring platform provides real-time data which can be used for remediation and requires no additional equipment. For example, the digital experience monitoring platform can enable an intelligent path selection in real-time for a user. Thus, the digital experience monitoring platform is proactive, not reactive.
[0126] Again, the cloud-based system 100 has the ability to monitor, diagnose, generate alerts, and perform remedial actions with respect to network endpoints, network components, network links, etc. The alerts generated can be with regards to any aspect of the inline monitoring disclosed herein and can be based on rules establishing specific criteria and conditions that, when fulfilled, trigger the alert(s).
[0169] FIG. 47 is diagram of a browser extension 1000 on a user device 300 communicating to the cloud-based system 100, such for RUM. Also, the browser extension 1000 can include the UPM browser extension described herein. This RUM feature helps us get a true real picture of the user's experience by having a plugin installed on a browser or the like executed on the user device 300 that can post the RUM metrics to either an intermediate aggregator such as the application 350 or directly to a data lake, such as in the cloud-based system 100. This approach is different from the traditional RUM solutions where the destination server injects a JavaScript (JS) into the web pages it is serving and gets the RUM statistics from the user's browser which only that provider can view. In our approach, the IT admin of the organization can configure any domain/URL or list of domains/URLs to be monitored and the plugin will calculate the RUM Statistics/Metrics for domains/URLs specified and push calculated Statistics/Metrics to our data lake for analysis that the customer can view. This gives our customers the unique ability to view the RUM Statistics/Metrics of any user in their org to get an insight into their digital experience.
determining circulation information of the target content in the plurality of processing nodes using the respective processing information of the plurality of processing nodes(metrics regarding the processing and url/web request metrics are generated for the nodes hosting content, ¶s87,88,91)
[0087] Metrics could be combined. For example, device health can be based on a combination of CPU, memory, etc. Network health could be a combination of Wi-Fi/LAN connection health, latency, etc. Application health could be a combination of response time, page loads, etc. The cloud-based system 100 can generate service health as a combination of CPU, memory, and the load time of the service while processing a user's request. The network health could be based on the number of network path(s), latency, packet loss, etc.
[0088] The lightweight connector 400 can also generate similar metrics for the applications 402, 404. In an embodiment, the metrics can be collected while a user is accessing specific applications that user experience is desired for monitoring. In another embodiment, the metrics can be enriched by triggering synthetic measurements in the context of an inline transaction by the application 350 or cloud edge. The metrics can be tagged with metadata (user, time, app, etc.) and sent to a logging and analytics service for aggregation, analysis, and reporting. Further, network administrators can get UEX reports from the cloud-based system 100. Due to the inline nature and the fact the cloud-based system 100 is an overlay (in-between users and services/applications), the cloud-based system 100 enables the ability to capture user experience metric data continuously and to log such data historically. As such, a network administrator can have a long-term detailed view of the network and associated user experience.
[0091] An example of HTTP Request metrics includes CONNECT, time to first byte/first 10 bytes, time to last byte, Secure Sockets Layer (SSL) handshake time, etc. For example, HTTP can be used to send probes to take measurements as described in commonly-assigned U.S. patent application Ser. No. 16/043,250, filed Jun. 24, 2018, and entitled “Cloud services management systems utilizing in-band communication conveying situational awareness,” the contents of which are incorporated by reference herein.
determining, when at least one of the processing information and the circulation information hits the event trigger condition, occurrence of a detection event corresponding to the event trigger condition in the data processing link(when particular metrics hit certain threshold alerts and other information are generated and displayed to user/administrator, ¶s108,126,127,130)
[0108] FIG. 21 is a GUI of an alerts dashboard. This includes a number of high severity alerts and a number of application, network, and device alerts. The alerts dashboard further includes a visualization of active alert distribution, a listing of high severity alerts, and a list of the most recent active alerts. FIG. 22 is a GUI of a performance dashboard. This includes the overall UEX score, an indication of the most impacted location and application, a map of global UEX score, and a graph of UEX score over time. FIG. 23 is a GUI of a user dashboard illustrating a single user. FIG. 24 is a GUI of an application dashboard illustrating a single application.
[0126] Again, the cloud-based system 100 has the ability to monitor, diagnose, generate alerts, and perform remedial actions with respect to network endpoints, network components, network links, etc. The alerts generated can be with regards to any aspect of the inline monitoring disclosed herein and can be based on rules establishing specific criteria and conditions that, when fulfilled, trigger the alert(s).
[0127] Alerts can be triggered when results meet a specific condition defined by an alert rule. An alert can also have an action, such as a notification of the alert, associated therewith, such that when alerts are triggered, the action is also triggered. For example, an email can be sent, webhooks can be triggered, or messages can be sent via 3rd party integrations such as Servicenow, Pagerduty, Slack, etc.
[0130] Triggering events based on the alert rules can be checked in real time or can be checked on a predetermined or selected interval, for example, every five minutes. The predetermined or selected interval can be aligned and synchronized with the monitors/inline monitoring described above. In order to reduce noise by sending multiple notifications for the same or similar alerts, alert criteria can be included to limit the notifications. For example, alerts can be limited to when the alert event occurs a predetermined or selected number of times in a row, if the alert events impact a predetermined or selected number or percentage of devices in a particular location, group, department, operating system version, and the like. Furthermore, a repeating alert event can be throttled so that only one notification of the alert is sent or the alert is only triggered once. For example, if the same alert event starts/stops multiple times within 1 minute, the alert can be throttled to send only one notification.
collecting data for the detection event to obtain detection data corresponding to the detection event(data corresponding to events are captured such user may drill down and see further information regarding events/alerts, ¶s 49.129 )
[0049] The cloud-based system 100 can also include a management system 120 for tenant access to provide global policy and configuration as well as real-time analytics. This enables IT administrators to have a unified view of user activity, threat intelligence, application usage, etc. For example, IT administrators can drill-down to a per-user level to understand events and correlate threats, to identify compromised devices, to have application visibility, and the like. The cloud-based system 100 can further include connectivity to an Identity Provider (IDP) 122 for authentication of the users 102 and to a Security Information and Event Management (SIEM) system 124 for event logging. The system 124 can provide alert and activity logs on a per-user 102 basis.
[0129] Any combination of rules can be established relative to the inline monitoring and the data and metrics collected therewith. For example, the rules can include one or more of the following: (1) when a UX score degrades by certain threshold percentage over a predetermined or selected period of time; and (2) any of the metrics of the inline monitoring meets a predetermined or selected threshold for the respective metric, such as a UX score, network latency (per log), percentage of packet loss (per leg), total hop count, per leg hop count, incomplete traceroutes, DNS time, Page Fetch Time, availability (HTTP errors), and device health metrics. More particularly, the rules can trigger an alert if: the overall UX score in any location is less than 70% in the past 24 hours; if there are more than 5% or 100 devices seeing a 500 error for web monitors; a particular device has not sent any data for a predetermined or selected amount of time (e.g. in the last 4 hours); a traceroute probe did not complete; a user has a predetermined or selected number of failed web monitor requests within predetermined or selected period of time, for example, 3 failed web monitor requests in 10 minutes (alerts can be throttled so that it triggers only once in an hour for failed logins from the same user); a web application has more than a predetermined or selected number of errors and/or a page fetch time greater than a predetermined or selected time more than a predetermined or selected number of times in a row; a UX score in a specific location becomes below average for that region; and a UX score within a setup geofence degrades from good to okay, such as below 66%.
determining, according to the detection data and a data threshold corresponding to an abnormal event, that the detection event is the abnormal event(alerts of a certain severity (threshold) are identified and displayed dashboard area of user interface, ¶108)
[0108] FIG. 21 is a GUI of an alerts dashboard. This includes a number of high severity alerts and a number of application, network, and device alerts. The alerts dashboard further includes a visualization of active alert distribution, a listing of high severity alerts, and a list of the most recent active alerts. FIG. 22 is a GUI of a performance dashboard. This includes the overall UEX score, an indication of the most impacted location and application, a map of global UEX score, and a graph of UEX score over time. FIG. 23 is a GUI of a user dashboard illustrating a single user. FIG. 24 is a GUI of an application dashboard illustrating a single application.
and displaying the detection event in a detection event region of a detection interface, the detection data in a data display region of the detection interface(summary/details of events that generated alerts are display in dashboard, ¶s108,169).
[0108] FIG. 21 is a GUI of an alerts dashboard. This includes a number of high severity alerts and a number of application, network, and device alerts. The alerts dashboard further includes a visualization of active alert distribution, a listing of high severity alerts, and a list of the most recent active alerts. FIG. 22 is a GUI of a performance dashboard. This includes the overall UEX score, an indication of the most impacted location and application, a map of global UEX score, and a graph of UEX score over time. FIG. 23 is a GUI of a user dashboard illustrating a single user. FIG. 24 is a GUI of an application dashboard illustrating a single application
[0169] FIG. 47 is diagram of a browser extension 1000 on a user device 300 communicating to the cloud-based system 100, such for RUM. Also, the browser extension 1000 can include the UPM browser extension described herein. This RUM feature helps us get a true real picture of the user's experience by having a plugin installed on a browser or the like executed on the user device 300 that can post the RUM metrics to either an intermediate aggregator such as the application 350 or directly to a data lake, such as in the cloud-based system 100. This approach is different from the traditional RUM solutions where the destination server injects a JavaScript (JS) into the web pages it is serving and gets the RUM statistics from the user's browser which only that provider can view. In our approach, the IT admin of the organization can configure any domain/URL or list of domains/URLs to be monitored and the plugin will calculate the RUM Statistics/Metrics for domains/URLs specified and push calculated Statistics/Metrics to our data lake for analysis that the customer can view. This gives our customers the unique ability to view the RUM Statistics/Metrics of any user in their org to get an insight into their digital experience.
further including highlighting the abnormal event to obtain a processed abnormal event(event alerts an include highlighting details of the alert/event displaying heat maps, ¶ 122)
displaying the processed abnormal event in the detection event region of the detection interface(event alerts an include highlighting details of the alert/event displaying heat maps, ¶s122,123)
[0122] A first user case can be how is the real user experience accessing key SaaS business applications? This can be determined by measuring performance from the user browser, when the user visits actual pages of key SaaS applications (ex: Office365, salesforce, workday, etc.). The UEX score can be based on page load timings, network delays, and system metrics during user session time frame. The UEX score metrics can be aggregated by geographic location and application to highlight problems based on default or pre-configured thresholds and metric trends (e.g., 90th percentile, mean) to provide an ability to share or save an interactive snapshot of the problem as part of a service escalation.
[0123] A second use case can be are there any high network latency or delays to key destinations from user devices—with and without the cloud? This can include scheduling ICMP tests to periodically measure network performance to a discrete network or application domain and reporting My Traceroute (MTR) style metrics (min/max/avg Latency, Jitter, % Loss). This can be measured with and without any proxy and used to display topology flow graph with latency at each hop, aggregate performance metrics by geographic location and application, and highlight problems based on default or pre-configured thresholds to provide an ability to share an interactive snapshot of the problem as part of a service escalation.
generating alarm information for the abnormal event(trigger an action such as generate and sending an email to one or more users, ¶141-142)
and pushing the alarm information to a target object of the abnormal event(trigger an action such as generate and sending an email to one or more users, ¶141-142)
[0141] The list view can include a number of columns providing information with regards to each alert. The list view can include columns for alert identification, an alert name, an alert status (active, cleared, disabled, muted), an alert start time, an alert duration (no end time if alert still active), a monitor name (source of the alert), metrics values that caused the alert to trigger, action taken (email) with a link to the Alert action, impacted geo locations with a score, impacted locations with a score, impacted applications with score, number of impacted users (with link to users), impacted groups, impact departments, impacted device types, and the like.
[0142] The list view of the alerts can be configured to auto refresh on a predetermined or selected time interval, such as once a minute. The list view can also be sorted based on the columns, and administrators can disable, suppress, and clear a single alerts or multiple alerts in a single action.
wherein the target object is configured to exclude the target content from the data processing link to resolve the abnormal event( a target object i.e. user can clear i.e. exclude the alerts associated with the problem website, ¶142,143).
[0142] The list view of the alerts can be configured to auto refresh on a predetermined or selected time interval, such as once a minute. The list view can also be sorted based on the columns, and administrators can disable, suppress, and clear a single alerts or multiple alerts in a single action.
[0143] Identifiers, such as color coding can be included in the list view of alerts to quickly identify certain aspects of the alerts, such as if the alerts are active, cleared, muted, disabled, and enabled. For example, an active alert can be shown as red for high severity and orange for a warning severity, a cleared alert can be shown as green, a muted alert can be shown as blue, and a disabled alert can be shown as gray.
Regarding claims 4, 11 and 18, Zheng teaches wherein the processing information comprises: a function field, review data, and time data; the determining circulation information of the target content in the plurality of processing nodes using the respective processing information of the plurality of processing nodes comprises(metrics include data such network functionality, user experience data and timing information of the user experience )
[0090] In an embodiment, the monitored data can be from different categories including application-related, network-related, device-related (also can be referred to as endpoint-related), protocol-related, etc. Data can be collected at the application 350 or the cloud edge to quantify user experience for specific applications, i.e., the application-related and device-related data. The cloud-based system 100 can further collect the network-related and the protocol-related data (e.g., Domain Name System (DNS) response time).
[0084] Again, digital experience monitoring includes the capture of data about how end-to-end application availability, latency, and quality appear to the end user from a network perspective. This is limited to the network traffic visibility and not within components, such as what application performance monitoring can accomplish. Networked application monitoring provides the speed and overall quality of networked application delivery to the user in support of key business activities. Infrastructure component interactions include a focus on infrastructure components as they interact via the network, as well as the network delivery of services or applications. This includes the ability to provide network path analytics.
TABLE-US-00001 Application-related data Page Load Time Redirect count (#) Page Response Time Throughput (bps) Document Object Model (DOM) Load Time Total size (bytes) Total Downloaded bytes Page error count (#) App availability (%) Page element count by category (#)
TABLE-US-00002 Network-related data HTTP Request metrics Bandwidth Server response time Jitter Ping packet loss (%) Trace Route Ping round trip DNS lookup trace Packet loss (%) GRE/IPSec tunnel monitoring Latency MTU and bandwidth measurements
arranging and sorting the review data according to the time data to obtain a review experience of the target content(scores of user experience display in time order to visual trends over time, ¶s104-106)
[0104] FIGS. 11-24 are various screenshots of a Graphical User Interface (GUI) associated with the analysis service to display, report, and provide a drill down of the User Experience (UEX) scores. FIG. 11 illustrates a GUI listing locations broken down showing an average score of all users at a location. FIG. 12 illustrates a GUI listing a specific location showing users, their UEX scores, a change in UEX score (e.g., over given time epochs), and impacted applications. FIG. 13 illustrates a graph of a specific user's UEX score over time. FIG. 14 illustrates a graph of a specific location's aggregate UEX score over time. Note, a user can drill down on the graph to display data at particular times when the score is low for troubleshooting.
[0105] FIG. 15 is a GUI of a global dashboard for the cloud-based system 100. Here, the aggregate UEX score is displayed (all users). There is a listing of application alerts (e.g., threshold crossings), mobile devices, desktop devices, etc. A map displays the global UEX score using color codes for visual indication of locations with good, okay, and poor UEX scores. Again, this visualization can be used for drill down and remediation.
[0106] FIG. 16 is a GUI of times in the global dashboard displaying top impacted users, top impacted applications, active alert distribution, and user distribution by UEX score. FIG. 17 is a GUI of a graph of UEX score over time. FIGS. 18 and 19 are a GUI of a dashboard for an individual user. Specifically, the UEX score, location, bandwidth, latency, packet loss, response time, and availability are displayed as are graphs of the UEX score over time and bandwidth for the user in FIG. 18. FIG. 19 includes a graph of various performance metrics over time. Note, the lower performance metrics correlate to lower UEX score.
parsing the function field to obtain a preprocessing experience of the target content, the preprocessing experience representing normalized processing for the target content before reviewed; and(the obtains historical values as a baseline/average(i.e. preprocessing ) to compare to current monitored values in generate experience scores, ¶s85, 137)
[0085] The cloud-based system 100 can enable real-time performance and behaviors for troubleshooting in the current state of the environment, historical performance and behaviors to understand what occurred or what is trending over time, predictive behaviors by leveraging analytics technologies to distill and create actionable items from the large dataset collected across the various data sources, and the like. The cloud-based system 100 includes the ability to directly ingest any of the following data sources network device-generated health data, network device-generated traffic data, including flow-based data sources inclusive of NetFlow and IPFIX, raw network packet analysis to identify application types and performance characteristics, HTTP request metrics, etc. The cloud-based system 100 can operate at 10 gigabits (10 G) Ethernet and higher at full line rate and support a rate of 100,000 or more flows per second or higher.
determining an integration result of the preprocessing experience and the review experience as the circulation information of the target content among the plurality of processing nodes(comparison of user experience to historical average values to determine if difference to historical averages meets criteria for being anomalous, ¶137)
[0137] The determination of when an alert is raised can be based on baselined data. For example, one vendor can compare the metric value to a weighted average of all historical metric data and if the value is greater than the average value by a predetermined or selected value of standard deviations, then the alert is raised.
Regarding claims 7, 14 and 20, Zheng teaches wherein the collecting data for the detection event to obtain detection data corresponding to the detection event comprises :collecting, when a detection time point is reached, data of the detection event within the preset time range to obtain the detection data of the detection event(metric data is retrieved periodically where detection of events/anomalies is performed over the period, ¶185).
[0185] The process 1050 includes operating an add on for a web browser (1051); receiving a list of domains or Uniform Resource Locators (URLs) to calculate RUM data thereon (step 1052); responsive to the web browser accessing any of the domains or URLs in the list, calculating and storing RUM data (step 1053); and periodically sending the stored RUM data to a cloud-based system (step 1054). The RUM data can include statistics, metrics, and errors that are detected based on any of start of navigation, redirects, Domain Name System (DBS), connection establishment and teardown, Hypertext Transfer Protocol (HTTP) request and response start and end, Document Object Model (DOM) load time, page load time, and Java Script and AJAX error detection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Zheng as applied to claims 1 8 and 15 above, and further in view of Liu US 2016/0309233.
Regarding claims 3, 10 and 17, Zheng teaches wherein the obtaining, in response to a detection trigger instruction, processing information of a plurality of processing nodes in a data processing link for a target content comprises(administrator configure monitoring of a network specifying specific URL to be monitored and conditions and triggers for alerts and other action to be performed on monitored URLs., ¶s 38,126,169).
Zheng does not teach performing, in response to the detection trigger instruction, bypass backup on a processing result of each of the processing nodes for the target content to obtain bypass information of each of the processing nodes, and collecting the bypass information of each of the processing nodes via a message queue; and obtaining, from the message queue, the respective bypass information of the plurality of processing nodes to obtain the processing information of the plurality of processing nodes for the target content.
Liu in the same field of endeavor as the invention teaches a system for content delivery. Liu teaches performing, in response to the detection trigger instruction, bypass backup on a processing result of each of the processing nodes for the target content to obtain bypass information of each of the processing nodes(backup notification message that indicate the result i.e. success of video delivery is maintained in message queue, and backup message queue, ¶s81-83),
and collecting the bypass information of each of the processing nodes via a message queue(notification message placed in queue, ¶s 81-83);
and obtaining, from the message queue, the respective bypass information of the plurality of processing nodes to obtain the processing information of the plurality of processing nodes for the target content(notification of is read out from queue upon delivery of video content, ¶s81-83).
[0081] Here the backup queue of messages is particularly a backup queue of messages stored in advance in the queue storage device, and the storage capacity of the backup queue of messages is larger or equal to the storage capacity of the queue of messages. Of course, preferably the backup queue of messages is stored in advance in a large-capacity hard disk or database of the distribution server, so that after the storage capacity of the queue of messages is saturated, the notification message received beyond the preset largest amount of data stored in the queue of messages can be added from the queue of messages to the backup queue of messages to thereby avoid the notification message from being lost.
[0082] The searching and processing unit 403 is configured to search for and distribute the video corresponding to the distributed storage address in the notification message, and if the distribution is finished, to delete the notification message corresponding to the video from the queue of messages; or if the distribution is interrupted, to put the notification message corresponding to the video at the end of the queue of messages to wait for processing.
[0083] It shall be noted that the distribution of the distributed and stored video product to the media resource system still may be interrupted due to a network delay, an overtime response, or other reasons, and if the video product, the distribution of which is interrupted is distributed repeatedly in the distribution-failure repeating mechanism all the time, the subsequent video products can not be distributed in a timely manner to the media resource system for playing, so the searching and processing unit 403 puts the notification message corresponding to the video product, the distribution of which is interrupted, at the end of the queue of messages to further wait for processing, so that the media resource system can read the subsequent notification messages in the queue of messages, and operate to distribute the videos accordingly. If the media resource system reads the notification message of the video, and distributes the video but fails again, the notification message will be put again at the end of the queue of messages to wait for processing until the video is distributed successfully to the media resource system, and the notification message corresponding thereto will be deleted.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Zheng with use of queues to maintain delivery notification messages. The reason for this modification would be to provide a method for tracking delivery status of content.
Claims 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Zheng as applied to claims 1 and 8 above, and further in view of Danyi US 11,582,316.
Regarding claims 5 and 12, Zheng teaches wherein after the determining circulation information of the target content in the plurality of processing nodes using the respective processing information of the plurality of processing nodes, the method further comprises(metrics regarding the processing and url/web request metrics are generated for the nodes hosting content, ¶s87,88,91)
[0087] Metrics could be combined. For example, device health can be based on a combination of CPU, memory, etc. Network health could be a combination of Wi-Fi/LAN connection health, latency, etc. Application health could be a combination of response time, page loads, etc. The cloud-based system 100 can generate service health as a combination of CPU, memory, and the load time of the service while processing a user's request. The network health could be based on the number of network path(s), latency, packet loss, etc.
[0088] The lightweight connector 400 can also generate similar metrics for the applications 402, 404. In an embodiment, the metrics can be collected while a user is accessing specific applications that user experience is desired for monitoring. In another embodiment, the metrics can be enriched by triggering synthetic measurements in the context of an inline transaction by the application 350 or cloud edge. The metrics can be tagged with metadata (user, time, app, etc.) and sent to a logging and analytics service for aggregation, analysis, and reporting. Further, network administrators can get UEX reports from the cloud-based system 100. Due to the inline nature and the fact the cloud-based system 100 is an overlay (in-between users and services/applications), the cloud-based system 100 enables the ability to capture user experience metric data continuously and to log such data historically. As such, a network administrator can have a long-term detailed view of the network and associated user experience.
[0091] An example of HTTP Request metrics includes CONNECT, time to first byte/first 10 bytes, time to last byte, Secure Sockets Layer (SSL) handshake time, etc. For example, HTTP can be used to send probes to take measurements as described in commonly-assigned U.S. patent application Ser. No. 16/043,250, filed Jun. 24, 2018, and entitled “Cloud services management systems utilizing in-band communication conveying situational awareness,” the contents of which are incorporated by reference herein.
Zheng teaches determining sub-circulation information(sub request for object in a content page, ¶121) but does not teach displaying, in response to a trigger operation for an information query interface, the information query interface; obtaining, in response to an input operation for an information input region in the information query interface, a to-be-searched identifier corresponding to the to-be-searched content, the to-be-searched content being contained in the target content;
extracting target sub-circulation information of the to-be-searched content from the circulation information according to the to-be-searched identifier; and switching from the information query interface to a circulation information interface in response to an interface switching operation, and displaying the target sub-circulation information on the circulation information interface.
Danyi in the same field of endeavor as the invention teaches a system for metric aggregation for user experience monitoring. Danyi teaches displaying, in response to a trigger operation for an information query interface, the information query interface(GUI allows selection of URL, Col 50 Lines 40-67)
obtaining, in response to an input operation for an information input region in the information query interface, a to-be-searched identifier corresponding to the to-be-searched content, the to-be-searched content being contained in the target content(metric for selected URL are obtained, Col 50 Lines 40-67)
extracting target sub-circulation information of the to-be-searched content from the circulation information according to the to-be-searched identifier; and switching from the information query interface to a circulation information interface in response to an interface switching operation, and displaying the target sub-circulation information on the circulation information interface(information of related metric of content related (child objects access/child spans) to the selected URL are obtained such metric are displayed in side panel, Col 50 Lines 40-67, . Col 56 Lines 48-64).
[(274) In one implementation, when a node associated with a normalized URL is selected, aggregated metrics for the node may be displayed in a side-panel, e.g., the side-panel 1902 in FIG. 19A. By aggregating metrics along the normalized URL as the dimension, meaningful data can be computed and displayed to the user through an on-screen GUI.
(275) FIG. 19B illustrates an example manner in which a group of related URLs may be normalized, in accordance with implementations of the monitoring service disclosed herein. Column 1988 of table 1950 shown in FIG. 19B comprises several unique but related URLs. The URLs in column 1988 are associated with a common path “lab.corp.signalfx.com/v2/dashboard” which, in one implementation, may be normalized by representing the final segment in the URL (which is unique for each URL in column 1988) with a wildcard “*”. Accordingly, the URLs in column 1988 may be normalized and represented by the normalized URL shown in column 1987 “lab.corp.signalfx.com/v2/dashboard/*”.
(276) FIG. 19C illustrates the manner in which aggregated metrics for normalized URLs may be displayed in an exemplary on-screen GUI, in accordance with implementations of the monitoring service disclosed herein. As shown in FIG. 19C, metrics associated with the normalized URLs may be displayed to a user through the on-screen GUI 1970. The metrics may be computed by aggregating metrics associated with each of the pages or websites grouped by the normalized URL. For each normalized URL, metrics such as the frontend errors 1972, endpoint errors 1973, and endpoint latency 1974 may be computed and displayed. Further, the highest P90 page load times 1971 and top pages/view 1978 for each normalized URL may be displayed. Also, web vitals, e.g., largest contentful paint 1975, cumulative layout shift 1976 and first input delay 1977 for each normalized URL may be shown in GUI 1970. Col 50 Lines 40-67]
[(311) The spans displayed may be root-level or parent spans (e.g., span 2052) that can be expanded out to reveal other child spans (e.g., spans 2053, 2054, etc.). For example, the document load event associated with parent span 2052 may be a combination of other sub-events, e.g., a document fetch associated with the child span 2053 and other different resource accesses such as the one associated with child span 2054. Although not shown in FIG. 20A, in one implementation, each of the spans shown in the waterfall view of the panel 2050 is displayed adjacent to an icon indicating whether one or more errors are associated with the span. Displaying an error status of a span enables a client to visually identify whether a particular span needs to be explored further. Note that each of the spans (including both the parent and children spans) may be expanded out to get further information regarding the various attributes associated with the spans, as shown in connection with FIG. 20B. Col 56 Lines 48-64]
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Zheng with a GUI that determines and displays access metrics of sub requested content tied to a root/ initial URL accessed. The reason for this modification would be to provide additional metrics to evaluate user’s experiences with web content access.
Claims 6, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Zheng as applied to claims 1 8 and 15 above, and further in view of Sharma US 2021/0219025, Kumar US 10,178,067 and Howe 2024/0129321.
Regarding claims 6, 13 and 19, Zheng teaches wherein the detection data comprises at least number of generations of processing information representing the failure of processing by the processing node(number of errors, ¶129)
number of processing time of the processing node for the target content within a preset time range(number page fetch time exceeding a predetermined/selected time, ¶129),
[0129] Any combination of rules can be established relative to the inline monitoring and the data and metrics collected therewith. For example, the rules can include one or more of the following: (1) when a UX score degrades by certain threshold percentage over a predetermined or selected period of time; and (2) any of the metrics of the inline monitoring meets a predetermined or selected threshold for the respective metric, such as a UX score, network latency (per log), percentage of packet loss (per leg), total hop count, per leg hop count, incomplete traceroutes, DNS time, Page Fetch Time, availability (HTTP errors), and device health metrics. More particularly, the rules can trigger an alert if: the overall UX score in any location is less than 70% in the past 24 hours; if there are more than 5% or 100 devices seeing a 500 error for web monitors; a particular device has not sent any data for a predetermined or selected amount of time (e.g. in the last 4 hours); a traceroute probe did not complete; a user has a predetermined or selected number of failed web monitor requests within predetermined or selected period of time, for example, 3 failed web monitor requests in 10 minutes (alerts can be throttled so that it triggers only once in an hour for failed logins from the same user); a web application has more than a predetermined or selected number of errors and/or a page fetch time greater than a predetermined or selected time more than a predetermined or selected number of times in a row; a UX score in a specific location becomes below average for that region; and a UX score within a setup geofence degrades from good to okay, such as below 66%.
Zheng does not specifically teach detection metric including number of invocations for the processing node,
number of generations of processing information representing the success of processing by the processing node,
number of anomalies of an account of the target content,
and quantity of abnormal fields contained in the target content
Sharma in the same field of endeavor as the invention teaches a system for content delivery. Sharma teaches detection metric including number of invocations for the processing node(total count of content selection, ¶60)
number of generations of processing information representing the success of processing by the processing node(hit count, ¶60)
[0060] The warm-up evaluator 235 may be adapted to calculate, and/or otherwise determine one or more parameters related to operation of the media warm-up processing module 230. For example, the warm-up evaluator 235 may track one or more of a total count, e.g., a number of overall viewer media content selections, a success or “hit” count or number of those media content selections that were served by warmed-up content and/or a failure or “miss” count or number of those media content selections that could not be served by warmed-up content, e.g., resulting in a cold-start process 203 (FIG. 2A). One or more metrics can be determined based one or more of the counts, such as success or hit rates, failure or miss rates, rations of hits to total, hits to misses, misses to total, misses to hits, and so on.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Zheng with tracking total request, total successes(i.e. hits) and total failure(misses) as taught by Sharma to the URL request metrics of Zheng. The reason for this modification would be to provide metrics total number of requests, number of request failures and successes for deriving performance metrics ratio of page request successes/failure
Kumar in the same field of endeavor as the invention teaches a content delivery system. Kumar teaches number of anomalies of an account of the target content(number of error per customer(i.e. account) in a period of time, Col 10 Line 54- Col; 11 Line 10)
[(37) Roll up tables 214 store and aggregate information related to the plurality of users accessing customer-facing portal applications and contextualize the information for display to administrators via the dashboard. In some examples, this information includes user behavioral and statistical data, such as the number of customer logins per hour, day, or month. In some examples, this information includes information describing events per customer, such as the number of errors or exceptions per customer over a particular amount of time. In some examples, this information includes the frequency of monitoring performed by application platform monitor 132. For example, different applications of applications 130 may generate log files hourly, daily, or weekly. In some examples, this information includes metadata describing hierarchical details of each customer. For example, this metadata may include information describing the customer, such as the organization name, each child account associated with the customer, and license or security permissions for the customer. Further, the metadata may include geographic information, such the continent, country, city/metro area, and data center the customer accesses. In some examples, roll-up tables 214 allow aggregation of user data such that it may be displayed via the dashboard at different hierarchical levels. Col 10 Line 54- Col; 11 Line 10]
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Zheng/Sharma with determining per customer(i.e. account) errors as taught by Kumar. The reason for this modification would be to provide additional metrics to evaluate user experience in content delivery system
Howe in the same field of endeavor as the invention teaches a content distribution system. Howe teaches quantity of abnormal fields contained in the target content(number of page errors, ¶147).
[0147] “Application-related” data may include, for example, a) page load time, b) page response time, c) Document Object Module (DOM) load time, d) total downloaded bytes, e) app availability (%), f) redirect count (#), g) throughput (bps), h) total size (bytes), i) page error count (#), j) page element count by category (#), etc. “Network-related” data may include, for example, a) http request metrics, b) server response time, c) ping packet loss (%), d) ping round trip, e) packet loss (%), f) latency, g) bandwidth, h) jitter, i) trace route, j) DNS lookup trace, k) GRE/IPSec tunnel monitoring, l) MTU and bandwidth measurements, etc. “Device-related data” (or endpoint-related data) may include, for example, a) system details, b) Central Processing Unit (CPU), c) memory (RAM), d) network interfaces, e) network config, f) disk, g) processes, h) applications, etc.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Zheng/Sharma/Kumar with determining the number of errors per page as taught by Howe. The reason for this modification would be to provide additional metrics to evaluate user experience in content delivery system.
Applicant Remarks
The applicant’s arguments on page 11 of the remarks, recites alleged aspect that are not supported or present in the specification: “At the end of the process, the suspicious content that "clogs" the processing link is excluded from the processing link,"thereby improving the stability of the data processing link during data processing" ([00145]). “ . ¶145 does not describe excluding a processing link as a first matter. Further as a second matter such an exclusion is not recited in the claims. Thus such arguments are beyond scope and thus moot.
The applicant further argues on page 12 of the remarks that the cited art Zheng does not have the capability to exclude a URL from the list of URL because the abnormal event in Zheng is caused by network activities are different components, not by a particular URL. The examiner contends such arguments are moot in view of the fact that the claim do not recite excluding a URLs. Thus aspects are not required to be taught by the prior art rendering such arguments moot.
The applicant argues that the remainder of the claims 5, 12 and 6, 13, 19 are patentable over the alleged deficiencies of Zheng. The examiner contends that rejection of claims 1, 8 and 15 are proper as discussed above, thus the rejection of claim 5, 12, 6, 13 and 19 are also proper.
Prior Art Cited But Not Used In The Rejection
US 2011/0264757 - NOTICE OF RESTORED MALFUNCTIONING LINKS
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455
Prosecution Insights