DETAILED ACTION
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 .
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 03/10/2026 has been entered.
Status of Claims
Applicant filed an RCE on 03/10/2026. Claims 1, 2, 8, 9, 14, and 15 have been amended. Claims 1–20 are currently pending examination.
Response to Arguments
Regarding the claim rejections under 35 U.S.C. § 103: Applicant's arguments with respect to James et al. (US20160355192A1) in view of Nölscher et al. (US20200029209A1) have been fully considered but they 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, in view of Cho (S20200207334A1) in view of Ahn (US20210162989A1) and further in view of ISO 23374-1:2023 (Intelligent transport systems — Automated valet parking systems (AVPS) — Part 1, First edition 2023-07).
Claim Objections
Claims 3, 10, and 16 are objected to because the parent independents recite "a handshake protocol" / "the handshake protocol," but these dependents introduce "an external handshake protocol" and then "processing the external handshake protocol" without a clear antecedent or an express statement that the external handshake is the handshake of the parent. Applicant should amend to "the handshake protocol" throughout, or expressly define the external handshake as the handshake of Claim 1/8/14. Appropriate correction is required.
Claim 12 is objected to because it recites causing the vehicles "to revert to the second AVM feature state, from the first AVM feature state, based on an unsuccessful completion of the handshake protocol associated with the second AVM feature state." That failure path is internally inconsistent with (i) independent Claim 1 (revert to the first on unsuccessful handshake associated with the second state), (ii) independent Claim 8 (progress to the second on successful handshake), and (iii) the specification, which states that unsuccessful completion causes the vehicles "to remain in (e.g., revert to) the first state" ( [0101]; see also [0110]). Applicant should amend Claim 12 to revert to the first from the second (or from an attempted second) on unsuccessful completion. Appropriate correction is required.
Claim 14 is objected to because the closing clause recites that the infrastructure system is configured to "send the message to the vehicle system," but the only message previously recited in Claim 14 is "an infrastructure marshaling message." There is no antecedent basis for "the message." Applicant should amend to "send the infrastructure marshaling message" (or "said infrastructure marshaling message"). Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1, 3-8, 10, 14 and 16–20 are rejected under 35 U.S.C. 103 as being unpatentable over Cho (uS20200207334A1) in view of Ahn (US20210162989A1), hereinafter referred to as Cho and Ahn.
Regarding claims 1 and 8 Cho discloses
initiating, at one or more vehicles, a state transition from a first automated vehicle marshaling (AVM) feature state of a plurality of AVM feature states to a second AVM feature state of the plurality of AVM feature states based on an infrastructure marshaling message uniquely associated with the second AVM feature state ("In step (2), an autonomous valet parking preparation command is transmitted from the infrastructure facility to the vehicle. The autonomous valet parking preparation command is sent to the vehicle before the autonomous driving of the vehicle begins." [0065]; "In step (7), an autonomous valet parking start command is transmitted from the infrastructure facility to the vehicle. The transmission of the autonomous valet parking start command is performed after the guide route and the driving boundary are delivered." [0070]; "In step (9), a vehicle control release command is transmitted from the infrastructure facility to the vehicle." [0072]; drop-off then "the driving authority of the vehicle is delegated to the infrastructure facility" and autonomous travel along the infra-determined guide route, [0049]);
wherein the infrastructure marshaling message is received directly from an infrastructure system
("The target position, the guide route and the driving route determined by the infrastructure are transmitted from the infrastructure facility to the vehicle." [0056]; "The vehicle performs autonomous driving according to commands transmitted from the infrastructure facility to the vehicle." [0057]);
wherein the infrastructure marshaling message is related to autonomously maneuvering the one or more vehicles by the infrastructure system when the one or more vehicles are under active motion control from the infrastructure system ("After the driving authority of the vehicle is delegated to the infrastructure facility, the infrastructure facility takes complete control of the vehicle while the vehicle is performing autonomous valet parking. … The vehicle operations include steering, accelerating, braking, gear shifting, engine starting/stopping, and door locking/unlocking." [0055]; autonomous driving "according to commands transmitted from the infrastructure facility," including a preset speed and "preset error margin of the given guide route" that "may be a value transmitted from the infrastructure facility," [0057);
processing, by the one or more vehicles, a handshake protocol between the infrastructure system and the one or more vehicles, the handshake protocol being utilized by the infrastructure system to take control of the one or more vehicles ("In step (3), the infrastructure facility 100 transmits an authentication ID request to the vehicle 200. In step (4), the vehicle 200 transmits an authentication ID to the infrastructure facility 100. In step (5), the infrastructure facility 100 determines approval or disapproval of the entry of the vehicle into the parking lot on the basis of the received authentication ID. … In step (8), the authority to drive and control the vehicle 200 is delegated from the vehicle 200 (or driver) to the infrastructure facility 100. In step (9), the infrastructure facility 100 notifies the driver that the authority to drive or control the vehicle 200 is delegated thereto." [0074],
and the handshake protocol being associated with the second AVM feature state in response to the initiation of the state transition from the first AVM feature state to the second AVM feature state ("In step (4), the infrastructure facility 100 transmits an autonomous valet parking preparation request to the vehicle 200. In step (5), the vehicle 200 transmits a reply to the automated valet parking preparation request to the infrastructure facility 100. The reply is a message of OK indicating that the preparation for automated valet parking is completed or a message of NG indicating that the preparation for automated valet parking is not completed. In step (6), the infrastructure facility 100 transmits a synchronization request to vehicle 200. … until the synchronization between the infrastructure facility 100 and the vehicle 200 is completed, a plurality of synchronization requests may be transmitted from the infrastructure facility 100 to the vehicle 200." [0076]);
and, as to claim 8,
causing the one or more vehicles to progress to the second AVM feature state in response to a successful completion of the handshake protocol associated with the second AVM feature state
(OK reply then synchronization then start command sequence, “The reply is a message of OK indicating that the preparation for automated valet parking is completed …….. the infrastructure facility 100 transmits a synchronization request to vehicle 200. ….. transmits a reply indicating that the synchronization is completed to the infrastructure facility 100. …….. .. the infrastructure facility 100 transmits boundary information of the permitted driving area to the vehicle 200. In step (13), the infrastructure facility 100 transmits a guide route to the vehicle 200. In step (14), the infrastructure facility 100 transmits an autonomous valet parking start command to the vehicle 200.” [0076]).
Cho does not explicitly disclose
causing the one or more vehicles to revert to the first AVM feature state in response to an unsuccessful completion of the handshake protocol associated with the second AVM feature state.
However, Ahn does teach causing the one or more vehicles to revert to the first AVM feature state in response to an unsuccessful completion of the handshake protocol associated with the second AVM feature state (unsuccessful-completion paths that do not progress into the target stage including V2I direct reception ("The communication unit 220 is configured to communicate data with the infrastructure 100. This communication is called vehicle-to-infra (V2I) communication." [0038], FIG. 2; "the communication unit 220 receives data such as a target position, a guide rote, a driving route, an instruction, or the like from the infrastructure 100" [0038]), complete infrastructure motion control ("Since the driving authority for the vehicle is delegated to the infrastructure, the infrastructure takes complete control of the vehicle during the automated valet parking process of the vehicle." FIGS. 4A–4B item (1); [0054]), stage-unique messages (Ahn FIG. 5 prep / start / brake / release; FIG. 7 engine-on / prep / OK–NG / sync / start), and unsuccessful vs successful handshake paths (FIG. 7: "The reply is a message of OK indicating that the preparation for automated valet parking is completed or a message of NG indicating that the preparation for automated valet parking is not completed"; FIG. 6 approval or disapproval of entry; FIG. 5 1 Hz vehicle-info / ACK miss-time communication-error detection).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the AVP V2I method of Cho to include the cumulative FIG/step handshake and stage sequencing taught by Ahn, because Cho and Ahn disclose infrastructure-led automated valet parking take-control protocol and one of ordinary skill in the art would combine the command sequence of Cho with Ahn's OK/NG / auth-ID / sync confirmation loops to ensure infrastructure does not start autonomous motion until the preparation handshake succeeds, with a reasonable expectation of success. See at least Ahn [0038, 0054, 0077].
Regarding claims 3, 10, and 16, Cho discloses
wherein an external handshake protocol varies based on each of the plurality of AVM feature states such that one or more characteristics of the external handshake protocol varies based on each of the plurality of AVM feature states (distinct stage messages: “autonomous valet parking preparation command,” [0065]; vehicle information at 1 Hz and acknowledgement, [0066-0067]; “autonomous valet parking start command,” [0076]; “vehicle control release command,” [0072]; authentication ID request/reply, [0074]; OK/NG reply and synchronization request, [0076]),
and wherein processing the external handshake protocol comprises: initiating one or more actions based on a message exchange between the infrastructure system and the one or more vehicles, wherein the one or more actions includes a verification of a wireless connection associated with the one or more vehicles (“The vehicle information is transmitted periodically at a specific frequency (for example, 1 Hz which means once per second). The vehicle information is used as a parameter to determine whether a communication error has occurred between the vehicle and the infrastructure facility. For example, when the vehicle information is not received by the infrastructure facility at a predetermined time which is set according to the specific communication frequency, the infrastructure facility determines that an error has occurred in communication between the vehicle and the infrastructure facility.” [0066]; acknowledgement miss-time, [0067]),
an authentication of the message (“the infrastructure facility 100 transmits an authentication ID request to the vehicle 200. … the infrastructure facility 100 determines approval or disapproval of the entry of the vehicle into the parking lot on the basis of the received authentication ID.” [0074]),
a validation of whether the one or more vehicles are within an operational design domain, or a combination thereof (“The vehicle can autonomously drive to the target position along the guide route within the permitted driving area. … the vehicle is controlled not to deviate from a preset error margin of the given guide route … This preset error margin may be transmitted from the infrastructure facility to the vehicle.” [0057]),
and wherein the one or more characteristics of the external handshake protocol includes an inter-transmit time associated with the message, a tolerance threshold of a connection strength associated with the one or more vehicles, or a combination thereof (“transmitted periodically at a specific frequency (for example, 1 Hz which means once per second)” and “predetermined time which is set according to the specific communication frequency,” [0066]).
Regarding claims 4, 11, and 17, Cho discloses
wherein each AVM feature state of the plurality of AVM feature states is associated with a different message (“In step (2), an autonomous valet parking preparation command is transmitted from the infrastructure facility to the vehicle.” [0065]; vehicle information at 1 Hz, [0066]; acknowledgement, [0067]; “an autonomous valet parking start command,” [0076]; “a vehicle control release command,” [0072]; authentication ID request, [0074]; OK/NG reply and synchronization request, [0076]).
Regarding claims 5 and 18, Cho discloses
further comprising: causing the one or more vehicles to progress to the second AVM feature state, from the first AVM feature state, based on a successful completion of the handshake protocol associated with the second AVM feature state (“The reply is a message of OK indicating that the preparation for automated valet parking is completed”; “until the synchronization between the infrastructure facility 100 and the vehicle 200 is completed, a plurality of synchronization requests may be transmitted” [0076]; “an autonomous valet parking start command is transmitted from the infrastructure facility to the vehicle. The transmission of the autonomous valet parking start command is performed after the guide route and the driving boundary are delivered.” [0070] ).
Regarding claims 6, 13, and 19, Cho discloses
further comprising: initiating, at the one or more vehicles, a state transition from the second AVM feature state of the plurality of AVM feature states to a third AVM feature state of the plurality of AVM feature states based on the progression to the second AVM feature state and on a message uniquely associated with the third AVM feature state (multi-stage chain: preparation command → start command → control release command, [0069-0072]; authority delegation then autonomous driving then finish/release, [0049]; [0061]);
processing, by the one or more vehicles, a handshake protocol associated with the third AVM feature state in response to the initiation of the state transition from the second AVM feature state to the third AVM feature state (OK/NG / sync before start, [0076]; authentication before authority delegation, [0098]);
and causing the one or more vehicles to progress to the third AVM feature state in response to a successful completion of the handshake protocol associated with the third AVM feature state (start after guide/boundary delivered, [0070]; control release after autonomous parking completed, [0061]).
Regarding claims 7 and 20, Cho discloses
further comprising: transmitting an alert to the infrastructure system associated with the unsuccessful completion of the handshake protocol associated with the second AVM feature state (“a message of NG indicating that the preparation for automated valet parking is not completed.” [0076]; “The vehicle monitors communication with the infrastructure facility to detect whether a communication error occurs.” [0062]),
wherein the transmission of the alert is based on a reversion of the one or more vehicles to the first AVM feature state (“a message of NG indicating that the preparation for automated valet parking is not completed.” [0076]; “The vehicle monitors communication with the infrastructure facility to detect whether a communication error occurs.” [0062]).
Regarding claim 12, Cho does not explicitly disclose
causing the one or more vehicles to revert to the second AVM feature state, from the first AVM feature state, based on an unsuccessful completion of the handshake protocol associated with the second AVM feature state.
However, Ahn does teach causing the one or more vehicles to revert to the second AVM feature state, from the first AVM feature state, based on an unsuccessful completion of the handshake protocol associated with the second AVM feature state. (unsuccessful-completion paths that do not progress into the target stage including V2I direct reception ("The communication unit 220 is configured to communicate data with the infrastructure 100. This communication is called vehicle-to-infra (V2I) communication." [0038], FIG. 2; "the communication unit 220 receives data such as a target position, a guide rote, a driving route, an instruction, or the like from the infrastructure 100" [0038]), complete infrastructure motion control ("Since the driving authority for the vehicle is delegated to the infrastructure, the infrastructure takes complete control of the vehicle during the automated valet parking process of the vehicle." FIGS. 4A–4B item (1); [0054]), stage-unique messages (Ahn FIG. 5 prep / start / brake / release; FIG. 7 engine-on / prep / OK–NG / sync / start), and unsuccessful vs successful handshake paths (FIG. 7: "The reply is a message of OK indicating that the preparation for automated valet parking is completed or a message of NG indicating that the preparation for automated valet parking is not completed"; [0077]FIG. 6 approval or disapproval of entry; FIG. 5 1 Hz vehicle-info / ACK miss-time communication-error detection).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the AVP V2I method of Cho to include the cumulative FIG/step handshake and stage sequencing taught by Ahn, because Cho and Ahn disclose infrastructure-led automated valet parking take-control protocol and one of ordinary skill in the art would combine the command sequence of Cho with Ahn's OK/NG / auth-ID / sync confirmation loops to ensure infrastructure does not start autonomous motion until the preparation handshake succeeds, with a reasonable expectation of success. See at least Ahn [0038, 0054, 0077].
Regarding claim 14, Cho discloses
A system comprising:
a vehicle system associated with one or more vehicles (“FIG. 1 is a view illustrating an automated valet parking system” [0011]) configured to:
initiate a state transition from a first automated vehicle marshaling (AVM) feature state of a plurality of AVM feature states to a second AVM feature state of the plurality of AVM feature states based on an infrastructure marshaling message uniquely associated with the second AVM feature state (“In step (2), an autonomous valet parking preparation command is transmitted from the infrastructure facility to the vehicle.” [0065]; “In step (7), an autonomous valet parking start command is transmitted from the infrastructure facility to the vehicle.” [0070]; “That is, the processor 230 refers to a device that performs a series of operations and makes determinations to control the vehicle 200 and to perform autonomous valet parking. … The vehicle controller 240 controls traveling, stopping, resuming of traveling, steering, accelerating, decelerating, lighting of lamps, alarm sounding, etc.” [0044]);
wherein the infrastructure marshaling message is received directly from an infrastructure system (“The target position, the guide route and the driving route determined by the infrastructure are transmitted from the infrastructure facility to the vehicle.” [0056]; “The vehicle performs autonomous driving according to commands transmitted from the infrastructure facility to the vehicle.” [0057]);
wherein the infrastructure marshaling message is related to autonomously maneuvering the one or more vehicles by the infrastructure system when the one or more vehicles are under active motion control from the infrastructure system (“After the driving authority of the vehicle is delegated to the infrastructure facility, the infrastructure facility takes complete control of the vehicle while the vehicle is performing autonomous valet parking.” [0055]);
process a handshake protocol between the infrastructure system and the one or more vehicles, the handshake protocol being utilized by the infrastructure system to take control of the one or more vehicles, and the handshake protocol being associated with the second AVM feature state in response to the initiation of the state transition from the first AVM feature state to the second AVM feature state ([0074] authentication-ID request/reply and authority delegation; [0076] preparation request / OK–NG reply / synchronization request);
and the infrastructure system configured to: send the message to the vehicle system (“commands transmitted from the infrastructure facility to the vehicle,” [0057]).
Cho does not explicitly disclose
cause the one or more vehicles to revert to the first AVM feature state in response to an unsuccessful completion of the handshake protocol associated with the second AVM feature state
However, Ahn does teach cause the one or more vehicles to revert to the first AVM feature state in response to an unsuccessful completion of the handshake protocol associated with the second AVM feature state. (unsuccessful-completion paths that do not progress into the target stage including V2I direct reception ("The communication unit 220 is configured to communicate data with the infrastructure 100. This communication is called vehicle-to-infra (V2I) communication." [0038], FIG. 2; "the communication unit 220 receives data such as a target position, a guide rote, a driving route, an instruction, or the like from the infrastructure 100" [0038]), complete infrastructure motion control ("Since the driving authority for the vehicle is delegated to the infrastructure, the infrastructure takes complete control of the vehicle during the automated valet parking process of the vehicle." FIGS. 4A–4B item (1); [0054]), stage-unique messages (Ahn FIG. 5 prep / start / brake / release; FIG. 7 engine-on / prep / OK–NG / sync / start), and unsuccessful vs successful handshake paths (FIG. 7: "The reply is a message of OK indicating that the preparation for automated valet parking is completed or a message of NG indicating that the preparation for automated valet parking is not completed"; FIG. 6 approval or disapproval of entry; FIG. 5 1 Hz vehicle-info / ACK miss-time communication-error detection).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the AVP V2I method of Cho to include the cumulative FIG/step handshake and stage sequencing taught by Ahn, because Cho and Ahn disclose infrastructure-led automated valet parking take-control protocol and one of ordinary skill in the art would combine the command sequence of Cho with Ahn's OK/NG / auth-ID / sync confirmation loops to ensure infrastructure does not start autonomous motion until the preparation handshake succeeds, with a reasonable expectation of success. See at least Ahn [0038, 0054, 0077].
Claims 2, 9 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Cho in view of Ahn as applied to claim 1 above and further in view of ISO 23374-1:2023 (Intelligent transport systems — Automated valet parking systems (AVPS) — Part 1, First edition 2023-07), hereinafter referred to as ISO23374.
Regarding claims 2, 9, and 15, Cho in view of Ahn discloses
the pre-onboarding state is a state in which the infrastructure system and a respective vehicle of the one or more vehicles perform an activation process for respective AVM features (“In step (2), an autonomous valet parking preparation command is transmitted from the infrastructure facility to the vehicle. The autonomous valet parking preparation command is sent to the vehicle before the autonomous driving of the vehicle begins.” [0065]),
the on-boarding state is a state in which the infrastructure system and the respective vehicle of the one or more vehicles complete authorization activities as part of a vehicle identification process so that the infrastructure system gains control of the respective vehicle of the one or more vehicles (“In step (3), the infrastructure facility 100 transmits an authentication ID request to the vehicle 200. … In step (5), the infrastructure facility 100 determines approval or disapproval of the entry of the vehicle into the parking lot on the basis of the received authentication ID. … In step (8), the authority to drive and control the vehicle 200 is delegated from the vehicle 200 (or driver) to the infrastructure facility 100.” [0074]; “the infrastructure facility takes complete control of the vehicle,” [0055]),
and the marshaling state is a state in which the infrastructure system autonomously controls the one or more vehicles when the one or more vehicles are under active motion control from the infrastructure system (“The vehicle performs autonomous driving according to commands transmitted from the infrastructure facility to the vehicle.” [0057]; “an autonomous valet parking start command is transmitted from the infrastructure facility to the vehicle.” [0070]). Cho further teaches de-/off-boarding / return of authority (“In step (6), the driver arrives at the pickup area and takes over the driving authority for the vehicle.” [0053]; control release, [0061, 0072]).
Cho in view Ahn does not explicitly disclose
wherein the plurality of AVM feature states includes an un-initiated state, a pre-onboarding state, an on-boarding state, a marshaling state, a de-boarding state, and an off-boarding state
However, ISO23374 does teach
wherein the plurality of AVM feature states includes an un-initiated state, a pre-onboarding state, an on-boarding state, a marshaling state, a de-boarding state, and an off-boarding state.
Named lifecycle states spanning check-in to check-out with automatic-operation missions and exclusive authority handoff:
(session — “sequence of interactions for a given subject vehicle (SV) between a check-in (see 9.3.3.1) and a check-out (see 9.3.3.2),” with a “sleep sub-state (see 9.3.2.3.3)” and a wireless connection on the operation interface during a session (ISO23374 Term 3.24, Notes 1–2);
(mission — “sequence of interactions under which the subject vehicle (SV) is being operated automatically by an automated valet parking system (AVPS)” (ISO23374 Term 3.25);
(authority “transferred between the user and the service provider, and does not exist among the two at the same time” (ISO23374 Term 3.3);
at drop-off the user “hands over authority to the service provider” (ISO23374 Term 3.7); pick-up authority return (ISO23374 Term 3.8);
“Automated valet parking systems (AVPSs) perform level 4 automated driving of individual or multiple unoccupied vehicles within a prescribed area of a parking facility,” and the document “defines the system architecture and the communication interfaces between the sub-systems” (ISO23374 Clause 1);
TOC: Clause 9.3 “System states and transition diagram” (9.3.1 diagram; 9.3.2 definition/requirements of system states; 9.3.3 transition conditions); 9.4 Suspend condition codes; 10.7.2 Scene 42 Communication failure; Annex A (normative) Communication sequences.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Cho in view Ahn method so that the plurality of AVM feature states includes the recited named states (mapped to ISO23374’s session/mission/check-in/check-out/sleep architecture), because ISO23374 is the international AVPS framework for the same use case — L4 unoccupied parking-facility operation with exclusive authority transfer and a normative system-state / transition architecture — and ISO’s Introduction leaves “specific technological solutions for the communications interface (e.g. communication method, message protocol)” open, so implementing ISO23374’s communication interface would look to an existing deployed-style AVP V2I protocol such as Cho (request/reply, OK/NG, periodic keep-alive, stage-specific instructions). Conversely, building on Cho would conform enter/prepare/drive/exit stages to ISO23374’s named states so the implementation interoperates with ISO-compliant facilities, with a reasonable expectation of success: both address the same parking-facility, infrastructure-to-vehicle, authority-transfer problem.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AHMED ALKIRSH whose telephone number is (703) 756-4503. The examiner can normally be reached M-F 9:00 am-5:00 pm EST.
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, FADEY JABR can be reached on (571) 272-1516. 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./Examiner, Art Unit 3668
/Fadey S. Jabr/Supervisory Patent Examiner, Art Unit 3668
