DETAILED ACTION
This Action is in response to Applicant’s amendment filed on 05/05/26.
Claims 14 and 15 have been previously cancelled
Claims 1-13 and 16-18 are pending.
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 .
Response to Arguments
Argument – The applicant argues, in regards to the 103 rejection of claims 1, 8 and 11, that Geng does not disclose the limitation “send a join request to the co-hosting business server for requesting to join co-hosting, and at the same time or before receiving a return message for the join request from the co-hosting business server, apply to a real-time collaborative RTC server for joining a co-hosting room”. In particular, the applicant states that Geng fails to disclose “at the same time or before receiving a return message for the join request from the co-hosting business server, apply to a real-time collaborative RTC server for joining a co-hosting room” (see applicant’s remarks; pages 6-9).
Response to argument – The examiner respectfully disagrees. The examiner notes that it appears the applicant is specifying applying to the real-time collaborative RTC sever in advance of receiving a return message. In particular, the applicant states “Claim 1 defines a specific advanced timing sequence, whereby the terminal can apply to the RTC server even before receiving confirmation from the server” (emphasis added) (see applicant’s remarks; page 8). However, the claim limitation recites “at the same time or before receiving a return message…” (emphasis added). In other words, the terminal may receive transmission corresponding to the co-hosting room either before, i.e. in advance, or at the same time as receiving a return message.
Geng discloses the server determines two anchor terminals currently agreeing with the co-hosting based on the response message and sends a data transmission (emphasis added) (see Geng; paragraph 0028). The server determines, based on the response message, the first anchor terminal and the second anchor terminal which currently establish an interaction connection, and then sends the data transmission (emphasis added). Thereby, facilitating shortening transmission time of the live-streaming data and reducing delay of the live-streaming interaction video (see Geng; paragraph 0035). In other words, at the same time the response message for the co-hosting request is received at a co-hosting server the second terminal receives transmission of a live-streaming room from a live-streaming server.
Therefore, Geng does in fact disclose the limitation “send a join request to the co-hosting business server for requesting to join co-hosting, and at the same time or before receiving a return message for the join request from the co-hosting business server, apply to a real-time collaborative RTC server for joining a co-hosting room” by the second terminal sends a co-hosting request to the server, i.e. “send a join request to the co-hosting business server for requesting to join co-hosting”. A response message, i.e. “return message”, is sent back to the second terminal and based on the response message, i.e. “at the same time…receiving a return message”, data transmission of a live-streaming room is sent from the server. As such, the rejection has been maintained.
In order to help expedite prosecution, the examiner suggests the applicant amend claims 1, 8 and 11 to remove “at the same time or” from the limitation in order to more clearly specify that the second co-hosting terminal may advance the timing of applying to the RTC server for joining the co-hosting room. Such an amendment would clearly define the applicant’s invention, as well as, correspond to the applicant’s remarks.
The applicant states the same reasoning, as that of claims 1, 8 and 11, for the dependent claims 2-7, 9, 10, 12, 13 and 16-18 (see applicant’s remarks; page 9). As such, the same rationale discussed above applies equally as well to claims 2-7, 9, 10, 12, 13 and 16-18.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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, 2, 7, 8, 11 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over DU (U.S. 2022/0141500 A1) in view of Geng (U.S. 2022/0086509 A1).
Regarding claim 1, DU discloses a co-hosting system, comprising a first co-hosting terminal, a second co-hosting terminal and a co-hosting business server (see DU; paragraph 0062; DU discloses a first terminal, i.e. “first co-hosting terminal”, a second terminal, i.e. “second co-hosting terminal” and a server, i.e. “co-hosting business server”);
the first co-hosting terminal being configured to: send a co-hosting application request to the second co-hosting terminal through the co-hosting business server (see DU; paragraphs 0134, 0137 and 0140; DU discloses the first terminal, i.e. “first co-hosting terminal”, sends a co-hosting request, i.e. “co-hosting application request”, to the server, i.e. “co-hosting business server”. The server sends the co-hosting request to the target user account in response to receiving the co-hosting request and the second terminal, i.e. “second co-hosting terminal”, receives the co-hosting request, i.e. “through the co-hosting business server”);
the second co-hosting terminal being configured to: upon receipt of a co-hosting acceptance operation for the co-hosting application request, send a co-hosting acceptance message to the co-hosting business server (see DU; paragraphs 0143, 0144 and 0146; DU discloses the second terminal, i.e. “second co-hosting terminal”, sends co-hosting grant information to the server, i.e. “send a co-hosting acceptance message to the co-hosting business server”, in response to a grant operation, i.e. “upon receipt of a co-hosting acceptance operation”, on the co-hosting prompt information).
While DU discloses a live streaming room created using a stream push function of a live streaming tool (see DU; paragraph 0121) and “the second co-hosting terminal being configured to: upon receipt of a co-hosting acceptance operation for the co-hosting application request, send a co-hosting acceptance message to the co-hosting business server”, as discussed above, Du does not explicitly disclose send a join request to the co-hosting business server for requesting to join co-hosting, and at the same time or before receiving a return message for the join request from the co-hosting business server, apply to a real-time collaborative RTC server for joining a co-hosting room.
In analogous art, Geng discloses send a join request to the co-hosting business server for requesting to join co-hosting, and at the same time or before receiving a return message for the join request from the co-hosting business server, apply to a real-time collaborative RTC server for joining a co-hosting room (see Geng; paragraphs 0021, 0028 and 0035; Geng discloses first and second terminals interact and communicate with each other over a network and a server. The server may be implemented as a plurality of servers, such as a co-hosting server, i.e. “co-hosting business server”, and a live-streaming server, i.e. “a real-time collaborative RTC server”. The second terminal sends a co-hosting request to the server, i.e. “send a join request to the co-hosting business server for requesting to join co-hosting”. A response message, i.e. “return message”, is sent back to the second terminal and based on the response message, i.e. “at the same time…receiving a return message”, data transmission of a live-streaming room is sent from the server. Thereby, facilitating shortening transmission time of the live-streaming data and reducing delay of the live-streaming interaction video. In other words, at the same time the response message for the co-hosting request is received at a co-hosting server, i.e. “co-hosting business server”, the second terminal receives transmission of a live-streaming room from a live-streaming server, i.e. “apply to a real-time collaborative RTC server for joining a co-hosting room”).
One of ordinary skill in the art would have been motivated to combine DU and Geng because they both disclose features for co-hosting during live streaming and as such, are within the same environment.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate Geng’s control of a co-hosting process into the system of DU in order to provide the benefit of scalability by allowing the creation of the live streaming room (see DU; paragraph 0121) to be done at a separate server since a plurality of servers may be used to provide comprehensive and diverse services (see DU; paragraph 0065), such as, co-hosting servers and live-streaming servers (see Geng; paragraph 0021).
Regarding claim 2, DU and Geng disclose all the limitations of claim 1, as discussed above, and further the combination of DU ad Geng clearly discloses wherein, the first co-hosting terminal is further configured to: upon receipt of the co-hosting acceptance message from the co-hosting business server, apply to the RTC server for joining the co-hosting room (see Geng; paragraphs 0021, 0026 and 0028; Geng discloses a terminal, i.e. “first co-hosting terminal”, receives live-streaming data, i.e. “apply to the RTC server for joining the co-hosting room”, based on an approve/response message received from a co-hosting server, i.e. “co-hosting business server”, which is in response to a co-hosting request, i.e. “upon receipt of the co-hosting acceptance message”. In other words, a terminal is receiving a live streaming room from a first server of the plurality of servers, i.e. “apply to a real-time collaborative RTC server for joining a co-hosting room”, after receiving an approve/response message in response to a co-hosting request).
The prior art used in the rejection of the current claim is combined using the same motivation as was applied in claim 1.
Regarding claim 7, DU and Geng disclose all the limitations of claim 1, as discussed above, and further the combination of DU ad Geng clearly discloses wherein the first co-hosting terminal comprises a guest client, and the second co-hosting terminal comprises a host client (see DU; paragraphs 0058, 0062-0064; DU discloses the terms “first” and “second” are configured to distinguish between similar objects but do not necessarily indicate a specific order or sequence. And between the first and second terminals, one terminal is an anchor, i.e. “host”, while the other is target, i.e. “guest”).
Regarding claim 8, DU discloses a method applied to a second co-hosting terminal (see DU; paragraph 0062; DU discloses a second terminal, i.e. “second co-hosting terminal”), comprising:
receiving a co-hosting application request from a first co-hosting terminal through a co-hosting business server (see DU; paragraphs 0134, 0137 and 0140; DU discloses a first terminal, i.e. “first co-hosting terminal”, sends a co-hosting request, i.e. “co-hosting application request”, to a server, i.e. “co-hosting business server”. The server sends the co-hosting request to the target user account in response to receiving the co-hosting request and the second terminal, i.e. “second co-hosting terminal”, receives the co-hosting request, i.e. “through a co-hosting business server”);
upon receipt of a co-hosting acceptance operation for the co-hosting application request, sending a co-hosting acceptance message to the co-hosting business server (see DU; paragraphs 0143, 0144 and 0146; DU discloses the second terminal, i.e. “second co-hosting terminal”, sends co-hosting grant information to the server, i.e. “send a co-hosting acceptance message to the co-hosting business server”, in response to a grant operation, i.e. “upon receipt of a co-hosting acceptance operation”, on the co-hosting prompt information).
While DU discloses a live streaming room created using a stream push function of a live streaming tool (see DU; paragraph 0121), as well as, “upon receipt of a co-hosting acceptance operation for the co-hosting application request, sending a co-hosting acceptance message to the co-hosting business server”, as discussed above,, DU does not explicitly disclose sending a join request to the co-hosting business server for requesting to join co-hosting, and at the same time or before receiving a return message for the join request from the co-hosting business server, applying to a real-time collaborative RTC server for joining a co-hosting room.
In analogous art, Geng discloses sending a join request to the co-hosting business server for requesting to join co-hosting, and at the same time or before receiving a return message for the join request from the co-hosting business server, applying to a real-time collaborative RTC server for joining a co-hosting room (see Geng; paragraphs 0021, 0028 and 0035; Geng discloses first and second terminals interact and communicate with each other over a network and a server. The server may be implemented as a plurality of servers, such as a co-hosting server, i.e. “co-hosting business server”, and a live-streaming server, i.e. “a real-time collaborative RTC server”. The second terminal sends a co-hosting request to the server, i.e. “send a join request to the co-hosting business server for requesting to join co-hosting”. A response message, i.e. “return message”, is sent back to the second terminal and based on the response message, i.e. “at the same time…receiving a return message”, data transmission of a live-streaming room is sent from the server. Thereby, facilitating shortening transmission time of the live-streaming data and reducing delay of the live-streaming interaction video. In other words, at the same time the response message for the co-hosting request is received at a co-hosting server, i.e. “co-hosting business server”, the second terminal receives transmission of a live-streaming room from a live-streaming server, i.e. “apply to a real-time collaborative RTC server for joining a co-hosting room”).
One of ordinary skill in the art would have been motivated to combine DU and Geng because they both disclose features for co-hosting during live streaming and as such, are within the same environment.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate Geng’s control of a co-hosting process into the system of DU in order to provide the benefit of scalability by allowing the creation of the live streaming room (see DU; paragraph 0121) to be done at a separate server since a plurality of servers may be used to provide comprehensive and diverse services (see DU; paragraph 0065), such as, co-hosting servers and live-streaming servers (see Geng; paragraph 0021).
Regarding claim 11, DU discloses a co-hosting method applied to a first co-hosting terminal (see DU; paragraph 0062; Du discloses a first terminal, i.e. “first co-hosting terminal”), comprising:
sending a co-hosting application request to a second co-hosting terminal through a co-hosting business server (see DU; paragraphs 0134, 0137 and 0140; DU discloses a first terminal, i.e. “first co-hosting terminal”, sends a co-hosting request, i.e. “co-hosting application request”, to a server, i.e. “co-hosting business server”. The server sends the co-hosting request to the target user account in response to receiving the co-hosting request and the second terminal, i.e. “second co-hosting terminal”, receives the co-hosting request, i.e. “through a co-hosting business server”);
wherein the second co-hosting terminal is configured to: upon receipt of a co-hosting acceptance operation for the co-hosting application request, send a co-hosting acceptance message to the co-hosting business server (see DU; paragraphs 0143, 0144 and 0146; DU discloses the second terminal, i.e. “second co-hosting terminal”, sends co-hosting grant information to the server, i.e. “send a co-hosting acceptance message to the co-hosting business server”, in response to a grant operation, i.e. “upon receipt of a co-hosting acceptance operation”, on the co-hosting prompt information).
While DU discloses “receipt of the co-hosting acceptance message from the co-hosting business server” (see DU; paragraphs 0151 and 0154; DU discloses the server sends co-hosting success information, e.g. co-hosting has been granted, to the first terminal), as well as, “wherein the second co-hosting terminal is configured to: upon receipt of a co-hosting acceptance operation for the co-hosting application request, send a co-hosting acceptance message to the co-hosting business server”, as discussed above, DU does not explicitly disclose send a join request to the co-hosting business server for requesting to join co-hosting, and at the same time or before receiving a return message for the join request from the co-hosting business server, applying to a real-time collaborative RTC server for joining a co-hosting room; and upon receipt of the co-hosting acceptance message from the co-hosting business server, apply to a real-time collaborative RTC server for joining a co-hosting room.
In analogous art, Geng discloses send a join request to the co-hosting business server for requesting to join co-hosting, and at the same time or before receiving a return message for the join request from the co-hosting business server, applying to a real-time collaborative RTC server for joining a co-hosting room (see Geng; paragraphs 0021, 0028 and 0035; Geng discloses first and second terminals interact and communicate with each other over a network and a server. The server may be implemented as a plurality of servers, such as a co-hosting server, i.e. “co-hosting business server”, and a live-streaming server, i.e. “a real-time collaborative RTC server”. The second terminal sends a co-hosting request to the server, i.e. “send a join request to the co-hosting business server for requesting to join co-hosting”. A response message, i.e. “return message”, is sent back to the second terminal and based on the response message, i.e. “at the same time…receiving a return message”, data transmission of a live-streaming room is sent from the server. Thereby, facilitating shortening transmission time of the live-streaming data and reducing delay of the live-streaming interaction video. In other words, at the same time the response message for the co-hosting request is received at a co-hosting server, i.e. “co-hosting business server”, the second terminal receives transmission of a live-streaming room from a live-streaming server, i.e. “apply to a real-time collaborative RTC server for joining a co-hosting room”).
upon receipt of the co-hosting acceptance message from the co-hosting business server, apply to a real-time collaborative RTC server for joining a co-hosting room (see Geng; paragraphs 0021, 0026 and 0028; Geng discloses a terminal receives live-streaming data, i.e. “apply to the RTC server for joining the co-hosting room”, based on an approve/response message received from a co-hosting server, i.e. “co-hosting business server”, which is in response to a co-hosting request, i.e. “upon receipt of the co-hosting acceptance message”. In other words, a terminal is receiving a live streaming room from a first server of the plurality of servers, i.e. “apply to a real-time collaborative RTC server for joining a co-hosting room”, after receiving an approve/response message in response to a co-hosting request).
One of ordinary skill in the art would have been motivated to combine DU and Geng because they both disclose features for co-hosting during live streaming and as such, are within the same environment.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate Geng’s control of a co-hosting process into the system of DU in order to provide the benefit of scalability by allowing the creation of the live streaming room (see DU; paragraph 0121) to be done at a separate server since a plurality of servers may be used to provide comprehensive and diverse services (see DU; paragraph 0065), such as, co-hosting servers and live-streaming servers (see Geng; paragraph 0021).
Regarding claim 16, DU and Geng disclose all the limitations of claim 8, as discussed above, and further the combination of DU ad Geng clearly discloses a non-transitory computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when executed on a computer device, cause the computer device to implement the method of claim 8 (see DU; paragraph 0031; DU discloses a non-transitory computer-readable storage medium stores at least one instruction executed by a processor).
Regarding claim 17, DU and Geng disclose all the limitations of claim 8, as discussed above, and further the combination of DU ad Geng clearly discloses a device comprising: a memory, a processor, and a computer program stored on the memory, wherein the processor, when executing the computer program, implements the method of claim 8 (see DU; paragraph 0236 and 0237; DU discloses a processor executing a program stored on a memory which includes one or more computer-readable storage media).
Regarding claim 18, DU and Geng disclose all the limitations of claim 8, as discussed above, and further the combination of DU ad Geng clearly discloses a computer program product, wherein the computer program product comprises a computer program/instructions, wherein the computer program/instructions, when executed by a processor, implements the method of claim 8 (see DU; paragraph 0237; DU discloses at least one program code is executed by the processor to perform the method).
Claims 3-6, 9, 10, 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over DU (U.S. 2022/0141500 A1) in view of Geng (U.S. 2022/0086509 A1), as applied to claims 1 above, and further in view of Benson et al. (U.S. 2025/0023933 A1).
Regarding claims 3 and 9, DU and Geng disclose all the limitations of claims 1 and 8, as discussed above. While DU discloses “receipt of the co-hosting acceptance operation for the co-hosting application request”, as discussed above, the combination of DU and Geng does not explicitly disclose wherein, the second co-hosting terminal is further configured to: upon receipt of the co-hosting acceptance operation for the co-hosting application request, present a countdown window.
In analogous art, Benson discloses wherein, the second co-hosting terminal is further configured to: upon receipt of the co-hosting acceptance operation for the co-hosting application request, present a countdown window (see Benson; paragraphs 0100-0102; Benson discloses upon a response to an invitation to a video conference, i.e. “co-hosting application”, a countdown is shown, i.e. “present a countdown window”, indicating a time remaining to join the video conference. The examiner notes that according to the applicant’s specification, a video call is also known as co-hosting, see applicant’s specification as filed; page 5 lines 1-2).
One of ordinary skill in the art would have been motivated to combine DU, Geng and Benson because they all disclose features for collaborative conferencing and as such, are within the same environment.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate Benson’s countdown into the combined system of DU and Geng in order to provide the benefit of efficiency by allowing resources provisioned for the connection to be released when they have not been used.
Regarding claims 4 and 10, DU, Geng and Benson disclose all the limitations of claims 3 and 9, as discussed above, and further the combination of DU, Geng and Benson clearly discloses wherein, the second co-hosting terminal is further configured to: according to a determination that countdown of the countdown window ends (see Benson; paragraphs 0102 and 0117; Benson discloses determining expiration of the countdown, i.e. “countdown window ends”, for a timer), determine whether an audio-video stream pushed by the first co-hosting terminal has been received (see Benson; paragraphs 0104 and 0117; Benson discloses a guest is given a predetermined amount of time to join and provide audio and video to the conference); and according to a determination that the audio- video stream has not been received, send a disconnecting co-hosting link request to the co- hosting business server and the RTC server respectively (see Benson; paragraph 0117; Benson discloses determining the timer has expired and no join response received, i.e. “the audio- video stream has not been received” and the join link is disabled, i.e. “disconnecting co-hosting link request”).
The prior art used in the rejection of the current claim is combined using the same motivation as was applied in claim 3.
Regarding claims 5 and 12, DU and Geng disclose all the limitations of claims 1 and 11, as discussed above. While DU discloses “receipt of the co-hosting acceptance operation for the co-hosting application request”, as discussed above, the combination of DU and Geng does not explicitly disclose wherein the first co-hosting terminal is further configured to: upon receipt of the co-hosting acceptance message from the co-hosting business server, present a countdown window.
In analogous art, Benson discloses wherein the first co-hosting terminal is further configured to: upon receipt of the co-hosting acceptance message from the co-hosting business server, present a countdown window (see Benson; paragraphs 0100-0102; Benson discloses upon a response to an invitation to a video conference, i.e. “co-hosting application”, a countdown is shown, i.e. “present a countdown window”, indicating a time remaining to join the video conference. The examiner notes that according to the applicant’s specification, a video call is also known as co-hosting, see applicant’s specification as filed; page 5 lines 1-2).
One of ordinary skill in the art would have been motivated to combine DU, Geng and Benson because they all disclose features for collaborative conferencing and as such, are within the same environment.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate Benson’s countdown into the combined system of DU and Geng in order to provide the benefit of efficiency by allowing resources provisioned for the connection to be released when they have not been used.
Regarding claims 6 and 13, DU and Geng disclose all the limitations of claims 5 and 12, as discussed above, and further the combination of DU, Geng and Benson clearly discloses wherein the first co-hosting terminal is further configured to: according to a determination that countdown of the countdown window ends, push an audio-video stream to the RTC server (see Benson; paragraphs 0094, 0102 and 0104; Benson discloses at the end of the countdown, the timed one-on-one video conference call session may commence, in which audio and video streams are provided, i.e. “push an audio-video stream”).
The prior art used in the rejection of the current claim is combined using the same motivation as was applied in claim 5.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Irwin et al. (U.S. 2014/0324952 A1) discloses reducing call connection time for a video call.
Johar et al. (U.S. 2016/0269504 A1) discloses enabling joining a video call and indicating an elapsed time since the call was initiated.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADAM A COONEY whose telephone number is (571)270-5653. The examiner can normally be reached M-F 7:30am-5:00pm (every other Fri off).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached at 571-270-3037. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.A.C/Examiner, Art Unit 2458 07/29/26
/UMAR CHEEMA/Supervisory Patent Examiner, Art Unit 2458
Prosecution Insights