DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-4, 6-8, 11-14, 16-18, 20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 1-4, 6-8, 11-14, 16-18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Olejar (Pub No: 2024/0389195), and further in view of Colling III (Pub No: 2002/0002633)
As to claim 1, Olejar teaches an apparatus (Olejar, Fig 4 a coordination system) configured to:
retrieve, based on a defined schedule (Olejar, [0052], the retrieval schedule can be automatically based on defined sensors or manually), one or more event-related alerts via a method of procedure (MOP) (Olejar, [0061], retrieving an emergency alert via a series of steps 3A (method of procedure)) ; and
send, based on a first request from a user (Olejar, [0053], the recipient makes a subscription request), information associated with the alert to a management module having a graphical user interface (GUI) portal (Olejar, [0062], send the retrieved emergency alerts to a emergency data subscription system and cloud server 310 which has a GUI on a emergency response application 360B);
Olejar does not explicitly teach identify one or more network site location affected by the one or more event-related alerts; send information associated with the one or more site locations to management; identifying the one or more network site locations, further comprises: retrieve, via a first micro service module, the one or more network site locations; retrieve, via a second micro service module, the information associated with the one or more network site locations, status, the status comprising at least one of: affected, damaged, currently damaged, and battery running
However, Colling teaches identify one or more network site location affected by the one or more event-related alerts (Colling, Fig 3A [0031], determine the location of the event upon an alarm); send information associated with the one or more site locations to management (Colling, Fig 3A [0031], transmit the information identifying the event location); identifying the one or more network site locations, further comprises: retrieve, via a first micro service module, the one or more network site locations (Colling, Fig 3A [0031] [0028], a processor with modules to determine the location of the event); retrieve, via a second micro service module, the information associated with the one or more network site locations, status, the status comprising at least one of: affected, damaged, currently damaged, and battery running (Colling, Fig 3A [0031] [0028], a processor with modules to determine the nature of the event [0032] the nature being “not starting”, “high wet”, “power failure” all being “AFFECTED”)
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing data of the claimed invention to provide “identification of site locations and status” as taught by Colling in the system of Olejar, so that it would provide for an event notification system that automatically verifies a response to an event (Colling [0009]).
As to claim 2, Olejar teaches wherein the one or more event-related alerts are comprised of at least one of: wildfire and natural disaster information (Olejar, [0069], fire emergencies).
As to claim 3, Olejar teaches wherein the apparatus is configured to: send the one or more event-related alerts to a first service module (Olejar, [0052], the emergency alert is sent to a clearinghouse module).
As to claim 4, Olejar teaches wherein the apparatus is configured to: validate, via the first service module, the retrieved one or more event-related alerts based on one or more conditions (Olejar, [0052], the clearinghouse validates the emergency data based on response of a soft or hard emergency button).
As to claim 5, Olejar teaches wherein the apparatus is configured to: retrieve, via the first service module, one or more network site information in connection with the one or more event-related events from a second service module (Olejar, [0052], retrieve by the clearinghouse and cloud server from a second emergency data source emergency data related to the emergency alert).
As to claim 6, Olejar teaches wherein the second service module comprises at least one of: network user management (Olejar, [0052], the second emergency data source comprises management information of an owner or user of the first data source)
As to claim 7, Olejar teaches wherein the management module further comprises at least one of: an alerts list (Olejar, [0059], the subscription system with application contains of list of incidents).
As to claim 8, Olejar teaches wherein the apparatus is configured to: display, via the GUI portal, the one or more event-related alerts on a geographical map (Olejar, [0059], Fig 2, display on a GUI the event alerts on a map).
As to claim 9, Olejar teaches wherein the apparatus is configured to: identify one or more network site locations affected by the one or more event-related alerts (Olejar, [0059], Fig 2, identify one or more location markers associated with the event alerts).
As to claim 10, Olejar teaches wherein the apparatus is configured to: display, via the GUI portal, the identified network site locations based on a second request from the user (Olejar, [0059], Fig 2, identify one or more location markers associated with the event alerts. The second request being a user selecting a search button).
As to claim 11, Olejar teaches a method (Olejar, [0038], a method) comprising:
retrieving, based on a defined schedule (Olejar, [0052], the retrieval schedule can be automatically based on defined sensors or manually), one or more event-related alerts via a method of procedure (MOP) (Olejar, [0061], retrieving an emergency alert via a series of steps 3A (method of procedure)); and
sending, based on a first request from a user (Olejar, [0061], retrieving an emergency alert via a series of steps 3A (method of procedure)), information associated with the alert to a management module having a graphical user interface (GUI) portal (Olejar, [0062], send the retrieved emergency alerts to a emergency data subscription system and cloud server 310 which has a GUI on a emergency response application 360B);
Olejar does not explicitly teach identify one or more network site location affected by the one or more event-related alerts; send information associated with the one or more site locations to management; identifying the one or more network site locations, further comprises: retrieve, via a first micro service module, the one or more network site locations; retrieve, via a second micro service module, the information associated with the one or more network site locations, status, the status comprising at least one of: affected, damaged, currently damaged, and battery running
However, Colling teaches identify one or more network site location affected by the one or more event-related alerts (Colling, Fig 3A [0031], determine the location of the event upon an alarm); send information associated with the one or more site locations to management (Colling, Fig 3A [0031], transmit the information identifying the event location); identifying the one or more network site locations, further comprises: retrieve, via a first micro service module, the one or more network site locations (Colling, Fig 3A [0031] [0028], a processor with modules to determine the location of the event); retrieve, via a second micro service module, the information associated with the one or more network site locations, status, the status comprising at least one of: affected, damaged, currently damaged, and battery running (Colling, Fig 3A [0031] [0028], a processor with modules to determine the nature of the event [0032] the nature being “not starting”, “high wet”, “power failure” all being “AFFECTED”)
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing data of the claimed invention to provide “identification of site locations and status” as taught by Colling in the system of Olejar, so that it would provide for an event notification system that automatically verifies a response to an event (Colling [0009]).
As to claim 12, Olejar teaches wherein the one or more event-related alerts are comprised of at least one of: wildfire and natural disaster information (Olejar, [0069], fire emergencies).
As to claim 13, Olejar teaches further comprising: sending the one or more event-related alerts to a first service module (Olejar, [0052], the emergency alert is sent to a clearinghouse module).
As to claim 14, Olejar teaches further comprising: validating, via the first service module, the retrieved one or more event-related alerts based on one or more conditions (Olejar, [0052], the clearinghouse validates the emergency data based on response of a soft or hard emergency button).
As to claim 15, Olejar teaches further comprising: retrieving, via the first service module, one or more network site information in connection with the one or more event-related events from a second service module (Olejar, [0052], retrieve by the clearinghouse and cloud server from a second emergency data source emergency data related to the emergency alert).
As to claim 16, Olejar teaches wherein the second service module comprises at least one of: network user management (Olejar, [0052], the second emergency data source comprises management information of an owner or user of the first data source)
As to claim 17, Olejar teaches wherein the management module further comprises at least one of: an alerts list (Olejar, [0059], the subscription system with application contains of list of incidents).
As to claim 18, Olejar teaches further comprising: displaying, via the GUI portal, the one or more event-related alerts on a geographical map (Olejar, [0059], Fig 2, display on a GUI the event alerts on a map).
As to claim 19, Olejar teaches further comprising: identifying one or more network site locations affected by the one or more event-related alerts (Olejar, [0059], Fig 2, identify one or more location markers associated with the event alerts).
As to claim 20, Olejar teaches a non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus (Olejar, Fig 4 a coordination system) to perform a method comprising:
retrieving, based on a defined schedule (Olejar, [0052], the retrieval schedule can be automatically based on defined sensors or manually), one or more event-related alerts via a method of procedure (MOP) (Olejar, [0061], retrieving an emergency alert via a series of steps 3A (method of procedure)); and
sending, based on a first request from a user (Olejar, [0053], the recipient makes a subscription request), information associated with the alert to a management module having a graphical user interface (GUI) portal (Olejar, [0062], send the retrieved emergency alerts to a emergency data subscription system and cloud server 310 which has a GUI on a emergency response application 360B);
Olejar does not explicitly teach identify one or more network site location affected by the one or more event-related alerts; send information associated with the one or more site locations to management; identifying the one or more network site locations, further comprises: retrieve, via a first micro service module, the one or more network site locations; retrieve, via a second micro service module, the information associated with the one or more network site locations, status, the status comprising at least one of: affected, damaged, currently damaged, and battery running
However, Colling teaches identify one or more network site location affected by the one or more event-related alerts (Colling, Fig 3A [0031], determine the location of the event upon an alarm); send information associated with the one or more site locations to management (Colling, Fig 3A [0031], transmit the information identifying the event location); identifying the one or more network site locations, further comprises: retrieve, via a first micro service module, the one or more network site locations (Colling, Fig 3A [0031] [0028], a processor with modules to determine the location of the event); retrieve, via a second micro service module, the information associated with the one or more network site locations, status, the status comprising at least one of: affected, damaged, currently damaged, and battery running (Colling, Fig 3A [0031] [0028], a processor with modules to determine the nature of the event [0032] the nature being “not starting”, “high wet”, “power failure” all being “AFFECTED”)
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing data of the claimed invention to provide “identification of site locations and status” as taught by Colling in the system of Olejar, so that it would provide for an event notification system that automatically verifies a response to an event (Colling [0009]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sha et al (Pub No: 2020/0242709) [0028].
Wu (Pub No: 2010/0273444) [0033]-[0053].
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 AFSHAWN M TOWFIGHI whose telephone number is (571)270-7296. The examiner can normally be reached M-F 8:00 AM -5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ian N Moore can be reached at 571-272-3085. 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.
/AFSHAWN M TOWFIGHI/Primary Examiner, Art Unit 2469
Prosecution Insights