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, 10 and 16 were amended, as stated on page 11 of 13 of the Applicants’ remarks, with the added features 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 new added features to independent claims 1, 10 and 16, Examiner performed updated searches and found new references which teaches the added feature 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-4, 6-11 and 13-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 and Fried were cited in the previous Office Action).
Regarding claim 1, Kats et al. (hereinafter “Kats”) teaches a method, comprising:
receiving, at an application on a recipient device (i.e., an architecture app or device phone app on a target recipient device [0625] receives and updated with the registered information, such as SCCMC data structure, provided from a caller after the caller registered at a server of an architecture 100; para. [0622]-[0623]), information about a call to be made from an initiating device, the information having an output phone number of the call, a name of an organization of the initiating device, and a reason for the call (i.e., the SCCMC data structure comprising call or caller identifying content, such as caller ID or telephone number associated with the caller’s device, caller business name and caller call purpose or call code (para. [0620], [0621] and [0637]); and
configuring, by the application, caller identification process on the recipient device to display, in response to receiving a subsequent call from the outbound phone number (i.e., determining an expected incoming call based on caller ID of the incoming call presented in the on-device or SCCMC data structure; para. [0632]), the name of the organization and the reason for the call (i.e., the call ID of an incoming call that identified a caller, the name of the organization, reasons of the call 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., as shown in figure 46; para. [0633]);
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] and in response to the caller calls the target recipient device, the target recipient device detects the caller ID from the incoming call as an expected call and retrieves and presents the portion of the SCCMC data structure which included the name of the organization and the reason of the call, as shown in figure 46; para. [0633], [0636] and [0637]).
It should be noticed that Kats failed to clearly teach the features of 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 the claim. However, Fried teaches a communication system 10, as shown in figure 1, performed as an intermedia service device. The system 10 establishes a communication session between an originator node 12 an recipient 14 over a communication network 16 (col.4, lines61-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 the identity of various originator nodes wherein each of the records 40 includes the name, logo (of an organization, etc.) phone number, etc. (col.6, lines 33-38). Fried further teaches the communications session processor 32 to validate the originator node 12 utilizing the record 40 (col.6, lines 39-60) stored in a database 26. The database 26 may be an on-premises server computer system of the organization or institute (col.7, line 64 col.8, line 1). If the call is validated and is allowed, the call is connected to the recipient node with attestation and information of the call, reason for call, etc. being displayed, as shown in figure 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 of its clients and informs him regarding a status of a loan request. The banks 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 text image informing regarding the purpose of the phone call (as reason for the call)(para.[0049] and [0059]). Shacham further teaches a distance server 130 (read on the intermediate service device) 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 number device is installed an application, such as a native application, to receive Rich Contacts and store the Rich Contacts in the regular contacts Database (i.e., local memory on the recipient telephone device)(para.[0055]). Shacham also teaches that the native application, upon receipt of the Rich Contacts, performs pre-configuring native caller identification process prior to call signaling, such as logging, various characteristics of the Rich Contacts (para.[0056]); monitoring the Rich Contacts and updating them when required (para.[0055] and [0082]); identifying the incoming call number and will present the message that is content encoded in the Rich Contacts, 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 for the mobile device. Tonogai further teaches information of the appropriate identity can be provided by an out-ot-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 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 the claim, as taught by Fried, Shacham and Tonogai into view of Kats in order to provide 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 4, Kats further teaches the limitations of the claim in figures 48 and 57, paragraphs [0372] and [0648].
Regarding claim 6, Kats further teaches the features of identifying a caller if caller ID of an incoming call is present (or matched) in the on-device data structure (read on comparing an incoming call number to a directory) and displaying some portion of the SCCMC data structure in paragraphs [0632]-[0633], [0636] and [0639].
Regarding claims 7-8, Kats further teaches the limitations of the claim, such as when is call is not expected or the caller ID (the telephone number of caller’s device was not found in a directory), a call interceptor of the application (architecture app) on the recipient device to query automatic on-device contacts in order to provide a source of caller ID references for every incoming call (para. [0634]-[0637]).
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 teaches a tangible, non-transitory, computer-readable medium having computer-executable instructions stored thereon that, when executed on a computer of a recipient device of a user, cause an application on the recipient device of the user to perform a process comprising:
receiving information about a call to be made from an initiating device (i.e., an architecture app or device phone app on a target recipient device [0625] receives and updated with the registered information, such as SCCMC data structure, provided from a caller after the caller registered at a server of an architecture 100; para. [0622]-[0623]), the information having an output phone number of the call, a name of an organization of the initiating device, and a reason for the call (i.e., the SCCMC or on-device data structure comprising call or caller identifying content, such as caller ID or telephone number associated with the caller’s device, caller business name and caller call purpose or call code (para. [0620], [0621] and [0637]); and
configuring caller identification process on the recipient device to display, in response to receiving a subsequent call from the outbound phone number (i.e., determining an expected incoming call based on caller ID of the incoming call presented in the on-device or SCCMC data structure; para. [0632]), the name of the organization and the reason for the call (i.e., the call ID of an incoming call that identified a caller, the name of the organization, reasons of the call 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., as shown in figure 46; para. [0633]);
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] and in response to the caller calls the target recipient device, the target recipient device detects the caller ID from the incoming call as an expected call and retrieves and presents the portion of the SCCMC data structure which included the name of the organization and the reason of the call, as shown in figure 46; para. [0633], [0636] and [0637]).
It should be noticed that Kats failed to clearly teach the feature of 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 the claim. However, Fried teaches a communication system 10, as shown in figure 1, performed as an intermedia service device. The system 10 establishes a communication session between an originator node 12 an recipient 14 over a communication network 16 (col.4, lines61-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 the identity of various originator nodes wherein each of the records 40 includes the name, logo (of an organization, etc.) phone number, etc. (col.6, lines 33-38). Fried further teaches the communications session processor 32 to validate the originator node 12 utilizing the record 40 (col.6, lines 39-60) stored in a database 26. The database 26 may be an on-premises server computer system of the organization or institute (col.7, line 64 col.8, line 1). If the call is validated and is allowed, the call is connected to the recipient node with attestation and information of the call, reason for call, etc. being displayed, as shown in figure 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 of its clients and informs him regarding a status of a loan request. The banks 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 text image informing regarding the purpose of the phone call (as reason for the call)(para.[0049] and [0059]). Shacham further teaches a distance server 130 (read on the intermediate service device) 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 number device is installed an application, such as a native application, to receive Rich Contacts and store the Rich Contacts in the regular contacts Database (i.e., local memory on the recipient telephone device)(para.[0055]). Shacham also teaches that the native application, upon receipt of the Rich Contacts, performs pre-configuring native caller identification process prior to call signaling, such as logging, various characteristics of the Rich Contacts (para.[0056]); monitoring the Rich Contacts and updating them when required (para.[0055] and [0082]); identifying the incoming call number and will present the message that is content encoded in the Rich Contacts, 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 for the mobile device. Tonogai further teaches information of the appropriate identity can be provided by an out-ot-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 an attestation that the organization of the initiating device is verified as being the organization they claim to be, as amended to the claim, as taught by Fried, Shacham and Tonogai into view of Kats in order to provide confidence to the called party on the caller ID of the incoming call.
Regarding claim 11, Kats further teaches an urgency of call, such as “your driver is arriving with your pizza now” in para. [0601].
Regarding claim 13, Kats further teaches the features of identifying a caller if caller ID of an incoming call is present (or matched) in the on-device data structure (read on comparing an incoming call number to a directory) and displaying some portion of the SCCMC data structure in paragraphs [0632]-[0633], [0636] and [0639].
Regarding claims 14-15, Kats further teaches the limitations of the claim, such as when is call is not expected or the caller ID (the telephone number of caller’s device was not found in a directory), a call interceptor of the application (architecture app) on the recipient device to query automatic on-device contacts in order to provide a source of caller ID references for every incoming call (para. [0634]-[0637]).
Regarding claim 16, 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 a caller identification process and an application that is executable by the processor (i.e., memory 2414 and/or data store 2418), the application when executed configured to:
receive information about a call to be made from an initiating device (i.e., an architecture app or device phone app on a target recipient device [0625] receives and updated with the registered information, such as SCCMC data structure, provided from a caller after the caller registered at a server of an architecture 100; para. [0622]-[0623]), the information having an output phone number of the call, a name of an organization of the initiating device, and a reason for the call (i.e., the SCCMC or on-device data structure comprising call or caller identifying content, such as caller ID or telephone number associated with the caller’s device, caller business name and caller call purpose or call code (para. [0620], [0621] and [0637]); and
configure caller identification process on the recipient device to display, in response to receiving a subsequent call from the outbound phone number (i.e., determining an expected incoming call based on caller ID of the incoming call presented in the on-device or SCCMC data structure; para. [0632]), the name of the organization and the reason for the call (i.e., the call ID of an incoming call that identified a caller, the name of the organization, reasons of the call 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., as shown in figure 46; para. [0633]);
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] and in response to the caller calls the target recipient device, the target recipient device detects the caller ID from the incoming call as an expected call and retrieves and presents the portion of the SCCMC data structure which included the name of the organization and the reason of the call, as shown in figure 46; para. [0633], [0636] and [0637]).
It should be noticed that Kats failed to clearly teach the feature of 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 the claim. However, Fried teaches a communication system 10, as shown in figure 1, performed as an intermedia service device. The system 10 establishes a communication session between an originator node 12 an recipient 14 over a communication network 16 (col.4, lines61-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 the identity of various originator nodes wherein each of the records 40 includes the name, logo (of an organization, etc.) phone number, etc. (col.6, lines 33-38). Fried further teaches the communications session processor 32 to validate the originator node 12 utilizing the record 40 (col.6, lines 39-60) stored in a database 26. The database 26 may be an on-premises server computer system of the organization or institute (col.7, line 64 col.8, line 1). If the call is validated and is allowed, the call is connected to the recipient node with attestation and information of the call, reason for call, etc. being displayed, as shown in figure 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 of its clients and informs him regarding a status of a loan request. The banks 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 text image informing regarding the purpose of the phone call (as reason for the call)(para.[0049] and [0059]). Shacham further teaches a distance server 130 (read on the intermediate service device) 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 number device is installed an application, such as a native application, to receive Rich Contacts and store the Rich Contacts in the regular contacts Database (i.e., local memory on the recipient telephone device)(para.[0055]). Shacham also teaches that the native application, upon receipt of the Rich Contacts, performs pre-configuring native caller identification process prior to call signaling, such as logging, various characteristics of the Rich Contacts (para.[0056]); monitoring the Rich Contacts and updating them when required (para.[0055] and [0082]); identifying the incoming call number and will present the message that is content encoded in the Rich Contacts, 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 for the mobile device. Tonogai further teaches information of the appropriate identity can be provided by an out-ot-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 an attestation that the organization of the initiating device is verified as being the organization they claim to be, as amended to the claim, as taught by Fried, Shacham and Tonogai into view of Kats in order to provide confidence to the called party on the caller ID of the incoming call.
Regarding claim 17, Kats further teaches an urgency of call, such as “your driver is arriving with your pizza now” in para. [0601].
Regarding claim 18, Kats further teaches the features of identifying a caller if caller ID of an incoming call is present (or matched) in the on-device data structure (read on comparing an incoming call number to a directory) and displaying some portion of the SCCMC data structure in paragraphs [0632]-[0633], [0636] and [0639].
Regarding claims 19-20, Kats further teaches the limitations of the claim, such as when is call is not expected or the caller ID (the telephone number of caller’s device was not found in a directory), a call interceptor of the application (architecture app) on the recipient device to query automatic on-device contacts in order to provide a source of caller ID references for every incoming call (para. [0634]-[0637]).
Claims 5 and 12 are 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 10 above, and further in view of Pace, Jr. et al. (US 10,855,842 also cited in the previous Office Action).
Regarding claims 5 and 12, Kats and Fried, in combination, teaches all subject matters as claimed above, except for the feature of presenting an option for rescheduling the call for a future time. However, Pace, Jr. et al. (hereinafter “Pace, Jr.”) teaches such feature in figure 3, col.6, lines 38-40.
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 presenting an option for rescheduling the call for a future time, as taught by Pace, into view of Kats, Fried, Shacham and tonogai in order to allow the recipient not to answer the incoming call when it is not a good time to accept the call.
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/112,966 (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 claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any references 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 2025