DETAILED ACTION
This is in response to US App. 18/635,897. Claims 1-20 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-3 and 8-16 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable by JP 7267639 (hereafter JP639).
Regarding Claim 1,
A method for monitoring, by a server, remote device status in mission-critical communications, the method comprising:
receiving, from a dispatcher device among a plurality of remote devices, a first monitoring request for monitoring a status of at least one responder device among the plurality of remote devices [JP639: p. 4; when a request for assistance is received (step 201), AED response network server 20 attempts to identify and select one or more registered volunteer responders in the vicinity of the incident (step 204); the AED response network server also attempts to identify and select one or more known connected public AEDs in the vicinity of the incident (step 209); p. 7; a request for assistance may be generated by selecting a suitable GUI button or other suitable GUI structure that causes a help request message to be sent to the AED response network server; the user's request for assistance is sent to the AED response network server 20, as described above with reference to FIG. 2A, and the AED response network server 20 initiates a request for public volunteer responders];
transmitting, to the at least one responder device, a second monitoring request based on one or more policies corresponding to the received first monitoring request [JP639: p. 10; at step 274, a status query or "check-in" message is sent to each of the identified AEDs, or to any desired subset of such AEDs (block 274); this is sometimes referred to as "pinging" or "polling" the AED; each pinged AED responds with a "current status" message providing its current location and operational status (step 278); p. 7; the AED response network server 20 initiates a request for public volunteer responders; p. 5; in parallel with notifying nearby volunteer responders, emergency alert notifications may be sent directly to any connected AED 10 near the incident (step 213)];
receiving, from the at least one responder device, a message including information about device status related to the at least one responder device [JP639; Fig. 2D; p. 11; the AED receiving the status query (block 275) establishes a connection with the AED response network server 20 via a second communication channel different from the first communication channel over which the status query is received; it responds to the query by establishing (block 276); a current status message is then sent over this second communication channel (block 278); p. 11; when the AED response network server receives current status messages from pinged AEDs (block 279), it effectively creates an updated AED map containing the current locations and operating status of AEDs in the vicinity of the incident]; and
transmitting, to the dispatcher device, the received message [JP639; p. 13; returning to Figure 2D, the server sends a neighborhood incident message to each AED (block 282) selected for notification and to each volunteer responder selected for notification; p. 13; there may be a wide range of specific text or graphics associated with the Incident Acceptance button or other GUI widget, but once the incident is accepted (decision block 287), an incident acceptance message is sent to the AED server (blocks 288, 289); if the incident is accepted, the AED response network server communicates with the AED as necessary to direct the volunteer to the incident and respond appropriately (blocks 290, 291)].
Regarding Claim 2,
further comprising: assigning, based on a validation of the received first monitoring request, the one or more policies corresponding to the received first monitoring request [JP639: p. 10; returning to Figure 2D, when the AED response server 20 receives a request for volunteer responders (block 201), the request includes the geographic location of the incident; the AED response server then identifies a set of potentially available AEDs for use in responding to the incident; the set of potentially available AEDs can be determined in various ways using various filtering techniques; p. 10; at step 274, a status query or "check-in" message is sent to each of the identified AEDs, or to any desired subset of such AEDs (block 274)].
Regarding Claim 3,
wherein the device status comprises at least one of a location, vital signs, a roaming, an accelerometer, a connection type, a network signal strength, status of a battery charge of the at least one responder device, an emergency alert status, a presence status, various sensor data, an active call status, and a profile status [JP639: p. 10; at step 274, a status query or "check-in" message is sent to each of the identified AEDs, or to any desired subset of such AEDs (block 274); this is sometimes referred to as "pinging" or "polling" the AED; each pinged AED responds with a "current status" message providing its current location and operational status (step 278)].
Regarding Claim 8,
wherein the message comprises a mission-critical short data service message [JP639: p. 10-11; it should be appreciated that the amount of data transferred in the original request (the "check-in" message) and the response (the current state message) is so small that it can be exchanged very quickly; messages may be sent using any of a variety of communication protocols supported by the AED, including, for example, SMS messages].
Regarding claims 9-13, which recite a method having the same claim limitations as those in claims 1-3 and 8 above, the same rationale of rejection as presented in claims 1-3 and 8 is applicable.
Regarding claims 14-16, which recite a server having the same claim limitations as those in claims 1-3 above, the same rationale of rejection as presented in claims 1-3 is applicable.
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) 4-5, 7, 17-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over JP639 in view of Wesby (EP 2290939).
Regarding Claim 4,
JP639 teaches that when a request for assistance is received (step 201), AED response network server 20 attempts to identify and select one or more registered volunteer responders in the vicinity of the incident (step 204) [JP639: p. 4].
However, JP639 does not teach the limitation, which recites receiving the first monitoring request comprises receiving a request message including a payload content type corresponding to the first monitoring request, and an encryption protocol is applied to the request message.
Wesby teaches:
wherein receiving the first monitoring request comprises receiving a request message including a payload content type corresponding to the first monitoring request, and an encryption protocol is applied to the request message [Wesby: p. 18; a remote asset management system wherein said local and/or remote system server service platform (150) comprising means for configuring and testing each of said set or subsets of programmable wireless modules (10) and their respective associated same or different fixed or mobile assets (120) according to clause 1 or 2; p. 18; … further comprising; means for remotely initiating said respective set or subsets of said programmable wireless modules (10) by sending to said identification module of each of said programmable wireless modules (10) a unique encrypted code (PUK) to allow said local or remote system server service platform (150) to put each of said programmable wireless modules (10) in a programming mode …; p. 18; … means for broadcasting a third list of the data type and capabilities of same or different or one or a plurality of fixed or mobile assets (120) wherein said data types being asset type and/or model number and/or OS type and/or power supply and/or battery supply and/or duty cycle parameters of wake up versus sleep mode duration and/or enabled or disabled asset functionality and/or location data and/or service history and/or location history and/or performance optimisation and/or security lock-down features and of said parameters information wherein said parameters information being about corresponding services, maintenance, operating modes and emergency procedures …].
It would have been obvious for POSITA before the effective filing date of the invention to combine the teachings of JP639 and Wesby in order to report back formatted status information regarding each of said or one or a plurality of fixed or mobile assets (120) to said local and/or remote system server service platform [Wesby: p. 18].
Regarding Claim 5,
wherein: the first monitoring request in the request message corresponds to a request for monitoring a plurality of status parameters associated with the plurality of remote devices [JP639: p. 10; returning to Figure 2D, when the AED response server 20 receives a request for volunteer responders (block 201), the request includes the geographic location of the incident; the AED response server then identifies a set of potentially available AEDs for use in responding to the incident], and
the plurality of status parameters includes one or more of an active call status, a presence status, an emergency alert status condition, status of a charge of a battery, a cell coverage, a signal strength, a current connection status, a current location, a roaming status, a profile status, a status of one or more sensors associated with the plurality of remote devices, and a health status indicated by sensor data corresponding to the plurality of remote devices, and wherein the sensor data corresponds to data collected by wearable devices among the plurality of remote devices [JP639: p. 10; at step 274, a status query or "check-in" message is sent to each of the identified AEDs, or to any desired subset of such AEDs (block 274); this is sometimes referred to as "pinging" or "polling" the AED; each pinged AED responds with a "current status" message providing its current location and operational status (step 278)].
Regarding Claim 7,
JP639 teaches that when a request for assistance is received (step 201), AED response network server 20 attempts to identify and select one or more registered volunteer responders in the vicinity of the incident (step 204) [JP639: p. 4].
However, JP639 does not teach the limitation, which recites the payload content type includes one of a TLV format, a JSON format, or an XML format, and the TLV format includes a plurality of Information Elements (IE) indicating the plurality of status parameters associated with the plurality of remote devices and a type and reference corresponding to each of the plurality of status parameters.
Wesby teaches:
wherein: the payload content type includes one of a TLV format, a JSON format, or an XML format, and the TLV format includes a plurality of Information Elements (IE) indicating the plurality of status parameters associated with the plurality of remote devices and a type and reference corresponding to each of the plurality of status parameters [Wesby: p. 25; … polling said respective set or subsets of fixed or mobile assets (120) by said programmable wireless module (10) to which one or a plurality of said fixed or mobile assets (120) are attached for sending said status data and/or alarm condition history according to a request from said fixed or mobile local or remote system server service platform (150) wherein said status data information are formatted in XML to be directly workable …].
It would have been obvious for POSITA before the effective filing date of the invention to combine the teachings of JP639 and Wesby in order to report back formatted status information regarding each of said or one or a plurality of fixed or mobile assets (120) to said local and/or remote system server service platform [Wesby: p. 18].
Regarding Claims 17-18 and 20, which recite the same claim limitations as those in claims 4-5 and 7 above, the same rationale of rejection as presented in claims 4-5 and 7 is applicable.
Claim(s) 6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over JP639 in view of Wesby (EP 2290939) and further in view of Gellens (CN 106537931).
Regarding Claim 6,
In JP639-Wesby combination, JP639 teaches that when a request for assistance is received (step 201), AED response network server 20 attempts to identify and select one or more registered volunteer responders in the vicinity of the incident (step 204) [JP639: p. 4].
However, JP639-Wesby does not teach that the request message comprises a Session Initiation Protocol (SIP) message indicating the monitoring request.
Gellens teaches:
wherein: the request message comprises a Session Initiation Protocol (SIP) message indicating the monitoring request [Gellens: p. 18; FIG. 5A, FIG. 5B and FIG. 5C show is modified to carry a session data and remote information processing data are Session Initiation Protocol (SIP) request message].
It would have been obvious for POSITA before the effective filing date of the invention to combine the teachings of JP639-Wesby and Gellens in order to report back formatted status information regarding each of said or one or a plurality of fixed or mobile assets (120) to said local and/or remote system server service platform [Wesby: p. 18] and in order to send invitations and collection of data (e.g., telematics data, such as minimum data set) to build up the central service 160 of the emergency call [Gellens: p. 38].
Regarding Claim 19, which recites the same claim limitations as those in claim 6 above, the same rationale of rejection as presented in claim 6 is applicable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Koo (US 2014/0052775) teaches that a telephone uniform resource identifier (Tel-URI) or a session initiation protocol uniform resource identifier (SIP-URI) may be included in session information 600 [Koo: 0072].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A WAQAS whose telephone number is (571)270-5642. The examiner can normally be reached 8:30 - 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, Marcus Smith can be reached at (571) 270-1096. 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.
SAAD A. WAQAS
Primary Examiner
Art Unit 2468
/Saad A. Waqas/Primary Examiner, Art Unit 2468
Prosecution Insights