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 .
DETAILED ACTION
Claim Construction
Claims 1, 11, and 31 recite contingent limitations, “in response to an incoming call rejection instruction that is entered by a user for the incoming call, the first terminal sends, to the network, a message used to reject the incoming call, and sends indication information to the second terminal, wherein the indication information is used to indicate the second terminal to send, to the network, a message used to reject the incoming call; and the second terminal receives the indication information, and sends, to the network based on the indication information, the message used to reject the incoming call.”
Claims 3, 13, and 33 recite contingent limitations, “wherein in response to the incoming call rejection instruction, the first terminal stops providing the incoming call reminder; and in response to the indication information, the second terminal stops providing the incoming call reminder.”
Regarding method claims 11 and 13, unless the recited condition (“in response” limitation) for performing a contingent step is satisfied, the contingent step does not need to be carried out. Therefore, prior art does not need to teach or suggest the contingent limitations to meet claim 11, 13, 21, and 23. See details in MPEP 2111.04, Section II including Schulhauser. For a compact prosecution, the citations/teachings of the prior art are still provided for the contingent limitations in claim 11 and 13, although the contingent limitations are required to be met.
In contrast, since claims 1, 3, 31, and 33 are machine claims, to render the claimed machine obvious, prior art must teach/suggest the structure(s) that perform the function(s) of the contingent steps. The interpretation of contingent limitations for machine claims 1, 3, 31, and 33 differs from that of method claims 11 and 13, because the claimed structures must be present in the machine/system regardless of whether the conditions are met, and the functions are actually performed. See MPEP 2111.04, Section II.
The contingent limitations in method claims do not have patentable weight. Applicant is recommended to amend the limitations to be positively recited. Claims 11 and21 are recommended to be amended into “receiving an incoming call rejection instruction that is entered by a user for the incoming call; in response to the incoming call rejection instruction, sending, to the network, a message used to reject the incoming call, and sending indication information to a second terminal.”
Claim Objections
Claims 1, 11, 21, and 31 are objected to because of the following informalities:
The claims are objected to because they include reference characters which are not enclosed within parentheses. Reference characters corresponding to elements recited in the detailed description of the drawings and used in conjunction with the recitation of the same element or group of elements in the claims should be enclosed within parentheses so as to avoid confusion with other numbers or characters which may appear in the claims. See MPEP § 608.01(m).
The phrase "a first subscriber identity module SIM" in claims 1 and 11 should be " a first subscriber identity module (SIM)." Appropriate correction is required.
The phrase "a second subscriber identity module SIM" in claims 21 and 31 should be " a second subscriber identity module (SIM)." Appropriate correction is required.
Claim 10 is objected to because of the following informalities:
The phrase "and that the second terminal sends, to the network based on the indication information, the message used to reject the incoming call” should be "and the second terminal sends, to the network based on the indication information, the message used to reject the incoming call.” Appropriate correction is required.
Claim 29 is objected to because of the following informalities:
The phrase "wherein before the sending, to the network based on the indication information, the message used to reject the incoming call” should be “wherein before the sending, to the network based on the indication information, of the message used to reject the incoming call.” Appropriate correction is required.
Claims 27 and 30 are objected to under 37 CFR 1.75(c) as being in improper form because a multiple dependent claims should refer to other claims in the alternative only--, and/or, --cannot depend from any other multiple dependent claim. See MPEP § 608.01(n). Accordingly, the claims 27 and 30 are required to be further treated on the merits. However, claim 27 is interpreted to be dependent from claim 25. Claim 30 is interpreted to be dependent from clam 11. Claims 27 and 30 are tried on the merits based on such interpretation. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 5 and 15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 5 and 15 recite “wherein when the first terminal receives first information from the second terminal, the first terminal and the second terminal have a same cell identity … wherein the first information comprises an identity of a cell to which the second terminal belongs.” It is unclear whether they refer to the same cell identity, since they are both associated with the same first information. For examining purposes, they are interpreted to be the same, namely “wherein when the first terminal receives first information from the second terminal, the first terminal and the second terminal have a same cell identity … wherein the first information comprises the cell identity to which the second terminal belongs.”
Claims 7 and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 7 and 17 recite “receives the first information” without antecedent basis. For examining purposes, it is interpreted to be “receives first information.”
Claims 11-30 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 11 is directed to a method performed by a first terminal. Claim 11 further recites “wherein the second terminal has a second SIM number, the second SIM number is the same as the first SIM number, the second terminal … simultaneously receive, from the network, the incoming call that is for … the second SIM number.” It is unclear how the structure(s)/function(s) of the second terminal limit/affect the method steps of the first terminal.
Similarly, claim 21 is directed to a method performed by a second terminal. Claim 21 recites “wherein the first terminal has a first SIM number, the first SIM number is the same as the second SIM number, the first terminal … simultaneously receive, from the network, the incoming call that is for the first SIM number and the second SIM number.” It is unclear how the structure(s)/function(s) of the first terminal limit/affect the method steps of the second terminal.
Dependent claims 12-20 and 22-30 fail to cure the deficiencies and thus are rejected for the same reason.
Further, without the other terminal and without the relationship with the other terminal (having the same SIM number and simultaneous receiving the incoming call), a single terminal cannot perform the claimed invention that necessarily requires both terminals and their relationship. Therefore, it is unclear how a single terminal directed to one of the terminals can perform the claimed invention. Applicant is recommended to cancel claims 11-30.
Claims 31-38 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 31 recites “the indication information comprises one or more of the third SIM number, the first SIM number, location information of the first terminal, and the like.”
The limitation, “the like,” is exemplary language, renders unclarity regarding what is considered as “the like.”
Further, it is unclear whether the list above is alternatives. Because “one or more of the third SIM number, the first SIM number, and location information of the first terminal” means one of “the third SIM number,” one of “the first SIM number,” and one of “location information of the first terminal.” However, in light of the specification, it appears to mean alternatives. For examining purposes, the limitation is interpreted to be alternatives, “the indication information comprises one or more of the third SIM number, the first SIM number, or location information of the first termina.”
Dependent claims 32-38 fail to cure the deficiencies and thus are rejected for the same reason.
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 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, 7, 9, 11-14, 16, 17, 19, 21-23, 29, and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma (US 2017/0094564 A1), in view of Deng (US 2021/0400091 A1), hereinafter Sharma-Deng.
Per claims 1, 11, 21, and 30, Sharma teaches “A communication system, wherein the communication system comprises a first terminal and a second terminal,(Fig.1; ¶ [0017], The exemplary network arrangement 100 includes UEs 110-114. In this example, it is assumed that the UEs 100-114 are associated with a single user) the first terminal has a first subscriber identity module SIM number, the second terminal has a second SIM number, and the first SIM number is the same as the second SIM number; (¶ [0028-0030], the association of the UEs 110-114 may link a mobile device number (MDN) of the user to each of the UEs 110-114. The MDN may be assigned to the user when one of the UEs 110-114 (e.g., the UE 110) is purchased or obtained and services are provided thereto by a service provider (e.g., via a SIM card) … each of the UEs 110-114 may have the MDN linked such that a communication transmitted to the MDN may reach all the UEs 110-114 … receiving calls on any of the associated UEs 110-114 (since all the UEs 110-114 may provide an alert of the incoming call as they are linked to the same MDN); ¶ [0047], the UE 200 may represent each of the UEs 110-114 and the UEs 110-114 may be associated with one another via a MDN of a user; ¶ [0056], The associated UEs may be linked to a user and a MDN of the user… the message may be transmitted as a SMS message bound for the MDN of the UE. Thus, all of the associated UEs will receive the message as the UEs are linked by the MDN; also see ¶ [0043], ¶ [0051]) the first terminal and the second terminal simultaneously receive, from a network, an incoming call that is for the first SIM number and the second SIM number and that is from a third SIM number; (¶ [0060], all of the associated UEs may be synchronizated with regard to a call that is received … a user may make and receive calls using the other associated UEs 110-114 that were otherwise set up through a MDN registered over a first one of the associated UEs 110-114. Using this association feature, when the UEs 110-114 are acting as the MT UE, a simultaneous alert (e.g., ringing) on all the associated UEs 110-114 … a single call may be alerted at a plurality of UEs through forking; ¶ [0030], receiving calls on any of the associated UEs 110-114 (since all the UEs 110-114 may provide an alert of the incoming call as they are linked to the same MDN); ¶ [0058] a synchronization feature may be performed across the UEs 110-114 from their linkage to one another based upon any type of association criteria such as a user account identification, a mobile device number (MDN)) in response to an incoming call rejection instruction that is entered by a user for the incoming call, the first terminal sends, to the network, a message used to reject the incoming call, (¶ [0064], the user may provide a manual input to reject the call. When the call is rejected, the alert may be terminated and the call may be terminated … a second response may be that the call is rejected; ¶ [0067], the call application 435 may enable the user to provide a manual input such as a reject; ¶ [0070], When a manual response type (e.g., answered or rejected) is determined by the response application 440 for the incoming call, the manual response may be transmitted to the network components; ¶ [0077], The call response 605 may be … the SIP 486 (when the call is rejected)) and […server …] sends indication information to the second terminal, wherein the indication information is used to indicate the second terminal to send, … a message used to reject the incoming call; and the second terminal receives the indication information, and sends, … based on the indication information, the message used to reject the incoming call.” (Fig.6; Fig.7; ¶ [0077-0080], the UE 112 may respond to the incoming call. It may be assumed that the user of the UE 112 performs a manual response … a call response 605 is transmitted to the TAS 170 … The call response 605 may be… the SIP 486 (when the call is rejected) … The TAS 170 may propagate the response type to the UE 114 and the UE 110 … the TAS 170 may transmit the response type via the SIP signal 615 … When the call response 605 is a SIP 486, a corresponding SIP signal may be forwarded to the UE 114 to perform operations based upon the received corresponding SIP 486 signal. Specifically, the UE 114 may perform an alert termination 620 (e.g., cease a ringing functionality) and perform a call history update 625 (e.g., marking the call on the UE 114 as rejected) …the TAS 170 may transmit the matched cause code 630 to the UE 110 …When the call response 605 is a SIP 486, a corresponding cause code 630 of a CC24 may be forwarded to the UE 110 to perform operations based upon the received corresponding CC24. Specifically, the UE 110 may perform an alert termination 635 (e.g., cease a ringing functionality) and perform a call history update 640 (e.g., marking the call on the UE 114 as rejected); ¶ [0061], the signals exchanged to synchronize the response to an incoming call … when a first one of the associated UEs 110-114 … receive the proper SIP signaling response as … as a SIP 486 (i.e., user busy) if the call is rejected. This feature for the other associated UEs may be of significant importance since the other associated UEs will cease performing the alert (e.g., ringing) upon the call being received or rejected on the associated UE; ¶ [0070], When a manual response type (e.g., answered or rejected) is determined by the response application 440 for the incoming call, the manual response may be transmitted to the network components; ¶ [0073], A second cause code may be cause code 24 (CC24). Those skilled in the art will understand that the CC24 may correspond to a “call rejected due to feature at destination.” … When the user rejects the incoming call on one of the associated UEs 110-114 having a PS connectivity (i.e., call rejected), the TAS 170 may receive the response type of a SIP 486 and match to the CC24 … The propagation application 525 may transmit the SIP signal to the non-responding associated UEs having a PS connectivity and transmit the matched cause code to the non-responding associated UEs; ¶ [0086], In 745, the TAS 170 determines whether the response type is indicative that the incoming call was rejected on the UE 112 …The TAS 170 also transmits the CC24 to the UE 110 … the TAS 170 transmits the SIP Cancel or a corresponding SIP signal to the UE 114 … Through receiving the corresponding SIP signal or the cause code, the UEs 110, 114 are capable of performing the appropriate operations based upon the received signal such as terminating an alert and updating a call history accordingly).
Sharma further teaches additional limitations in claim 30, “A terminal, comprising: a memory, configured to store computer program code, wherein the computer program code comprises computer instructions; and a processor, configured to: when the computer instructions are run, enable the terminal to perform the method” (¶ [0031-0032], The UE 200 may include a processor 205, a memory arrangement 210 …The processor 205 may be configured to execute a plurality of applications of the UE 200; ¶ [0088], the exemplary embodiments of the above described method may be embodied as a program containing lines of code stored on a non-transitory computer readable storage medium that, when compiled, may be executed on a processor or microprocessor).
Although Sharma does not explicitly teach the message to reject the incoming call from the second terminal is sent “to the network,” however Sharma teaches ceasing ringing the incoming call and update the call history to mark the call as rejected. Ceasing ring on the second terminal necessarily has to notify the network to reject call, and therefore Sharma implicitly teaches or suggests the rejection message sent “to the network.”
Sharma teaches the first terminal indicating the call rejection to a server and then the server indicating the call rejection to the second terminal. Sharma does not teach the first terminal indicating the call rejection to the second terminal directly by sending an indication directly from the first terminal to the second terminal.
In analogous teaching of call rejection for multiple associated devices, Deng teaches, upon a first terminal manually rejecting an incoming call, the first terminal directly indicates the call rejection to a second terminal (peer) by sending an indication of the call rejection via Bluetooth, which requires determining a distance between the first terminal and the second terminal being less than/meeting a distance threshold/level for Bluetooth communication range. Further, Deng explicitly teaches, upon the second terminal receiving the indication of the call rejection, the second terminal sends a message to the network to reject the call (Fig.1; Fig.5, step 502, step 503; Fig.7, step 703; ¶ [0198-0205], if the user chooses to reject the incoming call on the notebook computer, as shown in FIG. 5, the call answer method may further include the following steps. Step 501: The notebook computer receives an incoming call reject operation of the user. Step 502: In response to the incoming call reject operation of the user, the notebook computer sends a reject command to the mobile phone 1. For example, the incoming call reject operation may be a trigger operation performed by the user on a “decline” button included in the incoming call reminder interface displayed on the display device of the notebook computer, or the incoming call reject operation may be a trigger operation performed by the user on a predetermined physical button on the notebook computer, and the predetermined physical button is used to reject the incoming call. After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link. In some embodiments, in response to the incoming call reject operation of the user, the notebook computer may inform, through the display device, a peer party that the incoming call is rejected and the call ends. Step 503: The mobile phone 1 sends the reject command to the mobile phone 2. For example, the Bluetooth module 240-2 of the mobile phone 1 may transmit the reject command to the mobile communications module 230 of the mobile phone 1 through the processor 210. The mobile communications module 230 of the mobile phone 1 sends the reject command to the mobile phone 2 through the network device. In some embodiments, in response to the received reject command, the mobile phone 1 may display a corresponding interface on the display to inform the peer party that the incoming call is rejected and the call ends; also see ¶ [0223-0231]).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine sending a call rejection indication via Bluetooth directly from a first terminal to second terminal and sending a rejection message from the second terminal to a network as taught by Deng into sending a call rejection indication and rejecting a call by a second terminal as taught by Sharma. One of ordinary skill in the art would have been motivated to do so because this is simple substitution of one known element for another to obtain predictable results, specifically, substitution of how to send a call rejection indication and message of Sharma for that of Deng to obtain predictable results, especially given that Sharma and Deng are in the same field of endeavor of coordinating call rejection among multiple associated devices (KSR(B), MPEP 2143).
Per claims 2, 12, and 22, Sharma further teaches “wherein in response to the incoming call, both the first terminal and the second terminal provide an incoming call reminder” (¶ [0060], all of the associated UEs may be synchronizated with regard to a call that is received … a user may make and receive calls using the other associated UEs 110-114 that were otherwise set up through a MDN registered over a first one of the associated UEs 110-114. Using this association feature, when the UEs 110-114 are acting as the MT UE, a simultaneous alert (e.g., ringing) on all the associated UEs 110-114 … a single call may be alerted at a plurality of UEs through forking; ¶ [0030], receiving calls on any of the associated UEs 110-114 (since all the UEs 110-114 may provide an alert of the incoming call as they are linked to the same MDN)).
Per claims 3, 13, and 23, Sharma further teaches “wherein in response to the incoming call rejection instruction, the first terminal stops providing the incoming call reminder; (¶ [0064], the user may provide a manual input to reject the call. When the call is rejected, the alert may be terminated; ¶ [0077], the UE 112 may respond to the incoming call. It may be assumed that the user of the UE 112 performs a manual response and the call is not missed. Accordingly, a call response 605 is transmitted to the TAS 170 … The call response 605 may be … the SIP 486 (when the call is rejected; ¶ [0070], When a manual response type (e.g., answered or rejected) is determined by the response application 440 for the incoming call, the manual response may be transmitted to the network components) and in response to the indication information, the second terminal stops providing the incoming call reminder” (¶ [0079-0080], When the call response 605 is a SIP 486, a corresponding SIP signal may be forwarded to the UE 114 to perform operations based upon the received corresponding SIP 486 signal. Specifically, the UE 114 may perform an alert termination 620 (e.g., cease a ringing functionality) and perform a call history update 625 (e.g., marking the call on the UE 114 as rejected) …the TAS 170 may transmit the matched cause code 630 to the UE 110 …When the call response 605 is a SIP 486, a corresponding cause code 630 of a CC24 may be forwarded to the UE 110 to perform operations based upon the received corresponding CC24. Specifically, the UE 110 may perform an alert termination 635 (e.g., cease a ringing functionality) and perform a call history update 640 (e.g., marking the call on the UE 114 as rejected)).
Per claims 4 and 14, Deng further teaches “wherein before the first terminal sends the indication information to the second terminal, the first terminal determines that a distance between the first terminal and the second terminal meets a preset level” (Fig.1; Fig.5, Fig7, Step 401: The mobile phone 1 establishes a Bluetooth link to the notebook computer according to a Bluetooth protocol; ¶ [0157], Step 401: The mobile phone 1 establishes a Bluetooth link to a notebook computer according to a Bluetooth protocol; ¶ [0201], After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link; ¶ [0110], The Bluetooth module 240-2 is configured to exchange data between the first electronic device 101 and another short-distance device (for example, the second electronic device 102). [Comment: Per Deng’s teachings, establishing a Bluetooth link in Step 401 and transmitting a call rejection indication via Bluetooth in Step 502 both require determining the distance between the two terminals are within the communication range of Bluetooth, and namely below/meets “a preset level” of distance. Further, the teachings of Deng for independent claims are regarding an indication via Bluetooth from the first terminal to the second terminal and Bluetooth includes determining a distance. Therefore, the combination/motivation is the same as of independent claims.]
Per claims 6 and 16, Deng further teaches “wherein before the first terminal determines that the distance between the first terminal and the second terminal meets the preset level, the first terminal and the second terminal establish a Bluetooth communication link when receiving the incoming call” (Fig.1; Fig.5, Fig7, Step 401: The mobile phone 1 establishes a Bluetooth link to the notebook computer according to a Bluetooth protocol; ¶ [0157], Step 401: The mobile phone 1 establishes a Bluetooth link to a notebook computer according to a Bluetooth protocol; ¶ [0201], After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link; ¶ [0110], The Bluetooth module 240-2 is configured to exchange data between the first electronic device 101 and another short-distance device (for example, the second electronic device 102). [Comment: Deng teaches establishing a Bluetooth communication link in Step 401 (Fig.5) and then transmitting a call rejection indication via Bluetooth in Step 502. Before transmitting the call rejection indication in Step 502 via Bluetooth, which requires determining the distance below/meeting the Bluetooth communication range, the two terminals have established a Bluetooth communication link in Step 401 when receiving an incoming call in Step 402. Further, the combination/motivation is the same as of independent claims.]
Per claims 7 and 17, Deng further teaches “wherein the first terminal receives the first information from the second terminal by using the Bluetooth communication link; or the first terminal sends the indication information to the second terminal by using the Bluetooth communication link” (Fig.1; Fig.5, Fig7; ¶ [0201], After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link; ¶ [0229-0230], Step 703: The mobile phone 1 sends the reject command to the notebook computer through the Bluetooth link. For example, the processor 210 of the mobile phone 1 may further transmit the generated reject command to the Bluetooth module 240-2 of the mobile phone 1. The Bluetooth module 240-2 of the mobile phone 1 sends the reject command to the Bluetooth module 304-2 of the notebook computer through the Bluetooth link. The Bluetooth module 304-2 of the notebook computer transmits the reject command to the processor 301 of the notebook computer). [Comment: The combination/motivation is the same as of independent claims.]
Per claims 9 and 19, Sharma further teaches “wherein before the first terminal sends the indication information …, the first terminal determines that the second terminal is a terminal that has a SIM number the same as the first SIM number” (Fig.6; ¶ [0028-0030], the association of the UEs 110-114 may link a mobile device number (MDN) of the user to each of the UEs 110-114. The MDN may be assigned to the user when one of the UEs 110-114 (e.g., the UE 110) is purchased or obtained and services are provided thereto by a service provider (e.g., via a SIM card) … each of the UEs 110-114 may have the MDN linked such that a communication transmitted to the MDN may reach all the UEs 110-114 … receiving calls on any of the associated UEs 110-114 (since all the UEs 110-114 may provide an alert of the incoming call as they are linked to the same MDN); ¶ [0047], the UE 200 may represent each of the UEs 110-114 and the UEs 110-114 may be associated with one another via a MDN of a user; ¶ [0056], The associated UEs may be linked to a user and a MDN of the user… the message may be transmitted as a SMS message bound for the MDN of the UE. Thus, all of the associated UEs will receive the message as the UEs are linked by the MDN; also see ¶ [0043], ¶ [0051]).
Deng further teaches “wherein before the first terminal sends the indication information to the second terminal” (Fig.5, step 502; Fig.7, step 703; ¶ [0200-0202], Step 502: In response to the incoming call reject operation of the user, the notebook computer sends a reject command to the mobile phone 1…). [Comment: The combination/motivation is the same as of independent claims.]
Per claims 29, Sharma further teaches “wherein before the sending … based on the indication information, the message used to reject the incoming call, the method further comprises: determining that the second terminal is a terminal that has a SIM number the same as the first SIM number (Fig.6; ¶ [0028-0030], the association of the UEs 110-114 may link a mobile device number (MDN) of the user to each of the UEs 110-114. The MDN may be assigned to the user when one of the UEs 110-114 (e.g., the UE 110) is purchased or obtained and services are provided thereto by a service provider (e.g., via a SIM card) … each of the UEs 110-114 may have the MDN linked such that a communication transmitted to the MDN may reach all the UEs 110-114 … receiving calls on any of the associated UEs 110-114 (since all the UEs 110-114 may provide an alert of the incoming call as they are linked to the same MDN); ¶ [0047], the UE 200 may represent each of the UEs 110-114 and the UEs 110-114 may be associated with one another via a MDN of a user; ¶ [0056], The associated UEs may be linked to a user and a MDN of the user… the message may be transmitted as a SMS message bound for the MDN of the UE. Thus, all of the associated UEs will receive the message as the UEs are linked by the MDN; also see ¶ [0043], ¶ [0051]) or determining that an incoming call number in the incoming call is the same as an incoming call number carried in the indication information”
Deng further teaches “wherein before the sending, to the network based on the indication information, the message used to reject the incoming call” (Fig.1; Fig.5, step 503; Fig.7, step 702; ¶ [0198-0205], Step 502: In response to the incoming call reject operation of the user, the notebook computer sends a reject command to the mobile phone 1 … Step 503: The mobile phone 1 sends the reject command to the mobile phone 2 … The mobile communications module 230 of the mobile phone 1 sends the reject command to the mobile phone 2 through the network device.) [Comment: The combination/motivation is the same as of independent claims.]
Claims 5, 15, 24-26, 31-35, and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma (US 2017/0094564 A1), in view of Deng (US 2021/0400091 A1), and further in view of Novak (US 2013/0331135 A1), hereinafter Sharma-Deng-Novak.
Per claims 5, 15, and 24, Deng further teaches “wherein when the first terminal receives first information from the second terminal … the distance between the first terminal and the second terminal is less than a preset threshold, the first terminal determines that the distance between the first terminal and the second terminal meets the preset level” (Fig.1; Fig.5, Fig7, Step 401: The mobile phone 1 establishes a Bluetooth link to the notebook computer according to a Bluetooth protocol; ¶ [0157], Step 401: The mobile phone 1 establishes a Bluetooth link to a notebook computer according to a Bluetooth protocol; ¶ [0201], After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link; ¶ [0110], The Bluetooth module 240-2 is configured to exchange data between the first electronic device 101 and another short-distance device (for example, the second electronic device 102). [Comment: Per Deng’s teachings, establishing a Bluetooth link in Step 401 and transmitting a call rejection indication via Bluetooth in Step 502 both require determining the distance between the two terminals are within the communication range of Bluetooth, and namely below/meets “a preset level” of distance. The combination/motivation is the same as of independent claims.]
However, Sharma-Deng does not teach determining the distance comprising “the first terminal and the second terminal have a same cell identity … wherein the first information comprises an identity of a cell to which the second terminal belongs.”
Novak teaches determining whether a distance between two terminals are within a range of D2D communication comprises a first terminal receiving a cell ID from a second terminal (Fig.7, Step 704: Receiving Client Node Receives New Cell ID (Or Location Data) And Client Node ID Data From Sending Client Node; Fig. 8, Step 804: Receiving Client Node Receives New Cell ID (Or Location Data) And Client Node ID Data From A Sending Client Node; ¶ [0073], FIG. 7 is a generalized flowchart for receiving device-to-device (D2D) cell identifier (ID) and location data as implemented in accordance with an embodiment of the disclosure. In this embodiment, operations for the receipt of D2D Cell ID and location data are begun in step 702, followed by the receipt in step 704 of new cell ID (or associated location data) and client node ID data by a receiving client node from a sending client node; also see ¶ [0078]) and determining the first terminal and the second terminal having the same cell ID (Fig.7, Step 710: Does Cell ID/Location Match Current Location Area Of Receiving Node?; ¶ [0075], A determination is then made in step 710 whether the cell ID or similar location area of the sending client node matches that of the receiving client node … the receiving client node communicates its location information to the sending client node in step 712 to confirm that the two client nodes are in proximity and to likewise enable them to calculate if a D2D communications session is viable by calculating the distance between them. In various embodiments, the receiving client node is within the same cell as the sending client node. In these embodiments, the receiving client node receives the sending client nodes' coordinates, in addition to its cell ID, and it calculates the distance between the client nodes by using its own location information ¶ [0055], the messages are sent more frequently to members of the contact list that are nearby, such as those currently associated within the same cell-ID or a similar location area; ¶ [0070], the client node sends detailed data related to its current location, such as its GPS coordinates, to client nodes that are currently within the same cell or locations within viable communications range …the client node processes cell ID mapping data to determine whether the other client nodes are in similar areas).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine receiving a cell ID and having the same cell ID of Novak into determining a distance for communication of Sharma-Deng. One of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results, specifically, combining known methods of determining distance for peer communication to yield predictable results (KSR(A), MPEP 2143).
Per claim 25, Deng further teaches “when receiving the incoming call, establishing a Bluetooth communication link with the first terminal” (Fig.1; Fig.5, Fig7, Step 401: The mobile phone 1 establishes a Bluetooth link to the notebook computer according to a Bluetooth protocol; ¶ [0157], Step 401: The mobile phone 1 establishes a Bluetooth link to a notebook computer according to a Bluetooth protocol; ¶ [0201], After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link; ¶ [0110], The Bluetooth module 240-2 is configured to exchange data between the first electronic device 101 and another short-distance device (for example, the second electronic device 102). [Comment: Deng teaches has established a Bluetooth communication link in Step 401 (Fig.5) when receiving an incoming call in Step 402. Further, the combination/ motivation is the same as of independent claims.]
Per claim 26, Deng further teaches “sending the first information to the first terminal by using the Bluetooth communication link; or receiving the indication information from the first terminal by using the Bluetooth communication link” (Fig.1; Fig.5, Fig7; ¶ [0201], After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link; ¶ [0229-0230], Step 703: The mobile phone 1 sends the reject command to the notebook computer through the Bluetooth link. For example, the processor 210 of the mobile phone 1 may further transmit the generated reject command to the Bluetooth module 240-2 of the mobile phone 1. The Bluetooth module 240-2 of the mobile phone 1 sends the reject command to the Bluetooth module 304-2 of the notebook computer through the Bluetooth link. The Bluetooth module 304-2 of the notebook computer transmits the reject command to the processor 301 of the notebook computer). [Comment: The combination/motivation is the same as of independent claims.]
Per claim 31, Sharma further teaches “A communication system, wherein the communication system comprises a first terminal and a second terminal, (Fig.1; ¶ [0017], The exemplary network arrangement 100 includes UEs 110-114. In this example, it is assumed that the UEs 100-114 are associated with a single user) the first terminal has a first subscriber identity module SIM number, the second terminal has a second SIM number, and the first SIM number is the same as the second SIM number; (¶ [0028-0030], the association of the UEs 110-114 may link a mobile device number (MDN) of the user to each of the UEs 110-114. The MDN may be assigned to the user when one of the UEs 110-114 (e.g., the UE 110) is purchased or obtained and services are provided thereto by a service provider (e.g., via a SIM card) … each of the UEs 110-114 may have the MDN linked such that a communication transmitted to the MDN may reach all the UEs 110-114 … receiving calls on any of the associated UEs 110-114 (since all the UEs 110-114 may provide an alert of the incoming call as they are linked to the same MDN); ¶ [0047], the UE 200 may represent each of the UEs 110-114 and the UEs 110-114 may be associated with one another via a MDN of a user; ¶ [0056], The associated UEs may be linked to a user and a MDN of the user… the message may be transmitted as a SMS message bound for the MDN of the UE. Thus, all of the associated UEs will receive the message as the UEs are linked by the MDN; also see ¶ [0043], ¶ [0051]) the first terminal and the second terminal simultaneously receive, from a network, an incoming call that is for the first SIM number and the second SIM number and that is from a third SIM number; (¶ [0060], all of the associated UEs may be synchronizated with regard to a call that is received … a user may make and receive calls using the other associated UEs 110-114 that were otherwise set up through a MDN registered over a first one of the associated UEs 110-114. Using this association feature, when the UEs 110-114 are acting as the MT UE, a simultaneous alert (e.g., ringing) on all the associated UEs 110-114 … a single call may be alerted at a plurality of UEs through forking; ¶ [0030], receiving calls on any of the associated UEs 110-114 (since all the UEs 110-114 may provide an alert of the incoming call as they are linked to the same MDN); ¶ [0058] a synchronization feature may be performed across the UEs 110-114 from their linkage to one another based upon any type of association criteria such as a user account identification, a mobile device number (MDN)) in response to an incoming call rejection instruction that is entered by a user for the incoming call, the first terminal sends, to the network, a message used to reject the incoming call; (¶ [0064], the user may provide a manual input to reject the call. When the call is rejected, the alert may be terminated and the call may be terminated … a second response may be that the call is rejected; ¶ [0067], the call application 435 may enable the user to provide a manual input such as a reject; ¶ [0070], When a manual response type (e.g., answered or rejected) is determined by the response application 440 for the incoming call, the manual response may be transmitted to the network components; ¶ [0077], The call response 605 may be … the SIP 486 (when the call is rejected)) … […server …] sends indication information to the second terminal, wherein the indication information is used to indicate the second terminal to send … a message used to reject the incoming call, and the second terminal receives the indication information, and sends … based on the indication information, the message used to reject the incoming call” (Fig.6; Fig.7; ¶ [0077-0080], the UE 112 may respond to the incoming call. It may be assumed that the user of the UE 112 performs a manual response … a call response 605 is transmitted to the TAS 170 … The call response 605 may be… the SIP 486 (when the call is rejected) … The TAS 170 may propagate the response type to the UE 114 and the UE 110 … the TAS 170 may transmit the response type via the SIP signal 615 … When the call response 605 is a SIP 486, a corresponding SIP signal may be forwarded to the UE 114 to perform operations based upon the received corresponding SIP 486 signal. Specifically, the UE 114 may perform an alert termination 620 (e.g., cease a ringing functionality) and perform a call history update 625 (e.g., marking the call on the UE 114 as rejected) …the TAS 170 may transmit the matched cause code 630 to the UE 110 …When the call response 605 is a SIP 486, a corresponding cause code 630 of a CC24 may be forwarded to the UE 110 to perform operations based upon the received corresponding CC24. Specifically, the UE 110 may perform an alert termination 635 (e.g., cease a ringing functionality) and perform a call history update 640 (e.g., marking the call on the UE 114 as rejected); ¶ [0061], the signals exchanged to synchronize the response to an incoming call … when a first one of the associated UEs 110-114 … receive the proper SIP signaling response as … as a SIP 486 (i.e., user busy) if the call is rejected. This feature for the other associated UEs may be of significant importance since the other associated UEs will cease performing the alert (e.g., ringing) upon the call being received or rejected on the associated UE; ¶ [0070], When a manual response type (e.g., answered or rejected) is determined by the response application 440 for the incoming call, the manual response may be transmitted to the network components; ¶ [0073], A second cause code may be cause code 24 (CC24). Those skilled in the art will understand that the CC24 may correspond to a “call rejected due to feature at destination.” … When the user rejects the incoming call on one of the associated UEs 110-114 having a PS connectivity (i.e., call rejected), the TAS 170 may receive the response type of a SIP 486 and match to the CC24 … The propagation application 525 may transmit the SIP signal to the non-responding associated UEs having a PS connectivity and transmit the matched cause code to the non-responding associated UEs; ¶ [0086], In 745, the TAS 170 determines whether the response type is indicative that the incoming call was rejected on the UE 112 …The TAS 170 also transmits the CC24 to the UE 110 … the TAS 170 transmits the SIP Cancel or a corresponding SIP signal to the UE 114 … Through receiving the corresponding SIP signal or the cause code, the UEs 110, 114 are capable of performing the appropriate operations based upon the received signal such as terminating an alert and updating a call history accordingly).
Further, regarding the claim limitation, “the indication information comprises one or more of the third SIM number, the first SIM number, location information of the first terminal, and the like,” since Sharma teaches the first terminal sending the call rejection indication to the second terminal, the indication necessarily includes an identity of the first terminal. Since Sharma also teaches a type of identity of the first terminal is SIM (¶ [0028], the association of the UEs 110-114 may link a mobile device number (MDN) of the user to each of the UEs 110-114. The MDN may be assigned to the user when one of the UEs 110-114 (e.g., the UE 110) is purchased or obtained and services are provided thereto by a service provider (e.g., via a SIM card)). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine of SIM number as a type of identity into a call rejection indication with a first terminal identity as a sender, such that a call rejection indication sent from a first terminal to a second terminal would include a SIM number of the first terminal. One of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results, specifically, combining a known type of identity to another known method of a call rejection indication to yield predictable results (KSR(A), MPEP 2143).
Although Sharma does not explicitly teach the message to reject the incoming call from the second terminal is sent “to the network,” however Sharma teaches ceasing ringing the incoming call and update the call history to mark the call as rejected. Ceasing ring on the second terminal necessarily has to notify the network to reject call, and therefore Sharma implicitly teaches or suggests the rejection message sent “to the network.”
Sharma teaches the first terminal indicating the call rejection to a server and then the server indicating the call rejection to the second terminal. Sharma does not teach the first terminal indicating the call rejection to the second terminal directly by sending an indication directly from the first terminal to the second terminal. Further, Sharma does not teach “if a distance between the first terminal and the second terminal is less than a preset threshold, the first terminal determines that the distance between the first terminal and the second terminal meets a preset level; when the distance between the first terminal and the second terminal meets the preset level.”
In analogous teaching of call rejection for multiple associated devices, Deng teaches, upon a first terminal manually rejecting an incoming call, the first terminal directly indicates the call rejection to a second terminal (peer) by sending an indication of the call rejection via Bluetooth, which requires determining a distance between the first terminal and the second terminal being less than/meeting a distance threshold/level for Bluetooth communication range. Further, Deng explicitly teaches, upon the second terminal receiving the indication of the call rejection, the second terminal sends a message to the network to reject the call (Fig.1; Fig.5; Fig.7; ¶ [0198-0205], if the user chooses to reject the incoming call on the notebook computer, as shown in FIG. 5, the call answer method may further include the following steps. Step 501: The notebook computer receives an incoming call reject operation of the user. Step 502: In response to the incoming call reject operation of the user, the notebook computer sends a reject command to the mobile phone 1. For example, the incoming call reject operation may be a trigger operation performed by the user on a “decline” button included in the incoming call reminder interface displayed on the display device of the notebook computer, or the incoming call reject operation may be a trigger operation performed by the user on a predetermined physical button on the notebook computer, and the predetermined physical button is used to reject the incoming call. After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link. In some embodiments, in response to the incoming call reject operation of the user, the notebook computer may inform, through the display device, a peer party that the incoming call is rejected and the call ends. Step 503: The mobile phone 1 sends the reject command to the mobile phone 2. For example, the Bluetooth module 240-2 of the mobile phone 1 may transmit the reject command to the mobile communications module 230 of the mobile phone 1 through the processor 210. The mobile communications module 230 of the mobile phone 1 sends the reject command to the mobile phone 2 through the network device. In some embodiments, in response to the received reject command, the mobile phone 1 may display a corresponding interface on the display to inform the peer party that the incoming call is rejected and the call ends; also see ¶ [0223-0231]).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine sending a call rejection indication directly from a first terminal to second terminal and sending a rejection message from the second terminal to a network as taught by Deng into sending a call rejection indication and rejecting a call by a second terminal as taught by Sharma. One of ordinary skill in the art would have been motivated to do so because this is simple substitution of one known element for another to obtain predictable results, specifically, substitution of how to send a call rejection indication and message of Sharma for that of Deng to obtain predictable results, especially given that Sharma and Deng are in the same field of endeavor of coordinating call rejection among multiple associated devices (KSR(B), MPEP 2143).
However, Sharma-Deng does not teach determining the distance comprising “the first terminal receives first information from the second terminal, wherein the first information comprises an identity of a cell to which the second terminal belongs; when the first terminal and the second terminal have a same cell identity.”
Novak teaches determining whether a distance between two terminals are within a range of D2D communication comprises a first terminal receiving a cell ID from a second terminal (Fig.7, Step 704: Receiving Client Node Receives New Cell ID (Or Location Data) And Client Node ID Data From Sending Client Node; Fig. 8, Step 804: Receiving Client Node Receives New Cell ID (Or Location Data) And Client Node ID Data From A Sending Client Node; ¶ [0073], FIG. 7 is a generalized flowchart for receiving device-to-device (D2D) cell identifier (ID) and location data as implemented in accordance with an embodiment of the disclosure. In this embodiment, operations for the receipt of D2D Cell ID and location data are begun in step 702, followed by the receipt in step 704 of new cell ID (or associated location data) and client node ID data by a receiving client node from a sending client node; also see ¶ [0078]) and determining the first terminal and the second terminal having the same cell ID (Fig.7, Step 710: Does Cell ID/Location Match Current Location Area Of Receiving Node?; ¶ [0075], A determination is then made in step 710 whether the cell ID or similar location area of the sending client node matches that of the receiving client node … the receiving client node communicates its location information to the sending client node in step 712 to confirm that the two client nodes are in proximity and to likewise enable them to calculate if a D2D communications session is viable by calculating the distance between them. In various embodiments, the receiving client node is within the same cell as the sending client node. In these embodiments, the receiving client node receives the sending client nodes' coordinates, in addition to its cell ID, and it calculates the distance between the client nodes by using its own location information ¶ [0055], the messages are sent more frequently to members of the contact list that are nearby, such as those currently associated within the same cell-ID or a similar location area; ¶ [0070], the client node sends detailed data related to its current location, such as its GPS coordinates, to client nodes that are currently within the same cell or locations within viable communications range …the client node processes cell ID mapping data to determine whether the other client nodes are in similar areas).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine receiving a cell ID and having the same cell ID of Novak into determining a distance for communication of Sharma-Deng. One of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results, specifically, combining known methods of determining distance for peer communication to yield predictable results (KSR(A), MPEP 2143).
Per claim 32, Sharma further teaches “wherein in response to the incoming call, both the first terminal and the second terminal provide an incoming call reminder” (¶ [0060], all of the associated UEs may be synchronizated with regard to a call that is received … a user may make and receive calls using the other associated UEs 110-114 that were otherwise set up through a MDN registered over a first one of the associated UEs 110-114. Using this association feature, when the UEs 110-114 are acting as the MT UE, a simultaneous alert (e.g., ringing) on all the associated UEs 110-114 … a single call may be alerted at a plurality of UEs through forking; ¶ [0030], receiving calls on any of the associated UEs 110-114 (since all the UEs 110-114 may provide an alert of the incoming call as they are linked to the same MDN)).
Per claim 33, Sharma further teaches “wherein in response to the incoming call rejection instruction, the first terminal stops providing the incoming call reminder; and in response to the indication information, the second terminal stops providing the incoming call reminder” (¶ [0064], the user may provide a manual input to reject the call. When the call is rejected, the alert may be terminated; ¶ [0077], the UE 112 may respond to the incoming call. It may be assumed that the user of the UE 112 performs a manual response and the call is not missed. Accordingly, a call response 605 is transmitted to the TAS 170 … The call response 605 may be … the SIP 486 (when the call is rejected; ¶ [0070], When a manual response type (e.g., answered or rejected) is determined by the response application 440 for the incoming call, the manual response may be transmitted to the network components) and in response to the indication information, the second terminal stops providing the incoming call reminder” (¶ [0079-0080], When the call response 605 is a SIP 486, a corresponding SIP signal may be forwarded to the UE 114 to perform operations based upon the received corresponding SIP 486 signal. Specifically, the UE 114 may perform an alert termination 620 (e.g., cease a ringing functionality) and perform a call history update 625 (e.g., marking the call on the UE 114 as rejected) …the TAS 170 may transmit the matched cause code 630 to the UE 110 …When the call response 605 is a SIP 486, a corresponding cause code 630 of a CC24 may be forwarded to the UE 110 to perform operations based upon the received corresponding CC24. Specifically, the UE 110 may perform an alert termination 635 (e.g., cease a ringing functionality) and perform a call history update 640 (e.g., marking the call on the UE 114 as rejected)).
Per claim 34, Deng further teaches “wherein before the first terminal determines that the distance between the first terminal and the second terminal meets the preset level, the first terminal and the second terminal establish a Bluetooth communication link when receiving the incoming call” (Fig.1; Fig.5, Fig7, Step 401: The mobile phone 1 establishes a Bluetooth link to the notebook computer according to a Bluetooth protocol; ¶ [0157], Step 401: The mobile phone 1 establishes a Bluetooth link to a notebook computer according to a Bluetooth protocol; ¶ [0201], After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link; ¶ [0110], The Bluetooth module 240-2 is configured to exchange data between the first electronic device 101 and another short-distance device (for example, the second electronic device 102). [Comment: Deng teaches establishing a Bluetooth communication link in Step 401 (Fig.5) and then transmitting a call rejection indication via Bluetooth in Step 502. Before transmitting the call rejection indication in Step 502 via Bluetooth, which requires determining the distance below/meeting the Bluetooth communication range, the two terminals have established a Bluetooth communication link in Step 401 when receiving an incoming call in Step 402. Further, the combination/motivation is the same as of independent claims.]
Per claim 35, Deng further teaches “wherein the first terminal receives the first information from the second terminal by using the Bluetooth communication link; or the first terminal sends the indication information to the second terminal by using the Bluetooth communication link” (Fig.1; Fig.5, Fig7; ¶ [0201], After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link; ¶ [0229-0230], Step 703: The mobile phone 1 sends the reject command to the notebook computer through the Bluetooth link. For example, the processor 210 of the mobile phone 1 may further transmit the generated reject command to the Bluetooth module 240-2 of the mobile phone 1. The Bluetooth module 240-2 of the mobile phone 1 sends the reject command to the Bluetooth module 304-2 of the notebook computer through the Bluetooth link. The Bluetooth module 304-2 of the notebook computer transmits the reject command to the processor 301 of the notebook computer). [Comment: The combination/motivation is the same as of independent claims.]
Per claim 37, Sharma further teaches “wherein before the first terminal sends the indication information …, the first terminal determines that the second terminal is a terminal that has a SIM number the same as the first SIM number” (Fig.6; ¶ [0028-0030], the association of the UEs 110-114 may link a mobile device number (MDN) of the user to each of the UEs 110-114. The MDN may be assigned to the user when one of the UEs 110-114 (e.g., the UE 110) is purchased or obtained and services are provided thereto by a service provider (e.g., via a SIM card) … each of the UEs 110-114 may have the MDN linked such that a communication transmitted to the MDN may reach all the UEs 110-114 … receiving calls on any of the associated UEs 110-114 (since all the UEs 110-114 may provide an alert of the incoming call as they are linked to the same MDN); ¶ [0047], the UE 200 may represent each of the UEs 110-114 and the UEs 110-114 may be associated with one another via a MDN of a user; ¶ [0056], The associated UEs may be linked to a user and a MDN of the user… the message may be transmitted as a SMS message bound for the MDN of the UE. Thus, all of the associated UEs will receive the message as the UEs are linked by the MDN; also see ¶ [0043], ¶ [0051]).
Deng further teaches “wherein before the first terminal sends the indication information to the second terminal” (Fig.5, step 502; Fig.7, step 703; ¶ [0200-0202], Step 502: In response to the incoming call reject operation of the user, the notebook computer sends a reject command to the mobile phone 1…). [Comment: The combination/motivation is the same as of independent claims.]
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma-Deng, in view of Liu (US 2018/0049257A1).
Per claims 8 and 18, regarding claim limitations, “wherein after the first terminal and the second terminal reject the incoming call, the first terminal and the second terminal disconnect the Bluetooth communication link,” Deng teaches sending the call rejection indication via Bluetooth from the first terminal to the second terminal (see the rejection for independent claims). Deng further teaches disconnecting a Bluetooth communication link after handing up a call (¶ [0336], the notebook computer may send a hang-up command to the mobile phone 1 through the Bluetooth link …The mobile phone 1 and the mobile phone 2 may be disconnected from each other). Therefore, it would have been obvious to combine disconnecting a Bluetooth communication link into call rejection, such that after the first terminal and the second terminal reject the incoming call, a Bluetooth communication link would be disconnected. One of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results (KSR(A), MPEP 2143).
Liu explicitly teaches disconnecting Bluetooth after data transmission is completed (¶ [0043], After data transmission is completed, the Bluetooth connection is automatically disconnected to save power consumption).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine disconnecting Bluetooth after data transmission being completed of Liu into completing a call rejection by terminals of Sharma-Deng, such that a Bluetooth communication link between a first terminal and a second terminal would be disconnected after the terminals reject the incoming call. One of ordinary skill in the art would have been motivated to do so because Liu recognizes that it would have been advantageous to disconnect Bluetooth after data transmission is completed to save power consumption (¶ [0043], After data transmission is completed, the Bluetooth connection is automatically disconnected to save power consumption) (KSR(G), TSM, MPEP 2143).
Claim 27 and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma-Deng-Novak, in view of Liu (US 2018/0049257A1).
Per claims 27 and 36, regarding claim limitations, “wherein after the second terminal rejects the incoming call, the method further comprises: disconnecting the Bluetooth communication link with the first terminal,” Deng teaches sending the call rejection indication via Bluetooth from the first terminal to the second terminal (see the rejection for independent claims). Deng further teaches disconnecting a Bluetooth communication link after handing up a call (¶ [0336], the notebook computer may send a hang-up command to the mobile phone 1 through the Bluetooth link …The mobile phone 1 and the mobile phone 2 may be disconnected from each other). Therefore, it would have been obvious to combine disconnecting a Bluetooth communication link into call rejection, such that after the first terminal and the second terminal reject the incoming call, a Bluetooth communication link would be disconnected. One of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results (KSR(A), MPEP 2143).
Liu explicitly teaches disconnecting Bluetooth after data transmission is completed (¶ [0043], After data transmission is completed, the Bluetooth connection is automatically disconnected to save power consumption).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine disconnecting Bluetooth after data transmission being completed of Liu into completing a call rejection by terminals of Sharma-Deng-Novak, such that a Bluetooth communication link between a first terminal and a second terminal would be disconnected after the terminals reject the incoming call. One of ordinary skill in the art would have been motivated to do so because Liu recognizes that it would have been advantageous to disconnect Bluetooth after data transmission is completed to save power consumption (¶ [0043], After data transmission is completed, the Bluetooth connection is automatically disconnected to save power consumption) (KSR(G), TSM, MPEP 2143).
Claims 10, 20, and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma-Deng, in view of Akita (US 2016/0337495 A1).
Per claims 10, 20, and 28, Sharma further implicitly teaches/suggests “the second terminal sends, to the network based on the indication information, the message used to reject the incoming call” (Fig.6; Fig.7; ¶ [0077-0080], the UE 112 may respond to the incoming call. It may be assumed that the user of the UE 112 performs a manual response … a call response 605 is transmitted to the TAS 170 … The call response 605 may be… the SIP 486 (when the call is rejected) … The TAS 170 may propagate the response type to the UE 114 and the UE 110 … the TAS 170 may transmit the response type via the SIP signal 615 … When the call response 605 is a SIP 486, a corresponding SIP signal may be forwarded to the UE 114 to perform operations based upon the received corresponding SIP 486 signal. Specifically, the UE 114 may perform an alert termination 620 (e.g., cease a ringing functionality) and perform a call history update 625 (e.g., marking the call on the UE 114 as rejected) …the TAS 170 may transmit the matched cause code 630 to the UE 110 …When the call response 605 is a SIP 486, a corresponding cause code 630 of a CC24 may be forwarded to the UE 110 to perform operations based upon the received corresponding CC24. Specifically, the UE 110 may perform an alert termination 635 (e.g., cease a ringing functionality) and perform a call history update 640 (e.g., marking the call on the UE 114 as rejected); ¶ [0061], the signals exchanged to synchronize the response to an incoming call … when a first one of the associated UEs 110-114 … receive the proper SIP signaling response as … as a SIP 486 (i.e., user busy) if the call is rejected. This feature for the other associated UEs may be of significant importance since the other associated UEs will cease performing the alert (e.g., ringing) upon the call being received or rejected on the associated UE; ¶ [0070], When a manual response type (e.g., answered or rejected) is determined by the response application 440 for the incoming call, the manual response may be transmitted to the network components; ¶ [0073], A second cause code may be cause code 24 (CC24). Those skilled in the art will understand that the CC24 may correspond to a “call rejected due to feature at destination.” … When the user rejects the incoming call on one of the associated UEs 110-114 having a PS connectivity (i.e., call rejected), the TAS 170 may receive the response type of a SIP 486 and match to the CC24 … The propagation application 525 may transmit the SIP signal to the non-responding associated UEs having a PS connectivity and transmit the matched cause code to the non-responding associated UEs; ¶ [0086], In 745, the TAS 170 determines whether the response type is indicative that the incoming call was rejected on the UE 112 …The TAS 170 also transmits the CC24 to the UE 110 … the TAS 170 transmits the SIP Cancel or a corresponding SIP signal to the UE 114 … Through receiving the corresponding SIP signal or the cause code, the UEs 110, 114 are capable of performing the appropriate operations based upon the received signal such as terminating an alert and updating a call history accordingly).
Deng further teaches “the second terminal sends, to the network based on the indication information, the message used to reject the incoming call” (Fig.1; Fig.5; Fig.7; ¶ [0198-0205], if the user chooses to reject the incoming call on the notebook computer, as shown in FIG. 5, the call answer method may further include the following steps. Step 501: The notebook computer receives an incoming call reject operation of the user. Step 502: In response to the incoming call reject operation of the user, the notebook computer sends a reject command to the mobile phone 1. For example, the incoming call reject operation may be a trigger operation performed by the user on a “decline” button included in the incoming call reminder interface displayed on the display device of the notebook computer, or the incoming call reject operation may be a trigger operation performed by the user on a predetermined physical button on the notebook computer, and the predetermined physical button is used to reject the incoming call. After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link. In some embodiments, in response to the incoming call reject operation of the user, the notebook computer may inform, through the display device, a peer party that the incoming call is rejected and the call ends. Step 503: The mobile phone 1 sends the reject command to the mobile phone 2. For example, the Bluetooth module 240-2 of the mobile phone 1 may transmit the reject command to the mobile communications module 230 of the mobile phone 1 through the processor 210. The mobile communications module 230 of the mobile phone 1 sends the reject command to the mobile phone 2 through the network device. In some embodiments, in response to the received reject command, the mobile phone 1 may display a corresponding interface on the display to inform the peer party that the incoming call is rejected and the call ends). [Comment: The combination/motivation is the same as of independent claims.]
Although Sharma and does not explicitly disclose the call rejection indication from the first terminal to the second terminal carries the caller ID (the third SIM number), however for the terminal to indicate the second terminal to reject the call from the caller ID as taught in Sharma, it suggests the indication includes the caller ID ((the third SIM number), namely “wherein the indication information carries the third SIM number;… after determining that the indication information carries the third SIM number, the second terminal sends, to the network, the message used to reject the incoming call.”
Akita explicitly teaches that a second terminal receives an indication from a first terminal that carries a SIM number (caller ID) (Fig.1; Fig. 6 Fig.14; ¶ [0049], Shared list 173 includes a telephone number of a caller who makes an incoming call identified as a nuisance call by list generation device 30. Shared list 173 is generated by list generation device 30, and is provided to mobile phone terminals 10 through list distribution device 20; ¶ [0152], In step S108, transmission unit 213 transmits shared list 173 received at reception unit 211 from communication unit 23 to mobile phone terminals 10. When each mobile phone terminal 10 receives shared list 173 by communication unit 13) and rejects an incoming call after determining that the SIM number in the indication is the same as that of the incoming call (Fig.17; ¶ [0196], when this telephone number is included in shared list 173, mobile phone terminal 10 may reject an incoming call from this telephone number; ¶ [0072], Detection unit 111 detects a telephone number of a caller who makes an incoming call received at mobile phone terminal 10. Identification unit 112 identifies whether the telephone number detected by detecting unit 111 is included in shared list 173…Incoming-call-processing unit 113 performs a predetermined process based on shared list 173 for the incoming call received at mobile phone terminal 10. For example, when the telephone number detected by detecting unit 111 is identified by identification unit 112 as a number to be included in shared list 173, incoming-call-processing unit 113 rejects the incoming call to mobile phone terminal 10 from this telephone number; ¶ [0180], when an incoming call is received from the telephone number of a caller that is included in shared list 173, and the risk level of this telephone number is “6,” mobile phone terminal 10 may reject this incoming call; ¶ [0125], the telephone number “03-3456-****” is rejected since the telephone number of the caller is included in shared list 173).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine indicating a SIM number of a caller to compare for call rejection of Akita into a call rejection indication from a first terminal to a second terminal of Sharma-Deng, such that a call rejection indication from a first terminal to a second terminal would carry a SIM number and an incoming call would be rejected after determining the SIM number in the indication is the same as a SIM number of the incoming call. One of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results, specifically, combining known methods of call rejection indication to yield predictable results (KSR(A), MPEP 2143).
Claim 38 is rejected under 35 U.S.C. 103 as being unpatentable over Sharma-Deng-Novak, in view of Akita (US 2016/0337495 A1).
Per claim 38, Sharma further implicitly teaches/suggests “the second terminal sends, to the network based on the indication information, the message used to reject the incoming call” (Fig.6; Fig.7; ¶ [0077-0080], the UE 112 may respond to the incoming call. It may be assumed that the user of the UE 112 performs a manual response … a call response 605 is transmitted to the TAS 170 … The call response 605 may be… the SIP 486 (when the call is rejected) … The TAS 170 may propagate the response type to the UE 114 and the UE 110 … the TAS 170 may transmit the response type via the SIP signal 615 … When the call response 605 is a SIP 486, a corresponding SIP signal may be forwarded to the UE 114 to perform operations based upon the received corresponding SIP 486 signal. Specifically, the UE 114 may perform an alert termination 620 (e.g., cease a ringing functionality) and perform a call history update 625 (e.g., marking the call on the UE 114 as rejected) …the TAS 170 may transmit the matched cause code 630 to the UE 110 …When the call response 605 is a SIP 486, a corresponding cause code 630 of a CC24 may be forwarded to the UE 110 to perform operations based upon the received corresponding CC24. Specifically, the UE 110 may perform an alert termination 635 (e.g., cease a ringing functionality) and perform a call history update 640 (e.g., marking the call on the UE 114 as rejected); ¶ [0061], the signals exchanged to synchronize the response to an incoming call … when a first one of the associated UEs 110-114 … receive the proper SIP signaling response as … as a SIP 486 (i.e., user busy) if the call is rejected. This feature for the other associated UEs may be of significant importance since the other associated UEs will cease performing the alert (e.g., ringing) upon the call being received or rejected on the associated UE; ¶ [0070], When a manual response type (e.g., answered or rejected) is determined by the response application 440 for the incoming call, the manual response may be transmitted to the network components; ¶ [0073], A second cause code may be cause code 24 (CC24). Those skilled in the art will understand that the CC24 may correspond to a “call rejected due to feature at destination.” … When the user rejects the incoming call on one of the associated UEs 110-114 having a PS connectivity (i.e., call rejected), the TAS 170 may receive the response type of a SIP 486 and match to the CC24 … The propagation application 525 may transmit the SIP signal to the non-responding associated UEs having a PS connectivity and transmit the matched cause code to the non-responding associated UEs; ¶ [0086], In 745, the TAS 170 determines whether the response type is indicative that the incoming call was rejected on the UE 112 …The TAS 170 also transmits the CC24 to the UE 110 … the TAS 170 transmits the SIP Cancel or a corresponding SIP signal to the UE 114 … Through receiving the corresponding SIP signal or the cause code, the UEs 110, 114 are capable of performing the appropriate operations based upon the received signal such as terminating an alert and updating a call history accordingly).
Deng further teaches “the second terminal sends, to the network based on the indication information, the message used to reject the incoming call” (Fig.1; Fig.5; Fig.7; ¶ [0198-0205], if the user chooses to reject the incoming call on the notebook computer, as shown in FIG. 5, the call answer method may further include the following steps. Step 501: The notebook computer receives an incoming call reject operation of the user. Step 502: In response to the incoming call reject operation of the user, the notebook computer sends a reject command to the mobile phone 1. For example, the incoming call reject operation may be a trigger operation performed by the user on a “decline” button included in the incoming call reminder interface displayed on the display device of the notebook computer, or the incoming call reject operation may be a trigger operation performed by the user on a predetermined physical button on the notebook computer, and the predetermined physical button is used to reject the incoming call. After the notebook computer receives the incoming call reject operation of the user, the processor 301 of the notebook computer may generate the reject command and transmit the reject command to the Bluetooth module 304-2 of the notebook computer. The Bluetooth module 304-2 of the notebook computer may send the reject command to the mobile phone 1, for example, the Bluetooth module 240-2 of the mobile phone 1, through the Bluetooth link. In some embodiments, in response to the incoming call reject operation of the user, the notebook computer may inform, through the display device, a peer party that the incoming call is rejected and the call ends. Step 503: The mobile phone 1 sends the reject command to the mobile phone 2. For example, the Bluetooth module 240-2 of the mobile phone 1 may transmit the reject command to the mobile communications module 230 of the mobile phone 1 through the processor 210. The mobile communications module 230 of the mobile phone 1 sends the reject command to the mobile phone 2 through the network device. In some embodiments, in response to the received reject command, the mobile phone 1 may display a corresponding interface on the display to inform the peer party that the incoming call is rejected and the call ends). [Comment: The combination/motivation is the same as of independent claims.]
Although Sharma and does not explicitly disclose the call rejection indication from the first terminal to the second terminal carries the caller ID (the third SIM number), however for the terminal to indicate the second terminal to reject the call from the caller ID as taught in Sharma, it suggests the indication includes the caller ID ((the third SIM number), namely “wherein the indication information carries the third SIM number;… after determining that the indication information carries the third SIM number, the second terminal sends, to the network, the message used to reject the incoming call.”
Akita explicitly teaches that a second terminal receives an indication from a first terminal that carries a SIM number (caller ID) (Fig.1; Fig. 6 Fig.14; ¶ [0049], Shared list 173 includes a telephone number of a caller who makes an incoming call identified as a nuisance call by list generation device 30. Shared list 173 is generated by list generation device 30, and is provided to mobile phone terminals 10 through list distribution device 20; ¶ [0152], In step S108, transmission unit 213 transmits shared list 173 received at reception unit 211 from communication unit 23 to mobile phone terminals 10. When each mobile phone terminal 10 receives shared list 173 by communication unit 13) and rejects an incoming call after determining that the SIM number in the indication is the same as that of the incoming call (Fig.17; ¶ [0196], when this telephone number is included in shared list 173, mobile phone terminal 10 may reject an incoming call from this telephone number; ¶ [0072], Detection unit 111 detects a telephone number of a caller who makes an incoming call received at mobile phone terminal 10. Identification unit 112 identifies whether the telephone number detected by detecting unit 111 is included in shared list 173…Incoming-call-processing unit 113 performs a predetermined process based on shared list 173 for the incoming call received at mobile phone terminal 10. For example, when the telephone number detected by detecting unit 111 is identified by identification unit 112 as a number to be included in shared list 173, incoming-call-processing unit 113 rejects the incoming call to mobile phone terminal 10 from this telephone number; ¶ [0180], when an incoming call is received from the telephone number of a caller that is included in shared list 173, and the risk level of this telephone number is “6,” mobile phone terminal 10 may reject this incoming call; ¶ [0125], the telephone number “03-3456-****” is rejected since the telephone number of the caller is included in shared list 173).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine indicating a SIM number of a caller to compare for call rejection of Akita into a call rejection indication from a first terminal to a second terminal of Sharma-Deng-Novak, such that a call rejection indication from a first terminal to a second terminal would carry a SIM number and an incoming call would be rejected after determining the SIM number in the indication is the same as a SIM number of the incoming call. One of ordinary skill in the art would have been motivated to do so because this is combining prior art elements according to known methods to yield predictable results, specifically, combining known methods of call rejection indication to yield predictable results (KSR(A), MPEP 2143).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Barkan (US 2016/0072955 A1) discloses stopping ringing for a call at secondary destinations after the call is rejected at a primary destination.
South (US 2011/0320597 A1) discloses upon a user declining an incoming call, stopping ringing all telephony devices associated with the user.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANNAH S. WANG whose telephone number is (571)272-9018. The examiner can normally be reached on Monday-Friday 9am-5pm EST.
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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HANNAH S WANG/Supervisory Patent Examiner, Art Unit 2631
Prosecution Insights