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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 2, 11 and 18 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Taking claim 2 as exemplary, it recites “identifying that the number was automatically dialed by the UE, wherein the translating of the number comprises: in response to the identifying that the number was automatically dialed by the UE, translating the number dialed to the SIP message with the subservice field”. However, claim 1 already claims the limitations “initiating, by the UE, an emergency call by dialing a number, the number including a primary emergency number or another number; translating, by the UE, the number dialed to a session initiation protocol (SIP) message with a subservice field”. It is inherent that the UE already identified the number since it already translated it to a SIP message with a subservice field. Therefore, claim 2 does not further limit claim 1. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements. Claims 11 and 18 are rejected for at least the same reasons and dependence on independent claims 10 and 17, respectively.
Claim Rejections - 35 USC § 102
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 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.
Claims 1, 2, 4, 5, 7, 10-11, 13-18, 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Gellens, Randall Coleman (US PGPUB 2016/0029197 A1, hereinafter Gellens).
Consider claims 1, 10, and 17. Gellens discloses a method, system, and apparatuses comprising:
Regarding claim 1, Gellens discloses a system ([0004] one or more improved systems, methods, and/or apparatuses for asserting support for telematics capabilities in vehicle emergency call systems) comprising:
at least one processor ([0475] a processor); and
non-transitory memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations ([0475] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.) comprising:
detecting, by a user equipment (UE), a parameter associated with a characteristic of a user or the UE ([0122] terminal 110 may be configured to initiate an emergency call to the central service 160 (e.g., PSAP). The emergency call may be initiated in response to manual input from a user or in response to one or more detected conditions (e.g., deployed airbags, collision sensors, fire indicators, rollover, or other situation detection, etc.).);
identifying, by the UE, that the parameter is indicative of an emergency detected by the UE ([0122] terminal 110 may be configured to initiate an emergency call to the central service 160 (e.g., PSAP). The emergency call may be initiated in response to manual input from a user or in response to one or more detected conditions (e.g., deployed airbags, collision sensors, fire indicators, rollover, or other situation detection, etc.).);
initiating, by the UE, an emergency call by dialing a number, the number including a primary emergency number or another number ([0122] terminal 110 may be configured to initiate an emergency call to the central service 160 (e.g., PSAP).);
translating, by the UE, the number dialed to a session initiation protocol (SIP) message ([0122] terminal 110 may be configured to initiate an emergency call to the central service 160 (e.g., PSAP)...To initiate the emergency call, the terminal 110 may use a communication session signaling protocol such as Session Initiation Protocol (SIP), Extensible Messaging and Presence Protocol (XMPP), Google Talk, Skype, OSCAR, or Microsoft Messenger Service, or another communication session signaling protocol, to establish a packet-based call (e.g., voice call, packet based data call involving text, IM or video communication, and the like) with the central service 160 or a third-party central service (not shown)) with a subservice field ([0461] An ‘eCall.MSD’ entry may also be added to the Emergency Call Additional Data Blocks registry. Also, the ‘eCall.control’ entry may be added to the Emergency Call Additional Data Blocks registry. Also, emergencyCallData.eCall may be added to the Info Packages Registry under “Session Initiation Protocol (SIP) Parameters.”); and
transmitting, by the UE and to a node of a telecommunications core network, the SIP message with the subservice field ([0132] In certain examples, the terminal 110-a may be configured to initiate an emergency call to the central service 160-a (e.g., PSAP). The emergency call may be initiated in response to manual input from a user or in response to one or more detected condition (e.g., deployed airbags, collision sensors, fire indicators, rollover, or other situation detection, etc.). The emergency call may include a first set of signaling 117 related to a communication session signaling protocol (e.g., SIP) (that may include telematics information, for example) and a second set of signaling 119 related to a communication session (e.g., voice/data).).
Regarding claim 10, Gellens discloses all the limitations of claim 1, as discussed above. Gellens also discloses a network element ([0106] FIG. 1A shows an exemplary wireless network system 100 which may be used to exchange telematics data and related (telematics) metadata between a terminal 110 and a central service (e.g., a Public Safety Answering Point (PSAP) 160) through signaling messages transmitted over a communication session signaling protocol.). Therefore, the rejection of claim 1 applies equally as well to the limitations of claim 10. (Gellens Fig. 1A below):
PNG
media_image1.png
744
1010
media_image1.png
Greyscale
Regarding claim 17, Gellens discloses all the limitations of claim 1, in system form rather than method form. Gellens also discloses a method ([0103] Features generally relating to one or more improved systems, methods, and/or apparatuses.). Therefore, the rejection of claim 1 applies equally as well to the limitations of claim 17.
Regarding claim 2, Gellens discloses all the limitations of claim 1, as discussed above. Gellens also discloses:
identifying that the number was automatically dialed by the UE ([0122] terminal 110 may be configured to initiate an emergency call to the central service 160 (e.g., PSAP).), wherein the translating of the number comprises:
in response to the identifying that the number was automatically dialed by the UE, translating the number dialed to the SIP message with the subservice field ([0122] terminal 110 may be configured to initiate an emergency call to the central service 160 (e.g., PSAP)...To initiate the emergency call, the terminal 110 may use a communication session signaling protocol such as Session Initiation Protocol (SIP), Extensible Messaging and Presence Protocol (XMPP), Google Talk, Skype, OSCAR, or Microsoft Messenger Service, or another communication session signaling protocol, to establish a packet-based call (e.g., voice call, packet based data call involving text, IM or video communication, and the like) with the central service 160 or a third-party central service (not shown)) with a subservice field ([0461] An ‘eCall.MSD’ entry may also be added to the Emergency Call Additional Data Blocks registry. Also, the ‘eCall.control’ entry may be added to the Emergency Call Additional Data Blocks registry. Also, emergencyCallData.eCall may be added to the Info Packages Registry under “Session Initiation Protocol (SIP) Parameters.”).
Regarding claims 11, and 18. Gellens discloses all the limitations of claims 2, 10 and 17, as discussed above. Therefore, the rejection of claims 2, 10 and 17 apply equally as well to the limitations of claims 11, and 18.
Regarding claims 4, 13 and 20. Gellens discloses all the limitations of claim 1, 10 and 17, respectively, as discussed above. Gellens also discloses identifying that the user did not dial the number; and
in response to the detecting that the parameter falls below or exceeds a threshold or the identifying that the user did not dial the number, determining the number as being automatically dialed by the UE. ([0340], In some embodiments, IP-based emergency services mechanisms may be used to support emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and to convey vehicle, sensor, and location data related to the crash or incident. Such calls may be referred to as “Automatic Crash Notification” (ACN), or “Advanced Automatic Crash Notification” (AACN), even in the case of manual trigger. The “Advanced” qualifier may refer to the ability to carry a richer set of data.).
Regarding claims 5 and 14. Gellens discloses all the limitations of claim 1, and 10, respectively, as discussed above. Gellens also discloses wherein the number includes, as the primary emergency number, 911, and wherein initiating the emergency call comprises initiating, by the UE, the emergency call by dialing 911. ([0121] One type may include “normal” emergency calls originated by users dialing well-known emergency numbers such as 911 in North America and 112 in Europe. Another type may include eCalls, which are emergency calls that may have the characteristics described above and may include the transfer of telematics data to a central service as well as supporting voice and/or other media communication between the user of terminal 110 and the central service.).
Regarding claims 6 and 15. Gellens discloses all the limitations of claim 1, and 10, respectively, as discussed above. Gellens also discloses initiating the emergency call comprises initiating, by the UE, the emergency call by dialing the other number, the other number corresponding to a type of the UE. ([0300] The status line 2905-a of the example SIP 200 (OK) signaling message 2900-a may identify the message 2900-a as a SIP response and specify the type of response that is being made (e.g., OK). The header 2910-a of the response message may provide the identity of the terminal and the central service, the call identifier, contact information for the terminal and the central service, the call sequence number, an indication of the type(s) of data in the body, and a length of the response message 2900-a message).
Regarding claims 7, and 16. Gellens discloses all the limitations of claim 1, and 10, respectively, as discussed above. Gellens also discloses the node forwarding the subservice field to a public-safety access point (PSAP), the type of the subservice field identifying, to the PSAP, a type of the UE. ([0122] the telematics data and related telematics metadata may be associated or coordinated with the session and/or the voice channel (e.g., the telematics data and related telematics metadata may be exchanged between the same PSAP that is handling the voice channel)).
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.
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.
Claims 3, 12, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Gellens (US 20160029197 A1) in view of Balabhadruni; Venkata Ramesh et al. (US 20150016420 A1 hereinafter Balabhadruni).
Consider claims 3, 12, 19, Gellens teaches determining that the number is automatically dialed by the UE instead of manually dialed by a user; and
in response to the determining that the number is automatically dialed by the UE, determining to generate and send the subservice field with an SOS INVITE message, as the SIP message ([0154] the SIP protocol is defined by the Internet Engineering Task Force (IETF) in a number of Request For Comments standards such as RFC 3261. These standards define a number of SIP request and response messages, including an INVITE message, an ACK message, a BYE message, a CANCEL message, an OPTIONS message, a REGISTER message, a PRACK message, a SUBSCRIBE message, a NOTIFY message, a PUBLISH message, an INFO message, a REFER message, a MESSAGE message, and an UPDATE message).
Gellens teaches a ‘sos’ subservice field ([0372] Because of the need to identify and specially process Next-Generation ACN calls (as discussed above), new service URN children may be registered within the “sos” subservice), Gellens does not teach an “SOS Invite” as claimed.
Balabhadruni in the same art of endeavor teaches the UE transmit an SOS invite message during emergency situation ([050]: the UE 20 initiates a UE-undetected emergency call (hereafter abbreviated UEUEC) by sending a SIP INVITE 401 to the P-CSCF 23. The P-CSCF recognizes from the called number (or URI) that it is an emergency call and so forwards the INVITE to the E-CSCF 24 in signal 402 including an emergency (sos) indication).
Therefore, it would have been obvious to one with ordinary skill in the art before the filing date of the claimed invention to modify Gellens with Balabhadruni in order to improve the system and indicate during the registration of an existence of emergency which enhance the service provided to the user.
Claims 8, 9 are rejected under 35 U.S.C. 103 as being unpatentable over Gellens.
Consider claim 8, Gellens discloses all the limitations of claim 1, as discussed above. While Gellens does not explicitly disclose wherein a subservice field having a value of autotrigger, Gellens suggests telematic metadata transition between UE (vehicle terminal) and central service (PSAP) ([0154] By repurposing the SIP protocol to carry both session data and telematics data, the telematics data may be efficiently transmitted to a central service without interrupting or degrading the quality of a related call. As shown in FIG. 5A (below), the modified SIP request message format 500 may include a request line 505, a header 510, a set of session information 515 (e.g., session parameters, session data), and a set of telematics data 520.))
Therefore, because Gellens teaches using a modified SIP request message to carry telematics data by including messaging field values identifying telematics information, one of ordinary skill in the art would have recognized that the particular messaging field value (“autotrigger”) is merely a selectable identifier within the known SIP messaging field. Selecting “autotrigger” as the field value would have been a predictable use of a known element according to its established function.
Consider claim 9, Gellens discloses all the limitations of claim 1, as discussed above. While Gellens does not explicitly disclose wherein the value of the subservice field includes autotriggerbysmartphone, autotriggerbywatch, or auttriggerbyvehicle.
Gellens suggests telematic metadata transition between UE (vehicle terminal) and central service (PSAP) ([0154] By repurposing the SIP protocol to carry both session data and telematics data, the telematics data may be efficiently transmitted to a central service without interrupting or degrading the quality of a related call. As shown in FIG. 5A, the modified SIP request message format 500 may include a request line 505, a header 510, a set of session information 515 (e.g., session parameters, session data), and a set of telematics data 520.))
Therefore, because Gellens teaches using a modified SIP request message to carry telematics data by including messaging field values identifying telematics information, one of ordinary skill in the art would have recognized that the particular messaging field value (“autotriggerbysmartphone”, “autotriggerbywatch”, or “auttriggerbyvehicle”) is merely a selectable identifier within the known SIP messaging field. Selecting “autotriggerbysmartphone”, “autotriggerbywatch”, or “auttriggerbyvehicle” as the field value would have been a predictable use of a known element according to its established function. (Gellens FIG 5A below).
PNG
media_image2.png
632
548
media_image2.png
Greyscale
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW J LUBBERS whose telephone number is (571)270-5520. The examiner can normally be reached M-F, 9am to 5pm ET.
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, Kathy Wang-Hurst can be reached at 571 270 5371. 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.
/ANDREW J LUBBERS/Examiner, Art Unit 2644
/Alison Slater/Supervisory Patent Examiner, Art Unit 2647
Prosecution Insights