Prosecution Insights
Last updated: October 23, 2026
Application No. 18/859,349

IN-VEHICLE DEVICE, PROGRAM, AND INFORMATION PROCESSING METHOD

Final Rejection §102§103
Filed
Oct 23, 2024
Priority
Apr 27, 2022 — JP 2022-073430 +1 more
Examiner
DABIPI, DIXON F
Art Unit
2451
Tech Center
2400 — Computer Networks
Assignee
Sumitomo Electric Industries Ltd.
OA Round
2 (Final)
78%
Grant Probability
Favorable
3-4
OA Rounds
11m
Est. Remaining
93%
With Interview

Examiner Intelligence

Grants 78% — above average
78%
Career Allowance Rate
197 granted / 254 resolved
+19.6% vs TC avg
Strong +15% interview lift
Without
With
+15.2%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
10 currently pending
Career history
277
Total Applications
across all art units

Statute-Specific Performance

§101
9.2%
-30.8% vs TC avg
§103
64.2%
+24.2% vs TC avg
§102
10.9%
-29.1% vs TC avg
§112
9.9%
-30.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 254 resolved cases

Office Action

§102 §103
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 . Response to Arguments Applicant's arguments filed 07/21/2026 have been fully considered but they are not persuasive. Applicant’s arguments: Rejection Under 35 USC §102 and §103 (Summary of pages 6- 8, Examiner emphasis – Bold). …The rejection is respectfully traversed. Applicant submits that the prior art of record fails to teach or suggest an in-vehicle device including a first processing unit, a second processing unit, and a physical layer communication unit, wherein communication data generated by the first processing unit is output from the first processing unit to the second processing unit via the first upper layer communication unit, and the communication data received by the second processing unit is output from the second processing unit to the physical layer communication unit via the second upper layer communication unit. Similar arguments may be made with respect to claims 9 and 10. …Admittedly, Li does disclose two processor modules that communicate with one another and an Ethernet interface located on the second processor module, the Examiner's rationale relies on treating Li's processor-to-processor interfaces and internal communication structures as satisfying the claimed upper layer communication units and the specific layered connection arrangement recited in claim 1. However, Li does not clearly or explicitly describe the processors being connected via upper-layer communication units in the serial, layered fashion as required by amended claims 1, 9 and 10 but rather discloses a more general gateway architecture in which the processors interact through hardware interfaces and internal connections. Response: Examiner respectfully disagrees. See updated rejection of claim 1. In particular, Li, fig. 2, [0065] discloses a vehicle-mounted Ethernet gateway 100 which includes a first processing module 7 and a second processor unit 8. The first processor module 7 is provided with a first independent interface 9, and the second processor module 8 includes a second interface 10. Data generated by the first processing unit (fig. 2, (7)) is output from the first processing unit (fig. 2, (7)) to the second processing unit (fig. 2, (8)) via the first upper layer communication unit/first independent interface 9 that is connected to the second processor unit 8 via the second independent interface 10. Furthermore, the second processor 8 which includes an upper layer communication unit that connects to a physical layer communication unit such as an Ethernet interface 1/100BASE-TX which enables connection to an upper computer 200. Data received by the second processing unit (fig. 2, (8)) is output from the second processing unit (fig. 2, (8)) to the physical layer communication unit (Ethernet interface 1/100BASE-TX) via the second upper layer communication unit (Ethernet interface 1). The Ethernet gateway also includes a function configuration module 5 which connects the gateway through the physical interface to the upper computer 200). Therefore, Li discloses all of the limitations of claim 1 as currently amended. Claim Rejections - 35 USC § 102 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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claim(s) 1-2 is/are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Li et al. (CN 114545906 A), English translation attached. Regarding claim 1, Li an in-vehicle device (fig. 1, in-vehicle Ethernet gateway 100) to be connected to an in-vehicle network installed in a vehicle, the in-vehicle device (Li, fig. 1, [0033] discloses a central communication node in-vehicle Ethernet gateway 100 installed in a vehicle and communication between the vehicle and the outside world by connecting to a remote information control unit) comprising: a first processing unit (Li, fig. 2, [0065] the vehicle-mounted Ethernet gateway 100 includes a first processing module 7); a second processing unit (fig. 2, 8) connected to the first processing unit (Li, fig. 2, [0065] the vehicle-mounted Ethernet gateway 100 includes a first processing module 7 and a second processor unit 8. The first processor module 7 is provided with a first independent interface 9, and the second processor module 8 includes a second interface 10. The first independent interface 9 and the second independent interface 10 connected, enabling the first processor module 7 and the second processor module 8 to interact with each other); and a physical layer communication unit (fig. 2, ( Ethernet interface 1 /100BASE-TX Interface) connected to the second processing unit (fig. 2, (8)) (Li, fig. 2, [0065] At least one physical layer communication unit such as an Ethernet interface 1/100BASE-TX is provided in the second processor module 8), wherein the first processing unit (fig. 2, (7)) includes a first upper layer communication unit (fig. 2, (9)) corresponding to a layer that is higher than the physical layer communication unit (Ethernet interface 1/100BASE-TX) (Li, [0065;0067] the first processing unit 7 of figure 2 includes a first upper layer communication unit (fig. 2, (9)) comprising a Control Area Network (CAN) controller that is higher than the physical layer communication unit (Ethernet interface 1/100BASE-TX)), wherein, the second processing unit (fig. 2, (8)) includes a second upper layer communication unit (fig. 2, (10)) corresponding to a layer that is higher than the physical layer communication unit (Ethernet interface 1/100BASE-TX) (Li, [0065;0067] the second processing unit 8 of figure 2 includes a second upper layer communication unit (fig. 2, (10)) comprising a Control Area Network (CAN) controller that is higher than the physical layer communication unit (Ethernet interface 1/100BASE-TX)), wherein communication data generated by the first processing unit (fig. 2, (7)) is output from the first processing unit (fig. 2, (7)) to the second processing unit (fig. 2, (8)) via the first upper layer communication unit (fig. 2, (9/10)), (Li, fig. 2, [0064-0066] the vehicle-mounted Ethernet gateway 100 includes a first processing module 7 and a second processor unit 8. The first processor module 7 is provided with a first independent interface 9, and the second processor module 8 includes a second interface 10. Data generated by the first processing unit (fig. 2, (7)) is output from the first processing unit (fig. 2, (7)) to the second processing unit (fig. 2, (8)) via the first upper layer communication unit/first independent interface 9 that is connected to the second processor unit 8 via the second independent interface 10), and wherein the communication data received by the second processing unit (fig. 2, (8)) is output from the second processing unit (fig. 2, (8)) to the physical layer communication unit (Ethernet interface 1/100BASE-TX) via the second upper layer communication unit (Ethernet interface 1) (Li, figs. 1 &2, [0062-0065] discloses a second processor 8 which includes an upper layer communication unit that connects to a physical layer communication unit such as an Ethernet interface 1/100BASE-TX which enables connection to an upper computer 200. Data received by the second processing unit (fig. 2, (8)) is output from the second processing unit (fig. 2, (8)) to the physical layer communication unit (Ethernet interface 1/100BASE-TX) via the second upper layer communication unit (Ethernet interface 1). The Ethernet gateway also includes a function configuration module 5 which connects the gateway through the physical interface to the upper computer 200). Regarding claim 2, Li discloses the in-vehicle device according to claim 1, wherein a processing performance of the first processing unit (Main microcontroller unit) is higher than a processing performance of the second processing unit (Ethernet switching chip) (Li [0018-0020] discloses the first processing unit as the main microcontroller which is a higher performance processor than the second processor unit which is a secondary microcontroller used for switching data frames. The first processor unit includes an Ethernet flashing module for flashing a vehicle Ethernet gateway, a communication matrix configuration module used for implementing different configurations in a Controller Area Network (CAN), while the second processor unit is disclosed as an Ethernet switching chip that is mainly responsible for forwarding Ethernet frames between ports based on Mac addresses). 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 (i.e., changing from AIA to pre-AIA ) 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. Claim(s) 3-4, 6-8 and 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (CN 114545906 A), English translation attached) in view of Park et al (US 2013/0345899 A1). Regarding claim 3, Li discloses the in-vehicle device according to claim 2, wherein the first processing unit executes a plurality of programs relating to control of the vehicle (Li, [0068-0069] the first processor module 7 is a main microcontroller unit (MCU) which is an integrated circuit such as a chip-level computer that can perform different combinations of control for different applications). Li did not explicitly disclose the second processing unit executes processing relating to selection of communication data to be outputted to the in-vehicle network, out of communication data generated by the first processing unit executing a program. Park discloses the second processing unit (second processor 210) executes processing relating to selection of communication data (Selecting/setting a driving mode) to be outputted to the in-vehicle network, out of communication data generated by the first processing unit executing a program (Park, fig. 7 [0109-0113], discloses a process of setting a driving mode. If a driving mode value is set to DRIVING_MODE_SPORT, the first processor 200 may output a message for changing the driving mode according to the set value to the second processor 210 via an inter-node communication (INC) interface module and a web application 202 may output a message, the second processor selects and sets the driving mode using a set command. After the driving mode have been successfully set, the second processor unit sends a "Setting driving mode command has been successfully sent to the vehicle bus" on the display unit 101 as a console.log function). One of ordinary skill would have been motivated to combine the teachings of Li, and Park because these teachings are from the same field of endeavor with respect to in-vehicle communication systems). Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Park into the device by Li, thereby enabling an in-vehicle information processor mounted in a vehicle to require a data processing method of utilizing data corresponding to a vehicle status such as drive mode, speed or fuel quantity of the vehicle, Park, [Abstract]. Regarding claim 4, Li discloses the in-vehicle device according to claim 1, but did not explicitly disclose wherein the first processing unit is provided with a plurality of first upper layer communication units, and the plurality of first upper layer communication units are connected to a bus connection circuit included in the second processing unit. Park discloses wherein the first processing unit (Infotainment Processor 200) is provided with a plurality of first upper layer communication units (Native Vehicle Device API and Web Vehicle Device API), and the plurality of first upper layer communication units are connected to a bus connection circuit (inter-node communication (INC) interface module) included in the second processing unit (Vehicle Processor 210) (Park, fig. 2, [0059-0067], discloses a plurality of upper layer communication units such as a Native Device API and Web Vehicle Device API are connecting the first processing unit to the second processor unit via (inter-node communication (INC) interface module) by connecting CAN Interaction Add-on located in each of the first and second processor units (200 and 210)). The motivation to combine is similar to that of claim 3. Regarding claim 6, Li and Park disclose the in-vehicle device according to claim of claim 4, wherein the second processing unit (second processor 210) includes a filter unit (A driving mode setting unit) that filters (select/set driving mode) the communication data outputted (output a driving mode message) via the bus connection circuit (inter-node communication (INC) interface module) from the first processing unit (fig. 2, 200), and the filter unit is interposed between the bus connection circuit and the second upper layer communication unit (Park [0111-0113] using driving mode values received from a first processor 200 via an inter-node communication (INC) interface module, a second processor 210 filters/select and sets a driving mode for a vehicle by using a set command. After the driving mode have been successfully set, the second processor unit sends a "Setting driving mode command has been successfully sent to the vehicle bus" on the display unit 101 as a console.log function). The motivation to combine is similar to that of claim 4. Regarding claim 7, Li and Park disclose the in-vehicle device according to claim 6, wherein the second processing unit (210) acquires a control signal (driving mode values) outputted from the first processing unit (200) and performs filtering (selecting a driving mode value) by the filter unit (selection button) in accordance with the acquired control signal (in accordance with a desired driving mode) (Park [0111-0113] a second processor unit acquires driving mode values from a first processor unit. The second processor unit filters/selects a driving mode corresponding to the desired driving mode and sets the driving mode using a set command. After the driving mode have been successfully set, the second processor unit sends a "Setting driving mode command has been successfully sent to the vehicle bus" on the display unit 101 as a console.log function). The motivation to combine is similar to that of claim 4. Regarding claim 8, Li and Park disclose the in-vehicle device according to claim 7, wherein each of the first processing unit (a first processing module 7) and the second processing unit (a second processor unit 8) includes a control signal interface (a first and second independent interfaces (9 and 10)) for transmitting and receiving the control signal (Li, fig. 2, [0065] the vehicle-mounted Ethernet gateway 100 includes a first processing module 7 and a second processor unit 8. The first processor module 7 is provided with a first independent interface 9, and the second processor module 8 includes a second interface 10. The first independent interface 9 and the second independent interface 10 connected, enabling the first processor module 7 and the second processor module 8 to interact with each other). The motivation to combine is similar to that of claim 4. Regarding claim 9, Li discloses a program (application software) that causes a computer (fig. 1, in-vehicle Ethernet gateway 100) to execute a process, the computer being connected to an in-vehicle network installed in a vehicle and including: a first processing unit (a first processing module 7); a second processing unit (a second processor unit 8) connected to the first processing unit (Li, fig. 2, [0065] the vehicle-mounted Ethernet gateway 100 includes a first processing module 7 and a second processor unit 8. The first processor module 7 is provided with a first independent interface 9, and the second processor module 8 includes a second interface 10. The first independent interface 9 and the second independent interface 10 connected, enabling the first processor module 7 and the second processor module 8 to interact with each other), and a physical layer communication unit (fig. 2, (1)) ( Ethernet interface 1 /100BASE-TX Interface) connected to the second processing unit (fig. 2, (8)) (Li, fig. 2, [0065] At least one physical layer communication unit such as an Ethernet interface 1/100BASE-TX is provided in the second processor module 8), wherein the first processing unit (fig. 2, (7)) includes a first upper layer communication unit (fig. 2, (9)) corresponding to a layer that is higher than the physical layer communication unit (Ethernet interface 1/100BASE-TX) (Li, [0065;0067] the first processing unit 7 of figure 2 includes a first upper layer communication unit (fig. 2, (9)) comprising a Control Area Network (CAN) controller that is higher than the physical layer communication unit (Ethernet interface 1/100BASE-TX)), wherein, the second processing unit (fig. 2, (8)) includes a second upper layer communication unit (fig. 2, (10)) corresponding to a layer that is higher than the physical layer communication unit (Ethernet interface 1/100BASE-TX) (Li, [0065;0067] the second processing unit 8 of figure 2 includes a second upper layer communication unit (fig. 2, (10)) comprising a Control Area Network (CAN) controller that is higher than the physical layer communication unit (Ethernet interface 1/100BASE-TX)), wherein communication data generated by the first processing unit (fig. 2, (7)) is output from the first processing unit (fig. 2, (7)) to the second processing unit (fig. 2, (8)) via the first upper layer communication unit (fig. 2, (9/10)), (Li, fig. 2, [0065] the vehicle-mounted Ethernet gateway 100 includes a first processing module 7 and a second processor unit 8. The first processor module 7 is provided with a first independent interface 9, and the second processor module 8 includes a second interface 10. Data generated by the first processing unit (fig. 2, (7)) is output from the first processing unit (fig. 2, (7)) to the second processing unit (fig. 2, (8)) via the first upper layer communication unit/first independent interface 9 that is connected to the second processor unit 8 via the second independent interface 10), and wherein the communication data received by the second processing unit (fig. 2, (8)) is output from the second processing unit (fig. 2, (8)) to the physical layer communication unit (Ethernet interface 1/100BASE-TX) via the second upper layer communication unit (Ethernet interface 1) (Li, figs. 1 &2, [0063-0065] discloses a second processor 8 which includes an upper layer communication unit that connects to a physical layer communication unit such as an Ethernet interface 1/100BASE-TX which enables connection to an upper computer 200. Data received by the second processing unit (fig. 2, (8)) is output from the second processing unit (fig. 2, (8)) to the physical layer communication unit (Ethernet interface 1/100BASE-TX) via the second upper layer communication unit (Ethernet interface 1). The Ethernet gateway also includes a function configuration module 5 which connects the gateway through the physical interface to the upper computer 200), the process comprising: causing the first processing unit (first processor module 7) to execute a plurality of programs (different applications for controlling the vehicle) relating to control of the vehicle (Li, [0068-0069] the first processor module 7 is a main microcontroller unit (MCU) which is an integrated circuit such as a chip-level computer that can perform different combinations of control for different applications), and outputting (outputting control data), via the first upper layer communication unit (fig. 2, (9)), communication data generated (control data generated from processing different control applications) by execution of the programs (execution of control programs) to the second processing unit (fig. 2, (8)) (Li, figs. 1 &2, [0065-0069] the first processor module 7 is a main microcontroller unit (MCU) which includes a first upper layer communication unit 9 that is interconnected to an upper layer communication unit 10 of the second processor unit 8, to enable exchange of data between the first and second processors. The first processor unit (MCU) is an integrated circuit such as a chip-level computer that can perform different combinations of control for different applications to generate control data/instructions that are provided to the second processor via the interconnection of the upper layer communication units 9 and 10 in the respective processors) and causing the second processing unit to receive the communication data outputted from the first processing unit (Li, figs. 1 &2, [0065-0069] the first processor module 7 is a main microcontroller unit (MCU) which includes a first upper layer communication unit 9 that is interconnected to an upper layer communication unit 10 of the second processor unit 8, to enable exchange of data between the first and second processors. The first processor unit (MCU) is an integrated circuit such as a chip-level computer that can perform different combinations of control for different applications to generate control data/instructions that are provided to the second processor via the interconnection of the upper layer communication units 9 and 10 in the respective processors). Li did not explicitly disclose selecting communication data to be outputted to the in-vehicle network out of the received communication data. Park discloses selecting communication data to be outputted to the in-vehicle network out of the received communication data (Park, fig. 7 [0109-0113], discloses a process of setting a driving mode. If a driving mode value is set to DRIVING_MODE_SPORT, the first processor 200 may output a control message for changing the driving mode according to a set of values to the second processor 210 via an inter-node communication (INC) interface module, the second processor selects and sets the driving mode using a set command. After the driving mode have been successfully set, the second processor unit sends a "Setting driving mode command has been successfully” sent to the vehicle bus for display on the display unit 101 as a console.log function). The motivation to combine is similar to that of claim 3. Regarding claim 10, the claim is rejected with rational similar to that of claim 9. Claim(s) 5 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (CN 114545906 A), English translation attached) in view of Park et al (US 2013/0345899 A1), further in view of Van Dijk et al. (US 2023/0216705 A1). Regarding claim 5, Li and Park disclose the in-vehicle device according to claim 4, wherein the first processing unit executes a plurality of programs with different safety levels defined by ASIL (Li, [0068-0069] the first processor module 7 as a main microcontroller unit (MCU) which is an integrated circuit such as a chip-level computer that can perform different combinations of control for different applications. The MCU may be a model TC397XX, with 6-core, functional safety ASILD level and supports Ethernet /CANFD/CAN/LIN communication)). Li and Park did not explicitly disclose the plurality of first upper layer communication units are classified according to safety levels of the programs. Van Dijk discloses the plurality of first upper layer communication units are classified according to safety levels of the programs (Van Dijk [0019;0024 ] discloses solutions for protecting data integrity in sections of an in vehicle network by providing an efficient and cost-effective end-to-end protection of data communication channels to different applications. The integrity of data communication channels may be classified using an Automotive Safety Integrity Level (ASIL) standard of levels introduced in ISO 26262 where ASIL-D represents a channel for transmitting data requiring a high level of safety/integrity). One of ordinary skill would have been motivated to combine the teachings of Li, Park and Van Dijk because these teachings are from the same field of endeavor with respect to in-vehicle communication systems). Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Van Dijk into the device by Li and Park thereby enabling an operation for protecting the integrity of data communications between networked electronic control units, Van Dijk, [Abstract]. Regarding claim 11, Li, Park and Van Dijk disclose the in-vehicle device according to claim 5, wherein the second processing unit (second processor 210) includes a filter unit (A driving mode setting unit) that filters (select/set driving mode) the communication data outputted (output a driving mode message) via the bus connection circuit (inter-node communication (INC) interface module) from the first processing unit (fig. 2, 200), and the filter unit is interposed between the bus connection circuit and the second upper layer communication unit (Park [0111-0113] using driving mode values received from a first processor 200 via an inter-node communication (INC) interface module, a second processor 210 filters/select and sets a driving mode for a vehicle by using a set command. After the driving mode have been successfully set, the second processor unit sends a "Setting driving mode command has been successfully sent to the vehicle bus" on the display unit 101 as a console.log function). The motivation to combine is similar to that of claim 5. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following publications show the state of the art related to in-vehicle communication systems. Park et al. (US 2013/0345899 A1) Nakadai et al. (US 2016/0055850 A1) Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 DIXON F DABIPI whose telephone number is (571)270-3673. The examiner can normally be reached on Monday - Friday from 9:00 am to 5:00 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher L Parry, can be reached at telephone number 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice. /D.F.D/ Examiner, Art Unit 2451 /Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Read full office action

Prosecution Timeline

Oct 23, 2024
Application Filed
Apr 24, 2026
Non-Final Rejection mailed — §102, §103
Jul 21, 2026
Response Filed
Oct 07, 2026
Final Rejection mailed — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12771571
PRIVATE ALIAS ENDPOINTS FOR ISOLATED VIRTUAL NETWORKS
3y 1m to grant Granted Oct 20, 2026
Patent 12764057
BACKUP SERVICE FUNCTION NOTIFICATION AND SYNCHRONIZATION
4y 11m to grant Granted Oct 13, 2026
Patent 12756657
HIGHLY AVAILABLE DATA-PROCESSING NETWORK FUNCTIONS FOR RADIO-BASED NETWORKS
3y 3m to grant Granted Oct 06, 2026
Patent 12750158
EXTENDED REALITY AGGREGATOR LOW LATENCY ROBUST ERROR RECOVERY
3y 2m to grant Granted Sep 29, 2026
Patent 12701072
SERVICE AWARE ROUTING USING NETWORK INTERFACE CARDS HAVING PROCESSING UNITS
4y 1m to grant Granted Aug 04, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
78%
Grant Probability
93%
With Interview (+15.2%)
2y 11m (~11m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 254 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month