DETAILED ACTION
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 12/15/2025 has been entered.
Response to Amendment
The Applicants’ amendment, filed 12/15/2025, was received and entered. No claims were cancelled. No new claims were added. Independent claims 1, 14 and 20 were amended with the added features, as stated on page 11/14 in the remarks (filed 12/15/2025) of:
a/. automatically storing caller identification information into local memory accessed by a native caller identification process;
b/. pre-configuring native caller identification behavior prior to call signaling; and
c/. provisioning caller identification information out-of-band from an intermediate service for the purpose of modifying native caller identification resolution.
Based on the above added features, Examiner performed updated searches and found new references, such as Shacham (US 2023/0049920) and Tonogai (US 9,215,683), which teaches the added features and the subsequent Office Action is as followings.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 7, 9-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kats et al. (US. 2021/0344792) in view of Fried (US Pat. #: 12,356,293), Shacham (US 2023/0049920) and Tonogai (US 9,215,683) (wherein Kats et al. and Fried were cited in the previous Office Action).
Regarding claim 1, Kats et al. (hereinafter “Kats”) teaches a method, comprising:
receiving, at an intermediate service device (i.e., a server of an architecture 100), information about a call to be made from an initiating device to a recipient device of a user, the information including a reason for the call (i.e., a caller registers a call (i.e., a subsequent or future call) with the architecture 100, as shown in figure 1, wherein the caller transmitted to the architecture 100 a caller registration comprising identification information, such as caller ID or caller’s telephone number, target recipient’s telephone number along with a call reason or call code including information descriptive of an intended purpose of the call, etc.; para. [0621]-[0622] and [0626]-[0627]);
coordinating, by the intermediate service device, with an application on the recipient device to inform the recipient device of the call, an outbound phone number of the call, a name of an organization of the initiating device, and the reason for the call (i.e., information of the call registration, coordinating between an architecture app and device phone app, are received by a recipient’s device phone application or “app” and updates the target recipient device so that a subsequent call from the caller will be handled with the most up to date details, information, and the like; para. [0623] and [0625]), wherein the application on the recipient device configures a caller identification process on the recipient device to display, in response to receiving a subsequent call (i.e., expected incoming call) from the outbound phone number, the name of the organization and the reason for the call (i.e., the call ID of an incoming call that identified a caller and other information in the SCCMC content are presented or displayed on a lock screen of the device, on an interface of a call app of the device, etc.; para. [0633]);
confirming, by the intermediate service device with the initiating device, that the recipient device has been informed of the call, wherein, in response to the initiating device calling the recipient device using the outbound phone number, the caller identification process on the recipient device displays the name of the organization and the reason for the call (i.e., the architecture 100 confirms with the caller via a recipient status 5114, such as “recipient ready to receive a call” or notifying the associate caller that the target recipient has not opted into this service, or the like; para. [0629]-[0630] and [0636]-[0637]). It should be noticed that Kats failed to clearly teach the feature of the intermediate service device having an attestation that the organization of the initiating device is verified as being the organization they claim to be; automatically storing caller identification information into local memory accessed by a native caller identification process; pre-configuring native caller identification behavior prior to call signaling; and provisioning caller identification information out-of-band from an intermediate service for the purpose of modifying native caller identification resolution, as amended in the claim.
However, Fried teaches a communication system 10, as shown in figure 1, performed as an intermediate service device. The system 10 establishes a communication session between an originator node 12 and a recipient 14 over a communication network 16 (col.4, lines 61-65). Fried further teaches an entity, such as an administrator 50 shown in figure 5, operating the originator node 12 may be operated by a business/enterprise (organization) that is attempting to call a customer that is the recipient node 14 (col.5, lines 25-31). Fried further teaches records 40 of identity of various originator nodes wherein each of the records 40 includes a name, logo (of an organization, etc.), phone number, etc. (col.6, lines 33-38). Fried further teaches the communication session processor 32 to validate the originator node 12 utilizing the record 40 stored in a database 26 (col.6, lines 39-60). The database 26 may be an on-premises server computer system of the organization or institute (col.7, lines 64 through col.8, line 1). If the call is validated and allowed, the call is connected to the recipient node 14 with the attestation and information of the call, reason for call, etc. being displayed, as shown in figures 7A and 7B (col.9, lines 28-54).
Shacham teaches a system and method for communication prior to acceptance of a phone call. Shacham teaches that a bank (i.e., representative’s phone device 100, as shown in figure 1) wants to call one of its clients and informs him regarding a status of a loan request. The bank is concerned that the client will not recognize the phone number and will avoid answering the phone call. The bank’s representative will create a message that is comprised of the bank’s name (or name of the organization), an image of the ban’s logo, and an image that consist a textual message informing regarding the purpose of the phone call (as reason for the call)(para.[0049], [0059]). Shacham further teaches a distance server 130 (read on the intermediate service device), as shown in figure 1, comprising a software module used to generate Rich Contacts by combining the message and the phone number into the Rich Contacts and transmitting it to a recipient phone device 150 (para.[0041], [0050]-[0054] and [0060]). Shacham further teaches the recipient phone device is installed an application, such as a native application, to receive Rich contacts and store the Rich Contact in the regular Contacts Database (i.e., local memory on the device)(para.[0055]). Shacham also teaches that the native application, upon receipt of the Rich Contacts, performs pre-configuring native caller identification behavior prior to call signaling, such as logging, monitoring various characteristics of the Rich Contacts (para.[0056]); monitoring the Rich Contacts and update them when required (para.[0055] and [0082]); identifying the incoming call number and will present the message that is content encoded in the Rich Contact, to the user or recipient (para. [0058]).
Tonogai teaches a mobile device controller 18 which is programed to determine appropriate identity for the mobile device. Tonogai further teaches information of the appropriate identity can be provided by an out-of-band signaling mechanism, such as a data channel (col.7, lines 7-20).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features of the intermediate service device having an attestation that the organization of the initiating device is verified as being the organization they claim to be; automatically storing caller identification information into local memory accessed by a native caller identification process; pre-configuring native caller identification behavior prior to call signaling; and provisioning caller identification information out-of-band from an intermediate service for the purpose of modifying native caller identification resolution, as taught by Fried, Shacham and tonogai, into view of Kats in order to provide a confidence to the called party on the caller ID of the incoming call.
Regarding claim 2, Kats further teaches an urgency of call, such as “your driver is arriving with your pizza now” in para. [0601].
Regarding claim 3, Kats further teaches the limitations of the claim, such as late payment as potentially fraudulent transaction or credit offers as special offers (para. [0605]); offering extended warranties, upgraded, exchanges, or the like as a change in privacy rules; feedback or survey as a customer survey; call return from a worker upon customer request as a request callback; providing help to customer upon customer’s request as a response to an inquiry; para. [0608].
Regarding claim 7, Kats further teaches the feature of validating an incoming call using the caller ID (the telephone number) of the incoming call initiated from the caller as the expected incoming call configured in the registered SCCMC content in para. [0632]-[0633].
Regarding claim 9, Kats further teaches limitations of the claim, such as phone call or voice call and text message in paragraph [0174], [0376], [0604] and [0607].
Regarding claim 10, Kats further teaches a business system performed as an organization. Kats further teaches the SCM platform performed as the intermediate service device and business, context of an upcoming call, etc., of the business system leveraged among the business system and the SCM system (para. [0648] and [0651]). Thus, the intermediate service device (SCM system) is associated with the organization (business system), such as portions of the SCM platform being integrated with or into the business system (para. [0657]).
Regarding claim 11, Kats further teaches a business device, such as a smart phone (performed as the intermediate service device), etc., having a dialer app to perform a third party service separate from the organization or business system to communicate with the SCM platform to determine if SCM content and to activate it before the call is dialed, while the call is in progress and after the call is complete (para. [0667]).
Regarding claim 12, note the business application in figure 58 as the application associated with the organization to communication with the SCM platform for exchange information in paragraph [0669].
Regarding claim 13, Kats further teaches a dialer app of a business device is used to establish a side channel of communication with an SCM platform and integrated the SCM content handling in a business and SCM content app interactions. Thus, the app is associated with the intermediate service device, such as the smartphone discussed above (para. [0668]).
Regarding claim 14, Kats teaches a tangible, non-transitory, computer-readable medium having computer-executable instructions stored thereon that, when executed by a processor on a computer (i.e., computer 2400, as shown in figure 24, comprising processor 2412, memory 2414, etc., para. [0214]-[0217]), cause the computer to perform a process comprising:
receiving, at an intermediate service device (i.e., a server of an architecture 100), information about a call to be made from an initiating device to a recipient device of a user, the information including a reason for the call (i.e., a caller registers a call (i.e., a subsequent or future call) with the architecture 100, as shown in figure 1, wherein the caller transmitted to the architecture 100 a caller registration comprising identification information, such as caller ID or caller’s telephone number, target recipient’s telephone number along with a call reason or call code including information descriptive of an intended purpose of the call, etc.; para. [0621]-[0622] and [0626]-[0627]);
coordinating with an application on the recipient device to inform the recipient device of the call, an outbound phone number of the call, a name of an organization of the initiating device, and the reason for the call (i.e., information of the call registration, coordinating between an architecture app and device phone app, are received by a recipient’s device phone application or “app” and updates the target recipient device so that a subsequent call from the caller will be handled with the most up to date details, information, and the like; para. [0623] and [0625]), wherein the application on the recipient device configures a caller identification process on the recipient device to display, in response to receiving a subsequent call (i.e., expected incoming call) from the outbound phone number, the name of the organization and the reason for the call (i.e., the call ID of an incoming call that identified a caller and other information in the SCCMC content are presented or displayed on a lock screen of the device, on an interface of a call app of the device, etc.; para. [0633]);
confirming, with the initiating device, that the recipient device has been informed of the call, wherein, in response to the initiating device calling the recipient device using the outbound phone number, the caller identification process on the recipient device displays the name of the organization and the reason for the call (i.e., the architecture 100 confirms with the caller via a recipient status 5114, such as “recipient ready to receive a call” or notifying the associate caller that the target recipient has not opted into this service, or the like; para. [0629]-[0630] and [0636]-[0637]).
It should be noticed that Kats failed to clearly teach the feature of the intermediate service device having an attestation that the organization of the initiating device is verified as being the organization they claim to be; automatically storing caller identification information into local memory accessed by a native caller identification process; pre-configuring native caller identification behavior prior to call signaling; and provisioning caller identification information out-of-band from an intermediate service for the purpose of modifying native caller identification resolution, as amended to claim. However, Fried teaches a communication system 10, as shown in figure 1, performed as an intermediate service device. The system 10 establishes a communication session between an originator node 12 and a recipient 14 over a communication network 16 (col.4, lines 61-65). Fried further teaches an entity, such as an administrator 50 shown in figure 5, operating the originator node 12 may be operated by a business/enterprise (organization) that is attempting to call a customer that is the recipient node 14 (col.5, lines 25-31). Fried further teaches records 40 of identity of various originator nodes wherein each of the records 40 includes a name, logo (of an organization, etc.), phone number, etc. (col.6, lines 33-38). Fried further teaches the communication session processor 32 to validate the originator node 12 utilizing the record 40 stored in a database 26 (col.6, lines 39-60). The database 26 may be an on-premises server computer system of the organization or institute (col.7, lines 64 through col.8, line 1). If the call is validated and allowed, the call is connected to the recipient node 14 with the attestation and information of the call, reason for call, etc. being displayed, as shown in figures 7A and 7B (col.9, lines 28-54).
Shacham teaches a system and method for communication prior to acceptance of a phone call. Shacham teaches that a bank (i.e., representative’s phone device 100, as shown in figure 1) wants to call one of its clients and informs him regarding a status of a loan request. The bank is concerned that the client will not recognize the phone number and will avoid answering the phone call. The bank’s representative will create a message that is comprised of the bank’s name (or name of the organization), an image of the ban’s logo, and an image that consist a textual message informing regarding the purpose of the phone call (as reason for the call)(para.[0049], [0059]). Shacham further teaches a distance server 130 (read on the intermediate service device), as shown in figure 1, comprising a software module used to generate Rich Contacts by combining the message and the phone number into the Rich Contacts and transmitting it to a recipient phone device 150 (para.[0041], [0050]-[0054] and [0060]). Shacham further teaches the recipient phone device is installed an application, such as a native application, to receive Rich contacts and store the Rich Contact in the regular Contacts Database (i.e., local memory on the device)(para.[0055]). Shacham also teaches that the native application, upon receipt of the Rich Contacts, performs pre-configuring native caller identification behavior prior to call signaling, such as logging, monitoring various characteristics of the Rich Contacts (para.[0056]); monitoring the Rich Contacts and update them when required (para.[0055] and [0082]); identifying the incoming call number and will present the message that is content encoded in the Rich Contact, to the user or recipient (para. [0058]).
Tonogai teaches a mobile device controller 18 which is programed to determine appropriate identity for the mobile device. Tonogai further teaches information of the appropriate identity can be provided by an out-of-band signaling mechanism, such as a data channel (col.7, lines 7-20).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of the intermediate service device having an attestation that the organization of the initiating device is verified as being the organization they claim to be, as amended to claim, as taught by Fried, into view of Kats, Shacham and tonogai, in order to provide a confidence to the called party on the caller ID of the incoming call.
Regarding claim 15, Kats further teaches an urgency of call, such as “your driver is arriving with your pizza now” in para. [0601].
Regarding claim 16, Kats further teaches the feature of validating an incoming call using the caller ID (the telephone number) of the incoming call initiated from the caller as the expected incoming call configured in the registered SCCMC content in para. [0632]-[0633].
Regarding claim 18, Kats further teaches a business device, such as a smart phone (performed as the intermediate service device), etc., having a dialer app to perform a third party service separate from the organization or business system to communicate with the SCM platform to determine if SCM content and to activate it before the call is dialed, while the call is in progress and after the call is complete (para. [0667]).
Regarding claim 19, note the business application in figure 58 as the application associated with the organization to communication with the SCM platform for exchange information in paragraph [0669].
Regarding claim 20, Kats teaches an apparatus (such as a computer 2400 as shown in figure 24), comprising:
one or more network interfaces (i.e., network interface 2416);
a processor coupled to the one or more network interfaces (i.e., processor 2412) and configured to execute one or more processes; and
a memory configured to store an intermediate service process that is executable by the processor (i.e., memory 2414 and/or data store 2418), the intermediate service process when executed configured to:
receive (i.e., the computer 2400 performed as a server of an architecture 100 to receive information) information about a call to be made from an initiating device to a recipient device of a user, the information including a reason for the call (i.e., a caller registers a call (i.e., a subsequent or future call) with the architecture 100, as shown in figure 1, wherein the caller transmitted to the architecture 100 a caller registration comprising identification information, such as caller ID or caller’s telephone number, target recipient’s telephone number along with a call reason or call code including information descriptive of an intended purpose of the call, etc.; para. [0621]-[0622] and [0626]-[0627]);
coordinate with an application on the recipient device to inform the recipient device of the call, an outbound phone number of the call, a name of an organization of the initiating device, and the reason for the call (i.e., information of the call registration, coordinating between an architecture app and device phone app, are received by a recipient’s device phone application or “app” and updates the target recipient device so that a subsequent call from the caller will be handled with the most up to date details, information, and the like; para. [0623] and [0625]), wherein the application on the recipient device configures a caller identification process on the recipient device to display, in response to receiving a subsequent call (i.e., expected incoming call) from the outbound phone number, the name of the organization and the reason for the call (i.e., the call ID of an incoming call that identified a caller and other information in the SCCMC content are presented or displayed on a lock screen of the device, on an interface of a call app of the device, etc.; para. [0633]);
confirm, with the initiating device, that the recipient device has been informed of the call, wherein, in response to the initiating device calling the recipient device using the outbound phone number, the caller identification process on the recipient device displays the name of the organization and the reason for the call (i.e., the architecture 100 confirms with the caller via a recipient status 5114, such as “recipient ready to receive a call” or notifying the associate caller that the target recipient has not opted into this service, or the like; para. [0629]-[0630] and [0636]-[0637]).
It should be noticed that Kats failed to clearly teach the feature of the intermediate service device having an attestation that the organization of the initiating device is verified as being the organization they claim to be; automatically storing caller identification information into local memory accessed by a native caller identification process; pre-configuring native caller identification behavior prior to call signaling; and provisioning caller identification information out-of-band from an intermediate service for the purpose of modifying native caller identification resolution, as amended to claim. However, Fried teaches a communication system 10, as shown in figure 1, performed as an intermediate service device. The system 10 establishes a communication session between an originator node 12 and a recipient 14 over a communication network 16 (col.4, lines 61-65). Fried further teaches an entity, such as an administrator 50 shown in figure 5, operating the originator node 12 may be operated by a business/enterprise (organization) that is attempting to call a customer that is the recipient node 14 (col.5, lines 25-31). Fried further teaches records 40 of identity of various originator nodes wherein each of the records 40 includes a name, logo (of an organization, etc.), phone number, etc. (col.6, lines 33-38). Fried further teaches the communication session processor 32 to validate the originator node 12 utilizing the record 40 stored in a database 26 (col.6, lines 39-60). The database 26 may be an on-premises server computer system of the organization or institute (col.7, lines 64 through col.8, line 1). If the call is validated and allowed, the call is connected to the recipient node 14 with the attestation and information of the call, reason for call, etc. being displayed, as shown in figures 7A and 7B (col.9, lines 28-54).
Shacham teaches a system and method for communication prior to acceptance of a phone call. Shacham teaches that a bank (i.e., representative’s phone device 100, as shown in figure 1) wants to call one of its clients and informs him regarding a status of a loan request. The bank is concerned that the client will not recognize the phone number and will avoid answering the phone call. The bank’s representative will create a message that is comprised of the bank’s name (or name of the organization), an image of the ban’s logo, and an image that consist a textual message informing regarding the purpose of the phone call (as reason for the call)(para.[0049], [0059]). Shacham further teaches a distance server 130 (read on the intermediate service device), as shown in figure 1, comprising a software module used to generate Rich Contacts by combining the message and the phone number into the Rich Contacts and transmitting it to a recipient phone device 150 (para.[0041], [0050]-[0054] and [0060]). Shacham further teaches the recipient phone device is installed an application, such as a native application, to receive Rich contacts and store the Rich Contact in the regular Contacts Database (i.e., local memory on the device)(para.[0055]). Shacham also teaches that the native application, upon receipt of the Rich Contacts, performs pre-configuring native caller identification behavior prior to call signaling, such as logging, monitoring various characteristics of the Rich Contacts (para.[0056]); monitoring the Rich Contacts and update them when required (para.[0055] and [0082]); identifying the incoming call number and will present the message that is content encoded in the Rich Contact, to the user or recipient (para. [0058]).
Tonogai teaches a mobile device controller 18 which is programed to determine appropriate identity for the mobile device. Tonogai further teaches information of the appropriate identity can be provided by an out-of-band signaling mechanism, such as a data channel (col.7, lines 7-20).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of the intermediate service device having an attestation that the organization of the initiating device is verified as being the organization they claim to be, as amended to claim, as taught by Fried, into view of Kats, Shacham and tonogai, in order to provide a confidence to the called party on the caller ID of the incoming call.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Kats et al. (US 2011/0344792) in view of Fried (US Pat. #: 12,356,293), Shacham (US 2023/0049920) and Tonogai (US 9,215,683) as applied to claim 1 above, and further in view of Fang et al. (US 2021/0218725 also cited in the previous Office Action).
Regarding claim 4, Kats, Fried, Shacham and tonogai, in combination, teaches all subject matters as claimed above, except for the feature of establishing a connection utilizing an encrypted security token. However, Fang et al. (hereinafter “Fang”) teaches such feature in paragraph [0230] for improving security of token transmission.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of establishing a connection utilizing an encrypted security token, as taught by Fang, into view of Kats, Fried, Shacham and tonogai in order to establish a security connection between the intermediate service device and the recipient device.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Kats et al. (US 2011/0344792) in view of Fried (US Pat. #: 12,356,293), Shacham (US 2023/0049920) and Tonogai (US 9,215,683) and Fang et al. (US 2021/0218725) as applied to claims 1 and 4 above, and further in view of Ahuja (US 2017/0178217 also cited in the previous Office Action).
Regarding claim 5, Kats, Fried, Shacham, Tonogai and Fang, in combination, teaches all subject matters as claimed above, except for the feature of sharing the encrypted security token between the recipient device and the intermediate service device. However, Ahuja teaches such feature in paragraphs [0020] and [0035] for retrieval of purchased items and delivery.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of sharing the encrypted security token between the recipient device and the intermediate service device, as taught by Ahuja, into view of Kats, Fried, Shacham, Tonogai and Fang in order to securely transmit the information of the call to recipient device.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Kats et al. (US 2011/0344792) in view of Fried (US Pat. #: 12,356,293), Shacham (US 2023/0049920) and Tonogai (US 9,215,683) as applied to claim 1 above, and further in view of Fang et al. (US 2021/0218725) and Vendrow (US 8,831,191 also cited in the previous Office Action).
Regarding claim 6, Kats, Shacham and Tonogai, in combination, teaches the features of transmitting the reason and other identification information to the recipient device as discussed above. Kats and Fried, in combination, fails to teach the feature of establishing a connection by utilizing a encrypted token and maintained continuously. However, Fang teaches the feature of establishing a connection using the encrypted token in paragraph [0230]. Vendrow teaches that a connection is established and maintained continuously if the user associated with the device 102B (i.e., read on the recipient device) accepts the preview message of an incoming call. Otherwise, the connection is disconnected or sent to voicemail (col.4, lines 33-39).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features of establishing a connection by utilizing a encrypted token and maintained continuously, as taught by Fang and Vendrow into view of Kats, Shacham, Tonogai and Fried in order to securely terminate the incoming call to the recipient device.
Claims 8 and 17 is rejected under 35 U.S.C. 103 as being unpatentable over Kats et al. (US 2011/0344792) in view of Fried (US Pat. #: 12,356,293), Shacham (US 2023/0049920) and Tonogai (US 9,215,683) as applied to claims 1 and 14 above, and further in view of Goyal et al. (US9,338,289 also cited in the previous Office Action).
Regarding claims 8 and 17, Kats, Shacham, Tonogai and Fried, in combination, teaches all subject matters as claimed above, except for the feature of the initiating device selecting the outbound phone number from a plurality of outbound phone numbers based on available of the outbound phone number. However, Goyal et al. (hereinafter “Goyal”) teaches an originating device110, as shown in figure 1A, selects an outbound number from a pool of available numbers for use as a caller ID of an outbound call when initiated (col.22, lines 30-38).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature of the initiating device selecting the outbound phone number from a plurality of outbound phone numbers based on available of the outbound phone number, as taught by Goyal, into view of Kats, Fried, Shacham and Tonogai in order to provide selected outbound phone number as the caller ID of the incoming call to the recipient device.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 18/112970 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because . the claims of the present application are broader in scope than the claims of the patent and/or recited in different words (In re KARLSON (CCPA) 136 USPQ 184 (1963)).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BINH TIEU whose telephone number is (571)272-7510. The examiner can normally be reached on 9-5. The Examiner’s fax number is (571) 273-7510 and E-mail address: BINH.TIEU@USPTO.GOV.
Examiner interviews are available via telephone or video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, FAN S. TSANG can be reached on (571) 272-7547.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (FAIR) 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 FAIR system, see http://pair-direct.uspto.gov. If you have any questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Binh Kien Tieu/Primary Examiner, Art Unit 2694
Date: January 2026