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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-4, 8-12, 16-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over RACHELS (US PUBLICATION 20210392032) in view of FLERL (US PUBLICATION 20180157685) and in further view of HUNTER (US PUBLICATION 20220156138).
In regards to claim 1, RACHELS teaches a method comprising: receiving, by at least one processor via a particular application programming interface (API) of an administration service, a performance incident indication indicative of a performance incident associated with at least one application service; (P.0016) “The apparatuses, methods, and non-transitory computer readable media disclosed herein may provide for a geo-distributed service to notify a service consumer (e.g., entity as disclosed herein) of an incident that may require an action by the service consumer” (P.0031) “the apparatus 100 may include an incident detection module 102 to detect, with respect to a notification service 124 of a plurality of notification services 126, based on an analysis of signals received at an activity event hub 104 of an internal incident management service 130 of an entity 108, at least one incident 106 associated with activities of the entity 108.” (P.0055) “According to an example, the data endpoint 112 may be an open data protocol (OData) endpoint, where the open data protocol may represent a REST application programming interface (API) protocol.” wherein the performance incident indication comprises: an incident type identifier identifying a type of the performance incident and at least one application service identifier identifying the at least one application service; (P.0053) “ABC.EventType′=′IncidentAdd′ ABC.Owner′=′<null>′ ABC.OwningServiceName′=′PowerBI′ . . .
For the snippet above, “IncidentDataSource” may be described as the instance of the incident provider (e.g., FIG. 4, incident management service 130), “IncidentId” may be described as a unique identifier for the incident (not consumed by the notification service), “Title” may be described as a descriptive title of the incident, “Severity” may be described as a severity level of the incident (not consumed by the notification service), “Status” may be described as a status of the incident (not consumed by the notification service), “EventType” may be described as a type of change committed to the record—checked for control flow and merged with the identification for the ID+Event primary key” determining, by the at least one processor, using the administration service, a performance incident status based at least in part on the performance incident indication; (P.0035) “the incident analysis module 110 may determine, based on the analysis of the at least one detected incident 106, whether the at least one detected incident 106 is actionable by analyzing an event type associated with the at least one detected incident 106.” (P.0054) “Data that is analyzed with respect to the activity event hub 104 may include a service name (e.g., owning service name) that is being targeted with respect to the incident, and an event type. An example of an incident that is not actionable may include a service that is not in a specified service list (e.g., an Excel™ incident). An example of an incident that is actionable may include a service related, for example, to a Power BI™ (PBI) service” determining, by the at least one processor, using the administration service, at least one message comprising a notification of the performance incident based at least in part on: the performance incident status and the incident type identifier; (P.0039) “the incident notification module 116 may generate, based on the received information 114 related to the at least one detected incident 106, the notification object 118 that specifies details of the at least one detected incident 106 and an indication of a communication technique 120 that is to be utilized to communicate the at least one detected incident 106 to the entity 108.” (P.0055)
PNG
media_image1.png
577
467
media_image1.png
Greyscale
”
However RACHELS doesn’t teach determining, by the at least one processor, using the administration service, at least one front-end associated with the at least one application service; generating, by the at least one processor, using at least one front-end specific adapter of a plurality of adapters of the particular API, at least one front-end specific API call to the at least one front-end; updating, by the at least one processor, the at least one front-end with the at least one message using the at least one front-end specific API call so as to cause the at least one front-end to render the at least one message with front-end specific formatting.
FLERL teaches, determining, by the at least one processor, using the administration service, at least one front-end associated with the at least one application service; (P.0040) “The integration hub 9 may interface with the application 19 on the company device 17 in order to provide the user 21 with monitoring information.” (P.0051) “In one embodiment the integration server 9 may receive notification that a ticket state has changed and notify a user. If a ticket state is changed the integration server 9 is notified either from the service application 5 or from the mobile application 19 (if the state was modified on the mobile device 17). The integration server 9 then updates the mobile application 19 via the REST API.” generating, by the at least one processor, using at least one front-end specific adapter of a plurality of adapters of the particular API, at least one front-end specific API call to the at least one front-end; (P.0049) “The integration server 9 communicates with the mobile application 19 through a separate protocol (e.g., the Representational State Transfer (REST) protocol). In addition, the integration server 9: (a) creates HTTPS connections to the servers associated with the monitoring application 7 and the service application 5 (not the individual servers associated with the user 21) by utilizing the corresponding APIs, (b) connects to a notification system, such as Amazon's Simple Notification Service (SNS) and/or Google's Firebase Cloud Messaging, to send push notifications when ticket states are changed in the service application 5, (c) uses credentials from the service application 5 to validate the mobile application user's credentials and (d) routes mobile application requests to either the monitoring application 7 or the service application 5, depending on the request type.” (P.0051) “if the mobile application 19 is not open or displayed in the device 17 the notification appears on the home screen of the mobile device 17.” updating, by the at least one processor, the at least one front-end with the at least one message using the at least one front-end specific API call so as to cause the at least one front-end to render the at least one message with front-end specific formatting; (P.0051) “The integration server 9 then updates the mobile application 19 via the REST API. The user 21 may then see a visual indicator in the menu area as well as in the notifications list. In one embodiment, if the mobile application 19 is not open or displayed in the device 17 the notification appears on the home screen of the mobile device 17.”
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing of the claimed invention to combine the teachings of Flerl to the teachings of Rachels in order to provide the user with real time insight into monitored database nodes via a single, mobile point of access.
However RACHELS and FLERL both do not teach generating, by the at least one processor, using at least one public status page specific adapter of a plurality of adapters of the particular API, at least one public status page specific API call to at least one public status page; updating, by the at least one processor, using the at least one public status page specific adapter of the plurality of adapters of the particular API, the at least one public status page with the at least one message using the at least one public status page specific API call so as to cause the at least one public status page to render the at least one message with public status page specific formatting; and updating, by the at least one processor, a user interface of the administrative service to present an application status indicating that the at least one front-end is updated with the at least one message.
HUNTER teaches generating, by the at least one processor, using at least one public status page specific adapter of a plurality of adapters of the particular API, at least one public status page specific API call to at least one public status page; (P.0101) “ the assistant program 109 communicates with the communication tool (e.g., via its API) when user interface 900 is activated to retrieve a list of all status updates created for the affected service/product in the time period between when the alert was first created and the current time.” (P.0042) “the incident management system 106 is shown as being part of and running on the ITS server 102. In some embodiments, the incident management system 106 may not reside on the ITS server 102 but as a stand-alone system that is communicatively coupled to the ITS to receive/forward issue and incident related data from/to the ITS server 102. Further, in some embodiments, the incident management system 106 may be communicatively coupled to one or more other incident management platforms (such as Opsgenie offered by Atlassian, Inc.) to send alerts to helpdesk staff once an incident is detected and/or communication tools (such as Statuspage) to forward application/service status information to the corresponding application/services.” (P.0104) “Deflection bugs are essentially records of bugs maintained in a public bug tracking tool (such as JAC) to communicate outages and critical bugs to customers.” updating, by the at least one processor, using the at least one public status page specific adapter of the plurality of adapters of the particular API, the at least one public status page with the at least one message using the at least one public status page specific API call so as to cause the at least one public status page to render the at least one message with public status page specific formatting; (P.0100) “Statuspage helps organizations inform customers about outages and scheduled maintenance. Customers can subscribe to updates via email or text messages when an incident is reported on the organization's webpage, and updates can also be embedded directly into other interfaces and web properties.” (P.0102) “the user may select the selectable affordance to create a new status update. Selection of the selectable affordance results in the assistant program 109 forwarding instructions to the client to render a new pop-up user interface. This user interface (not shown), may provide one or more templates for creating the status update message. Once the status update message is created, the status update message may be communicated directly to the communication tool to post on the organization's webpage at step 622.” (P.0101) “when user interface 900 is activated to retrieve a list of all status updates created for the affected service/product in the time period between when the alert was first created and the current time.” and updating, by the at least one processor, a user interface of the administrative service to present an application status indicating that the at least one front-end is updated with the at least one message. (P.0101) “The user interface 900 includes a list of existing status updates 902 and a selectable affordance 904 to create a new status update. To display this list of existing status updates, the assistant program 109 communicates with the communication tool (e.g., via its API) when user interface 900 is activated to retrieve a list of all status updates created for the affected service/product in the time period between when the alert was first created and the current time.”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing of the claimed invention to apply Hunter to the combination of Rachels and Flerl in order to inform customers about outages and scheduled maintenance on the organizations webpage, and to provide a helpdesk user with visibility into the current status updates that have been posted for the identified incident.
In regards to claim 2, HUNTER teaches wherein the performance incident indication comprises a geographic location associated with the performance incident. (P.0067) “ the threshold value may vary for different geographical areas—higher values in geographical areas that have higher number of customers and lower values in geographical areas that have fewer numbers of customers.” (P.0072) “the relevant support staff may be selected based on the application/service ID associated with a majority of the created issues and/or a geographical location where a majority of the issues were created.”
Therefore, it would be obvious for one of ordinary skill in the art before the effective filing date to apply Hunters teachings to the teachings of Rachels in order to allow the threshold value used to detect a potential incident to vary based on geographical areas that have higher or lower numbers of customers.
In regards to claim 3, HUNTER teaches determining, by the at least one processor, using the administration service, at least one message for alerting at least one user of the performance incident based at least in part on the geographic location. (P.0072) “This static list may be configured such that a list of relevant support staff are provided for each of the application/services the ITS is responsible for and for different geographical locations in which the ITS operates. In this case, the relevant support staff may be selected based on the application/service ID associated with a majority of the created issues and/or a geographical location where a majority of the issues were created.” (P.0073) “once one or more relevant users are identified, the incident detection module 107 sends an alert to the identified relevant person(s)”
Therefore it would be obvious for one of ordinary skill in the art before the effective filing date to apply Hunters teachings to the teachings of Rachels in order to identify and alert the relevant support staff responsible for the geographical location where a majority of the affected issues were created.
In regards to claim 4, HUNTER teaches wherein the at least one front-end comprises a geographic location. (P.0072) “In this case, the relevant support staff may be selected based on the application/service ID associated with a majority of the created issues and/or a geographical location where a majority of the issues were created.”
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date to apply Hunters teachings to the teachings of Rachels to identify the geographical location associated with the customers whose devices generated the issues underlying the potential incident.
In regards to claim 8, RACHELS teaches receiving, by at least one processor via the particular API of the administration service, an updated performance incident indication indicative of an updated status of the performance incident associated with at least one application service; (P.0017) “the operational data may be characterized as incidents that each include an add incident state, an edit incident state, and a mitigate incident state. The add incident state, edit incident state, and mitigate incident state may correspond to initial, update, and finalization events associated with an incident.” determining, by the at least one processor, using the administration service, an updated performance incident status based at least in part on the updated performance incident indication; (P.0017) “With respect to edit incident state, the payload may be the same as an initial event (e.g., add incident state) except that the event type will differ.” (P.0035) “the incident analysis module 110 may determine, based on the analysis of the at least one detected incident 106, whether the at least one detected incident 106 is actionable by analyzing an event type associated with the at least one detected incident 106.” determining, by the at least one processor, using the administration service, at least one updated message comprising an updated notification of the updated to the performance incident based at least in part on the updated performance incident indication indicative; (P.0055) “For relevant incident actions (e.g., incidents that are actionable), the incident analysis module 110 may query the data endpoint 112 for more information 114 (e.g., incident information 114) about the incident 106. According to an example, the data endpoint 112 may be an open data protocol (OData) endpoint, where the open data protocol may represent a REST application programming interface (API) protocol. The information 114 about the incident 106 may include any type of information that specifies whether an action (e.g., an alert) is to be taken with respect to the incident 106. For example, an incident 106 related to a prototype deployment of a service may not need to be notified to a customer (e.g., the entity 108), whereas an incident 106 related to an operational deployment of a service may need to be notified to the customer. An example of a data endpoint 112 snippet, which would generate a notification object since it has data in the relevant IncidentNotification custom fields, is as follows:
PNG
media_image2.png
149
367
media_image2.png
Greyscale
”
However, RACHELS does not teach updating, by the at least one processor, using the at least one public status page specific adapter of the plurality of adapters of the particular API, the at least one public status page with the at least one updated message using the at least one public status page specific API call so as to cause the at least one public status page to render the at least one updated message with public status page specific formatting; and updating, by the at least one processor, the user interface of the administrative service to present the application status indicating that the at least one front-end is updated with the at least one updated message.
HUNTER teaches updating, by the at least one processor, using the at least one public status page specific adapter of the plurality of adapters of the particular API, the at least one public status page with the at least one updated message using the at least one public status page specific API call so as to cause the at least one public status page to render the at least one updated message with public status page specific formatting; (P.0102) “This user interface (not shown), may provide one or more templates for creating the status update message. Once the status update message is created, the status update message may be communicated directly to the communication tool to post on the organization's webpage” (P.0100) “Statuspage helps organizations inform customers about outages and scheduled maintenance. Customers can subscribe to updates via email or text messages when an incident is reported on the organization's webpage, and updates can also be embedded directly into other interfaces and web properties.” and updating, by the at least one processor, the user interface of the administrative service to present the application status indicating that the at least one front-end is updated with the at least one updated message. (P.0101) “The user interface 900 includes a list of existing status updates 902 and a selectable affordance 904 to create a new status update. To display this list of existing status updates, the assistant program 109 communicates with the communication tool (e.g., via its API) when user interface 900 is activated to retrieve a list of all status updates created for the affected service/product in the time period between when the alert was first created and the current time.”
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hunter to the teachings of Rachels in order to inform customers about outages and scheduled maintenance on the organizations webpage and to provide a help desk user with visibility into the current status updates that have been posted for the identified incident.
However RACHELS and HUNTER both do not teach updating, by the at least one processor, the at least one front-end with the at least one updated message using the at least one front-end specific API call so as to cause the at least one front-end to render the at least one updated message with the front-end specific formatting;
FLERL teaches updating, by the at least one processor, the at least one front-end with the at least one updated message using the at least one front-end specific API call so as to cause the at least one front-end to render the at least one updated message with the front-end specific formatting; (P.0051) “the integration server 9 may receive notification that a ticket state has changed and notify a user. If a ticket state is changed the integration server 9 is notified either from the service application 5 or from the mobile application 19 (if the state was modified on the mobile device 17). The integration server 9 then updates the mobile application 19 via the REST API. The user 21 may then see a visual indicator in the menu area as well as in the notifications list. In one embodiment, if the mobile application 19 is not open or displayed in the device 17 the notification appears on the home screen of the mobile device 17.” (P.0049) “connects to a notification system, such as Amazon's Simple Notification Service (SNS) and/or Google's Firebase Cloud Messaging, to send push notifications when ticket states are changed…”
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Flerl to the combination of Rachels and Hunter in order to update a users mobile application such that they can see the status of their request.
As to claims 9-12 and 16, reference is made to a non-transitory computer readable medium that corresponds to the method of claims 1-4 and 8 respectively and is therefore met by the rejection of claims 1-4 and 8 above.
As to claims 17, reference is made to a system that corresponds to the method of claim 1 and is therefore met by the rejection of claim 1 above. Claim 17 further details the system comprising: “at least one processor in communication with at least one front-end via a network” (Columns 5-6, Lines 47-3)
As to claims 18, reference is made to a system that corresponds to the method of claims 2 and 3 respectively and is therefore met by the rejection of claims 2 and 3 above.
Claim(s) 5, 13, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over RACHELS (US PUBLICATION 20210392032) in view of FLERL (US PUBLICATION 20180157685) and in further view of HUNTER (US PUBLICATION 20220156138) and in further view of HAYWARD (US PUBLICATION 20200084295)
In regards to claim 5, RACHELS, FLERL, and HUNTER teach the claims substantially but do not teach determining, by the at least one processor, using the administration service, at least one language of the at least one message based at least in part on the geographic location of the at least one front-end.
HAYWARD teaches determining, by the at least one processor, using the administration service, at least one language of the at least one message based at least in part on the geographic location of the at least one front-end. (P.0006) “a method that includes one or more of receiving a network request from a client device, detecting that a pre-established policy of a cloud tenant has been triggered based on content included in the received network request, identifying a locale of the client device, retrieving, at runtime, a tenant message in response to the triggered policy and a custom translation of the tenant message based on the identified locale…”(P.0046) “In 530, the method may include identifying a locale of the client device. For example, the locale may be initially registered by a user of the user device. As another example, the locale of the client device may be identified based on application programming interface (API) calls made to an operating system on the client device. Here, the client device may install a mobile application for using the cloud service, and the mobile application may detect, via mobile OS API calls, the user's locale and send this value to the cloud service during registration which may be saved. As another example, the locale of the client device may updated based on a locale field included in the network request received in 510. Each time a message retrieval request (e.g., HTTP GET, HTTP POST, etc.) is sent from the client device, the message retrieval request may include a locale field that is populated by the client device based on a detected locale, a network location, a GPS coordinate, or the like.” (P.0036) “The attributes 310 may include a username such as a name of the end user associated with enrolled mobile device generating the traffic flow, a user group such as a customer defined collection of users (e.g., marketing department, development team, etc.), a destination geographical location such as a country that is associated with the destination IP address of the network request…”
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing of the claimed invention to combine the teachings of Hayward to the teachings of Rachels in order to provide an improved mechanism for localizing messages for could tenants rather than limiting localization to a standard message applied at compile time.
As to claim 13, reference is made to a non-transitory computer readable medium that corresponds to the method of claim 5 and is therefore met by the rejection of claim 5 above.
As to claim 19, reference is made to a system that corresponds to the method of claim 5 and is therefore met by the rejection of claim 5 above.
Claim(s) 6-7, 14-15, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over RACHELS (US PUBLICATION 20210392032) in view of FLERL (US PUBLICATION 20180157685) and in further view of HUNTER (US PUBLICATION 20220156138) and in further view of ROS (US PUBLICATION 20170230808)
In regards to claim 6, RACHELS, FLERL, and HUNTER teach the claims substantially but don’t teach determining, by the at least one processor, at least one application type of the at least one front-end; and modifying, by the at least one processor, the at least one message based at least in part on the at least one application type.
ROS teaches, determining, by the at least one processor, at least one application type of the at least one front-end; and modifying, by the at least one processor, the at least one message based at least in part on the at least one application type. (P.0118) “In this example, MNS End-Devices provide access to one or more MNS End-Points and an MNS End-Point is addressed via one MNS End-Point address. Additionally, the MNS End-Point supports one or more MNS Modalities. Examples of MNS End-Devices, MNS End-Points, MNS End-Point Addresses, and MNS Modalities are shown below in Table 1.” (P.0119) “an MNS Modality is the name of an agreed-upon method of delivery (agreed between the Recipient and MNS System 200, 900 or 1000) based on any of the three Notification Content Types: Audio, Text, and Multi-Media. MNS Modalities are set on a per MNS End-Point Type basis.” \; see also (P.0120-0125)
Therefore, It would be obvious for one of ordinary skill in the art before the effective filing date to combine the teachings of Ros to the teachings of Rachels, Flerl, and Hunter in order to ensure a notification is delivered in a form of content compatible with the receiving end-points rendering ability.
In regards to claim 7, RACHELS, FLERL, and HUNTER teach the claims substantially but don’t teach receiving, by the at least one processor, at least one receipt confirmation from the at least one front-end, the at least one receipt confirmation confirm a receipt and a display of the at least one message by the at least one front-end; and updating, by the at least one processor, the user interface of the administrative service to present status confirmation report indicating that the at least one receipt confirmation of the at least one front-end for the at least one message.
ROS teaches receiving, by the at least one processor, at least one receipt confirmation from the at least one front-end, the at least one receipt confirmation confirm a receipt and a display of the at least one message by the at least one front-end; and updating, by the at least one processor, the user interface of the administrative service to present status confirmation report indicating that the at least one receipt confirmation of the at least one front-end for the at least one message. (P.0085) “Once the MNS End-Point (e.g., 380) of the System End-Device 1030 receives the addressed Notification signal 1048, the System End-Device 1030 displays or transmits the Live Announcement to the Recipient User 1036.” (P.0113) “Upon receiving the Notification message's state change, from “Delivering” to “Delivered,” and given that this is the only active Notification message 372a in the MNS Incident 370a, all Notification messages of this MNS Incident 370a have been delivered by the MNS Notification Engine and that will be reflected on the delivery statistics on the UI for this MNS Incident.”
Therefore, It would be obvious for one of ordinary skill in the art before the effective filing date to combine the teachings of Ros to the teachings of Rachels and Flerl in order to provide a system operator with visibility into whether all notification messages of an incident have been delivered
As to claims 14 and 15, reference is made to a non-transitory computer readable medium that corresponds to the method of claims 6 and 7 and is therefore met by the same rejection above.
As to claim 20, reference is made to a system that corresponds to the method of claim 7 and is therefore met by the rejection above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELMAN MOHAMED ABDULLAHI whose telephone number is (571)272-8556. The examiner can normally be reached 7:30-5:00 (Fri alternating).
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, LEWIS BULLOCK can be reached at (571) 272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SELMAN MOHAMED ABDULLAHI/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights