DETAILED ACTION
This Non-Final Office Action is in response to application number 18/105,058 filed on February 2nd 2023. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statements
The Information Disclosure Statements (IDS), submitted on January 14th 2026, April 24th 2025, November 7th 2024, February 9th 2024, August 17th 2023 and February 2nd 2023 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement has been considered by the examiner.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/18/2026 has been entered.
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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-3, 6-7,9-11,14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Igumnov et al. (US 20170265045 A1) over Olive (US20200007614 A1) further in view of Aladag (TR 201918892 A2 Translation).
Regarding claims 1 and 9, Igumnov et al. disclose a method for rule-based mission critical (MCX) communication by an MCX server, the method comprising: receiving, from an MCX client, an MCX service request which comprises information indicating a location of the MCX client, and rule-set information for the MCX service request including information indicating a location range from the location of the MCX client; (Paragraphs 0044 and 0046-48 disclose “The type of incident may be indicated in the new group call request transmitted by the requesting device…”.. Paragraphs 0064 disclose the location range from the location of the MCX client as the relative distance from the client to a defined location stated as “At step 502 in FIG. 5A, a controller in a RAN receives a request for a new location-based group call relative to a defined location from a requesting device (e.g., one of a first responding SU and a dispatch console). The defined location may be received in a same packet, instruction, header, or embedded control signal as the new group call request, or may be sent in a separate packet, instruction, header, or embedded control signal. The defined location may be a same location as the requesting device (e.g., first responding SU), may be a location manually entered by an operator of the requesting device (e.g., first responding SU or dispatch console), or may be some defined location automatically determined by the controller, perhaps with aid from other components within the RAN or outside of the RAN. The defined location may be comprised of, for example, GPS coordinates or other form of latitude and longitude coordinates. In other embodiments, Cartesian or polar coordinate systems could be used instead or in addition.”); determining at least one MCX participant required for the MCX service request based on the rule-set information for the MCX service request (Paragraphs 0040,0044 and 0048 disclose “The responder types required for a response to the defined location may be determined in a number of ways. For example, the responder types required may determine as a function of one or more of (I) a responder type of a first, location-based group call requesting SU, (ii) a type of incident occurring at the defined location, and (iii) a content of the location-based group call request. Here the at least one MCX participant is interpreted to be at least 2 responder type to encompass the group call scenario; and initiating wireless communication between the determined at least one MCX participant and the MCX client based on the rule-set information for the MCX service request (Paragraphs 0074-0075 disclose the establishment of the connection between the requesting device and subscriber unit).
As at least one MCX participant (one or more) is required for the MCX service request and as a group call is composed of a set of participants (two or more), the service request is a subset of the group call.
Igumnov et al. fail to explicitly disclose a client request for an expert level MCX participant.
However in an analogous art Olive teaches a client request for an expert level MCX participant (US 20200007614 A1 Paragraph 0079-0080 disclose the request for an expert responder through the use of credit levels “In an example, credit levels may be used for identifying responders who have achieved particular levels of achievement in responding to requests. A particular level ranges can be associated with a named achievement level group. For example, the credit level range of 0-99 for a responder in the “Financial Advising” category, and this credit level range can place the responder in a “White” achievement level group….” And “In an example use of credit levels, a requester may indicate in his or her request that the request should only be sent to responders who have achieved a particular credit level or have been placed in a particular achievement level group….”.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Igumnov et al. and to incorporate the teachings of Olive, to request for an expert level MCX participant in the request, in order ensure that the participating responders meet or exceed desired competency levels.
Igumnov et al. and Olive fail to explicitly disclose a client requesting an availability of the MCX participant.
However in an analogous art Aladag teaches a client requesting an availability of the MCX participant (TR 201918892 A2 Paragraph Page 1 Paragraph 2 discloses “The server (4) in the system of the invention is triggered by the requests of the users to create a group call via the application (3), and the user who wants to initiate a group call wants to check the availability of all other parties over the network and create a call that can be met by all parties at the most appropriate time.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Igumnov et al. and Olive to incorporate the teachings of Aladag, to request an availability of the MCX participant, in order ensure that the desired participating responders are available.
Regarding claims 6 and 14, Igumnov et al. disclose a method for rule-based mission critical (MCX) communication by an MCX server, the method comprising: receiving, from an MCX client, an ad hoc group call request which comprises information indicating a location of the MCX client, and rule-set information for the ad hoc group call request including information indicating a location range from the location of the MCX client (Paragraph 0044 discloses “The type of incident may be indicated in the new group call request transmitted by the requesting device…” Paragraphs 0064 disclose the location range from the location of the MCX client as the relative distance from the client to a defined location stated as “At step 502 in FIG. 5A, a controller in a RAN receives a request for a new location-based group call relative to a defined location from a requesting device (e.g., one of a first responding SU and a dispatch console).)”; identifying a mission critical event based on the ad hoc group call request received from the MCX client (Paragraph 0044 discloses “in response to receiving an indication of the incident type, may then determine the required responders for responding to the defined location. For example, given an incident type, the controller 232 may access an incident type to required responder mapping (e.g., maintained within or external to the RAN 226) to determine what required responder types should be grouped into a location-based group as a function of the reported incident type.” Here incident type identifies the severity and the appropriate response); determining, upon identifying the mission critical event, a group of MCX participants required for the ad hoc group call request (Paragraphs 0040,0044 and 0048 disclose “The responder types required for a response to the defined location may be determined in a number of ways. For example, the responder types required may determine as a function of one or more of (I) a responder type of a first, location-based group call requesting SU, (ii) a type of incident occurring at the defined location, and (iii) a content of the location-based group call request. Here the at least one MCX participant is interpreted to be at least 2 responder type to encompass the group call scenario; and initiating an ad hoc group call between the determined group of MCX participants and the MCX client based on the rule-set information for the ad hoc group call request (Paragraphs 0074-0075 disclose the establishment of the connection between the requesting device and subscriber unit).
Igumnov et al. fail to explicitly disclose a client request for an expert level MCX participant.
However in an analogous art Olive teaches a client request for an expert level MCX participant (US 20200007614 A1 Paragraph 0079-0080 disclose the request for an expert responder through the use of credit levels “In an example, credit levels may be used for identifying responders who have achieved particular levels of achievement in responding to requests. A particular level ranges can be associated with a named achievement level group. For example, the credit level range of 0-99 for a responder in the “Financial Advising” category, and this credit level range can place the responder in a “White” achievement level group….” And “In an example use of credit levels, a requester may indicate in his or her request that the request should only be sent to responders who have achieved a particular credit level or have been placed in a particular achievement level group….”.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Igumnov et al. and to incorporate the teachings of Olive, to request for an expert level MCX participant in the request, in order ensure that the participating responders meet or exceed desired competency levels.
Igumnov et al. and Olive fail to explicitly disclose a client requesting an availability of the MCX participant.
However in an analogous art Aladag teaches a client requesting an availability of the MCX participant (TR 201918892 A2 Paragraph Page 1 Paragraph 2 discloses “The server (4) in the system of the invention is triggered by the requests of the users to create a group call via the application (3), and the user who wants to initiate a group call wants to check the availability of all other parties over the network and create a call that can be met by all parties at the most appropriate time.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Igumnov et al. and Olive to incorporate the teachings of Aladag, to request an availability of the MCX participant, in order ensure that the desired participating responders are available.
Regarding claims 2,7,10 and 15, Igumnov et al. disclose the method of claim 1, wherein the rule-set information further comprises at least one of an emergency type, or a minimum number of the MCX participants (Paragraph 0045 and Table II disclose the incident type equivalent to emergency type “For example, when the reported incident type for the new location-based group is residential house fire..” and the defined location based group).
Regarding claims 3 and 11, Igumnov et al. disclose the method of claim 1, wherein the determining the at least one MCX participant required for the MCX service request comprises: receiving, from the MCX client, a fetch participants request which comprises rule-set information for the fetch participants request (Paragraph 0046 discloses the client sending the required responders, “…the content of the location-based group call request (or a subsequent message transmitted thereafter) could also be used to explicitly indicate the required responders for responding to the defined location” whereby the rule set information corresponds to the defined location. Additionally paragraph 0045 also discloses “…when the reported incident type for the new location-based group is residential house fire, the controller 232 may access the incident type to required responder types mapping and determine..,”); verifying the fetch participants request received from the MCX client based on the rule-set information for the fetch participants request; and determining the at least one MCX participant satisfying the rule-set information for the fetch participants request (Paragraph 0048 discloses that “Once the controller 232 determines the plurality of required responder types to respond to the defined location, it then applies a default or initial set of location-based group formation rules relative to the defined location to create an initial group of responding SUs out of the potential responding SUs units meeting one of the plurality of required responder types for responding to the defined location”).
Claims 4-5,8,12-13,16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Igumnov et al. (US 20170265045 A1) in view of Olive (US20200007614 A1) in view of Aladag (TR 201918892 A2 Translation) further in view of Leis et al. (US 12309214 B2).
Regarding claims 4,8,12 and 16, Igumnov et al. disclose the method of claim 1. wherein the initiating the wireless communication between the determined at least one MCX participant and the MCX client comprises: sending a communication request invite to the determined at least one MCX participant (Paragraph 0050 and FIG 2. disclose MCPTT controlling server 203 sending call request signal 223 to MCPTT client2 207) ; receiving an invite accept response from the determined at least one MCX participant (Paragraph 0053 and FIG 2. discloses step 225 the MCPPT client2 207 receiving, accepting call signal 223). ; verifying the received invite accept response based on the received rule-set information for the MCX service request; and sending the verified invite accept response to the MCX client to establish the wireless communication between the determined at least one MCX participant and the MCX client (Paragraph 0054-0055 and FIG 2. Disclose MCPTT client2 207 accepting the call by sending MCPTT call response to server 203 and respective to server 201).
Igumnov et al. fails to explicitly disclose sending a communication request invite to the at least one determined MCX participant; receiving an invite accept response from the at least one determined MCX participant; verifying the received invite accept response based on the received rule-set information for the ad hoc group call request; and sending the verified invite accept response to the MCX client to establish the wireless communication between the determined at least one MCX participant and the MCX client.
However, in an analogous art Leis et al. teaches sending a communication request invite to the at least one determined MCX participant (US 12309214 B2 Paragraph 0050 and FIG 2. disclose MCPTT controlling server 203 sending call request signal 223 to MCPTT client2 207) ; receiving an invite accept response from the at least one determined MCX participant (US 12309214 B2 Paragraph 0053 and FIG 2. discloses step 225 the MCPPT client2 207 receiving, accepting call signal 223). ; verifying the received invite accept response based on the received rule-set information for the ad hoc group call request; and sending the verified invite accept response to the MCX client to establish the wireless communication between the determined at least one MCX participant and the MCX client (US 12309214 B2 Paragraph 0054-0055 and FIG 2. Disclose MCPTT client2 207 accepting the call by sending MCPTT call response to server 203 and respective to server 201).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Igumnov et al. to incorporate the teachings of Leis et al. to establish connectivity between the client and 2 or more participants, in order to establish rule based MCX services between the client and participants.
Regarding claims 5 and 13, Igumnov et al. disclose the method of claim 4.
Igumnov et al. fails to explicitly disclose that the communication request invite is sent to the determined MCX participant based on identifying a mission critical event.
However, in an analogous art Leis et al. teaches wherein the communication request invite is sent to the determined MCX participant based on identifying a mission critical event (Paragraph 0050 and FIG 2. disclose MCPTT controlling server 203 sending call request signal 223 to MCPTT client2 207).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Igumnov et al. to incorporate the teachings of Leis et al. to establish connectivity between the client and 2 or more participants, in order to establish rule based MCX services between the client and participants.
Regarding claim 18, Igumnov et al. disclose the method according to claim 6.
Igumnov et al. fail to explicitly disclose determining, based on the ad hoc group call request, whether a group call feature is supported; and rejecting the ad hoc group call request based on determining the group call feature is not supported.
However in an analogous art olive teaches determining, based on the ad hoc group call request, whether a group call feature is supported; and rejecting the ad hoc group call request based on determining the group call feature is not supported (US 20200007614 A1 Paragraph 0257 discloses “In response to the information sharing manager 2212 determining that the criteria is not met, the request from the requester may be prevented from being communicated to the candidate responder. In addition for example, in response to the information sharing manager 2212 determining that the criteria is not met, the request from the requester may be communicated to another candidate responder. The other candidate responder may not have met initial qualifications for sending the request, but may be an alternate if the requester does not meet the criteria of the first candidate responder.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to have modified Igumnov et al. to incorporate the teachings of olive et al. to reject the ad hoc group call request based on determining the group call feature is not supported, in order to optimize resource utilization.
Response to Arguments
Applicant’s arguments with respect to claim 1 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Samuel Dilan Rutnam whose telephone number is 703-756-1374. The examiner can normally be reached between 8:30am-5:00pm Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sujoy Kundu can be reached on 571-272-8586.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR.
Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Samuel Dilan Rutnam/
Patent Examiner, Art Unit 2471
/MOHAMMAD S ADHAMI/Primary Examiner, Art Unit 2471
Prosecution Insights