Prosecution Insights
Last updated: April 19, 2026
Application No. 18/356,397

METHOD AND SYSTEM FOR ADDITION OF ASSURANCE INFORMATION TO V2X MESSAGING

Final Rejection §103
Filed
Jul 21, 2023
Examiner
PATEL, HARESH N
Art Unit
2496
Tech Center
2400 — Computer Networks
Assignee
Blackberry Limited
OA Round
4 (Final)
78%
Grant Probability
Favorable
5-6
OA Rounds
3y 1m
To Grant
99%
With Interview

Examiner Intelligence

Grants 78% — above average
78%
Career Allow Rate
632 granted / 815 resolved
+19.5% vs TC avg
Strong +22% interview lift
Without
With
+22.1%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
43 currently pending
Career history
858
Total Applications
across all art units

Statute-Specific Performance

§101
15.1%
-24.9% vs TC avg
§103
41.6%
+1.6% vs TC avg
§102
19.7%
-20.3% vs TC avg
§112
12.8%
-27.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 815 resolved cases

Office Action

§103
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 . DETAILED ACTION Status of Claims Claims 1-3, 5-12, 14-20 are subject to examination. Claim 4, 13 is cancelled. Drawings Figures dated 8/5/25 is acknowledged. 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 of this title, 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. Claim(s) 1, 10, 19, is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM et al., WO 2018230833 A1, 2018-12-20 in view of GHOSH et al., 20200145188 and CHENG, CN 110879876 A and YANG et al., WO 2019160176 A1. Referring to claim(s) 1, 10, 19, Kim substantially discloses, a method at an Intelligent Transportation System (ITS) Entity, the method comprising: An Intelligent Transportation System (ITS) Entity, the ITS Entity comprising: a processor; and a communications subsystem, wherein the ITS Entity is configured to, A non-transitory computer readable medium for storing instruction code, which, when executed by a processor of an Intelligent Transportation System (ITS) Entity, cause the ITS Entity to (PA can specify TLM. In particular, the PA may designate and authorize the TLM and the Central Point of Contact (CPOC) to operate within the ITS trust system. The PA may determine if the root CA is trustworthy and may approve / remove the root CA operation within the ITS trusted domain by notifying the TLM about approved / retired root CA certificates. In other words, the PA can authorize root CA operation and verify that the TLM can trust the root CA, last para, page 12 the security lifecycle may include an initial ITS station configuration phase, a registration phase, an authorization phase, an operation and maintenance phase, and an expiration phase of life during manufacture. In this specification, the initial ITS station configuration step may correspond to a before initialization step / state, the registration step may correspond to an initialized and unenrolled step / state, and the authorization step may be a registration step. And may be referred to as an enrolled and unauthorized phase / status, the operation and maintenance phase may correspond to an authorized for service phase / status, and the expiration phase of life is expiration of life. (end of life) may correspond to a phase / state, 2nd last para, page 13. sending a request for an Authorization Ticket or an Authorization certificate to an Authorization Authority ( In the authorization phase, the ITS station may request the AT from the AA. The AA is an entity responsible for issuing and monitoring the use of Authorization Tickets (ATs), which can provide authoritative proof that a V2X communication device can use a particular V2X service. Such AA may issue an AT. The V2X communication device may have an AT, 2nd last para, page 5 the V2X communication system may be a Root Certificate Authority (root CA), Enrollment Authority (EA), Authorization Authority (AA) and / or at least one V2X communication device. It may include, 3rd last para, page 12 receiving a response from the Authorization Authority, the response including the Authorization Ticket or the Authorization certificate ( the V2X communication device may request an EC and obtain an EC from the EA. Also, the V2X communication device may request an AT (PC) from AA and obtain an AT from AA. Also, the V2X communication device may transmit and receive a V2X message. For example, the V2X communication device may communicate a trust message with another V2X communication device using the EC and the AT. The V2X communication device can also forward the received V2X message to another V2X communication device. A V2X communication device that forwards to another V2X communication device is referred to as a relaying V2X communication device, last para, page 5. containing a safety assurance indication comprising information, The AA is an entity responsible for issuing and monitoring the use of Authorization Tickets (ATs), which can provide authoritative proof that a V2X communication device can use a particular V2X service, 8th para, page 5 A functional entities of the ITS security architecture and the relationships that exist between them and the ITS communication layer. In FIG. 10, the security layer is shown as a vertical layer adjacent to the ITS communication layer, but in fact, since the security service is provided on a layer by layer basis, the security layer can be subdivided into ITS layers. Such a security service may be provided on a layer basis in such a manner that each of the security services operates in one or several ITS architecture layers or in a security management layer. As shown in FIG. 10, functional entities of the ITS security architecture and the ITS communication layers may perform communication, last fifth para, page 12 sending a message to a second ITS entity, the message containing the information within the Authorization Ticket or Authorization certificate issued by the Authorization Authority. A V2X communication device that forwards to another V2X communication device is referred to as a relaying V2X communication device, last para, page 5. When in the “service authorization” state, the ITS station may have a set of ATs that allow transmission of signed messages to any other ITS station. 8th para, page 5 The entity may have an OBE Registration Certificate (EC), Anonymous Certificate (PC), and / or Identification Certificate (IC). The entity can use this EC to request a PC and / or IC from the AA. each EC may have at least one provider service ID (PSID), the owner's identity, IC can be used for authentication in V2I applications. The IC has a provisioning process similar to that of a PC, but can have different PSIDs and parameters. 3rd para page 10 the V2X communication device may communicate a trust message with another V2X communication device using the EC and the AT. The V2X communication device can also forward the received V2X message to another V2X communication device, last para, page 5. When in the “service authorization” state, the ITS station may have a set of ATs that allow transmission of signed messages to any other ITS station. 3rd para, page 14. Kim does not specifically mention about, which is well-known in the art, which GHOSH discloses, the safety assurance indication providing that at least one of hardware and software at the entity is certified to a safety assurance level, at least one of functional safety of the entity and a safety of an of the entity ( [0017] Furthermore, as the encryption is implemented in a FUSA manner, the system may be certified automotive safety integrity level (D), which requires FUSA execution of encryption operations. It is noted that ASIL D certification may be required for various automotive applications [0018] FIG. 1 to provide FUSA encryption for messages communicated over V2X network 140. [0012] In particular, the present disclosure provides an encryption system that is FUSA compliant. The disclosed FUSA encryption system can be implemented in hardware circuitry arranged to execute the encryption operations. Furthermore, the disclosure FUSA encryption system can be implemented in software, such as, at the application level in a V2X communication device. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known certified entity and functionality of the entity. One of ordinary skilled in the art would readily know that "Certified software" itself refers to software that has been officially recognized and approved by a third-party organization or entity, demonstrating compliance with specific standards, regulations, or quality requirements. This process ensures that the software meets certain criteria, offering assurance to users regarding its reliability, safety, or functionality. Hence, these limitations would enable implementing reliability, safety, or functionality with the entity, para 12. Kim and GHOSH do not specifically mention about, which is well-known in the art, which Cheng, CN 110879876 A discloses, to an indicated value, safety assurance indication within Authorization Ticket or Authorization certificate (expiry date, issuer device may generate authorization certificate in the trusted execution environment of the issuer device, and the value of each parameter of the authorization certificate set value of corresponding parameter in the authorization certificate parameter information. It should be understood that the authorization certificate may include parameter information of each parameter included in the authorization certificate parameter information. For example, the authorization certificate may include a publisher user identification, certificate identifier and the middleman user identifier, authorization certificate may also include an encryption algorithm identifier, encryption key, decryption algorithm identifier and a decryption key. It should be understood that the authorization certificate comprises the various parameters, in practice the authorization certificate may also include at least one of the following: a certificate type identifier, check code, certificate failure time, certificate fixed byte number and authorized content information of the configuration information, last para, page 9 apparatus generates corresponding to the target digital asset of the digital assets ciphertext, the authorization certificate ciphertext and witness information cipher text, and sends to the device, abstract) Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known safety assurance indication within Authorization Ticket or Authorization certificate. One of ordinary skilled in the art would readily know that "Certified software" itself refers to software that has been officially recognized and approved by a third-party organization or entity, demonstrating compliance with specific standards, regulations, or quality requirements. This process ensures that the software meets certain criteria, offering assurance to users regarding its reliability, safety, or functionality. Hence, these limitations would enable implementing reliability, safety, or functionality with the entity. The indication with the value of the certificate/ticket would enable providing information and communicating the information that is needed for the implementation of the safety/ functionality of the entity, abstract. Kim, GHOSH, CHENG, CN 110879876 A, do not specifically mention about, “a transmitter” “intended functionality”, “the indication is associated with PSID and SSP, wherein the PSID and the SSP indicate an application to which the safety assurance indication is applicable As demonstrated above, Kim in view of Ghoshnd Cheng, CN 110879876 A shows that the certificate/ticket can have lots of indications in the certificate/ticket itself. Such indications to indicate “a transmitter” “intended functionality” using the above taught certificate/ticket, is a design choice. For example, other inventors can merely add one more indication in the certificate/ticket and would overcome the claimed subject matter of this application. For example, further inventors can merely add further one more indication in the certificate/ticket and would overcome the claimed subject matter of this application. Yang disclose these limitations, Security profile: Indicate the security service profile / level to apply. ITS-AID length: Indicates the length of the value of the ITS-AID field. ITS-AID: indicates the ID of the application. Security permissions length: Indicates the length of the value of the Security permissions field. Security permissions: Service Specific Permissions (SSPs) associated with ITS-AID Security context information: Provides information for selecting security protocol properties. Security target ID list length: Indicates the length of the value of the Security target ID list field. Security target ID list: Provides a list of target IDs used by security entities, middle portion, page 21 Smart cars connect drivers, vehicles, and traffic infrastructure to provide a variety of customized mobility services, as well as traditional vehicle technologies such as traffic safety and complexity. This connectivity can be implemented using Vehicle to Everything (V2X) communication technology, 1st para, page 2. Application layer: The application layer may implement and support various use cases. For example, the application may provide road safety, efficient traffic information, and other application information. The application layer can classify and define ITS applications and provide services to end vehicles / users / infrastructures through lower layers. The application can be defined / applied by use-case, or the use-case can be grouped as road-safety, traffic efficiency, local service, infotainment to define / apply It may be. As an embodiment, application classification, use-case, etc. may be updated when new application scenarios occur. Layer management can manage and service information related to the operation and security of the application layer. Information and services are communicated and shared in both directions through the interface between management entity and application layer (MAMA) and the interface between security entity and ITS-S applications (SA) or Service Access Points (eg MA-SAP, SA-SAP) 3rd para, page 5 FCW technology is a V2V safety communication technology that warns of a collision with a preceding vehicle. If a vehicle with a V2X communication device stops suddenly or stops in an accident, it can send an FCW safety message to prevent subsequent vehicle collisions. Subsequent vehicles may receive FCW messages and warn the driver or perform controls such as speed reduction or lane change. 5th para, page 8 The network / transport layer of FIG. 5 may send a vehicle safety message, The PSID field is a provider service identifier and may be allocated according to an application in a higher layer. The PSID field helps the receiver determine the appropriate higher layer. 6th para, page 9 Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known providing indication associated with PSID and SSP. One of ordinary skilled in the art would readily know that in computer science and networking, A Public Service Identifier (PSID) is a unique code with different meanings depending on the context, most commonly referring to an ID for emergency responders (tracking training/certs). It can also mean an identifier for Intelligent Transportation Systems (ITS) applications in vehicle-to-vehicle communication. Service-specific permissions are granular access controls defining what users or applications can do within particular services. Hence, the associated PSID would enable responders to track information, and the SSP would enable defining permission for the access control associated with the service, 3rd para, page 5. Claim(s) 2, 11, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of GHOSH, CHENG, CN 110879876 A, Yang, and Alrabady et al, 20140075517. Referring to claim(s) 2, 11, 20, Kim, GHOSH, CHENG, CN 110879876 A does not specifically mention about, which is well-known in the art, which Alrabady discloses, providing service parameters for the ITS entity [0009] allow developmental software to be installed on a secure production controller without having to authenticate the software. The method includes requesting information from the controller and creating an information ticket in the controller in response to the request that identifies the controller. The information ticket is sent to a secure server that creates an authorization ticket that identifies the controller from the information ticket and creates a security code for the ticket. The authorization ticket is presented to the controller and if the security code is verified by the controller, the controller enables development software to be installed [0029] When the engineer 94 wishes to use the controller 92 (e.g., to program into the controller unsigned software and/or calibration files) the engineer 94, through the programming tool, will send a request for controller information. When the controller 92 receives the request on the line 98, it proceeds to create a controller information ticket represented by line 100 and that ticket is transferred to the engineer 94 through the programming tool on line 102. The information ticket is a message that can include any unique information that identifies that particular ECU, such as module ID number, component serial number, or manufacturing traceability. [0030] Based on the information provided in the controller information ticket, the server 96 creates an authorization ticket, represented by line 108, where the authorization ticket is signed by the server 96 and can be a file header with a specific module ID. [0031] FIG. 5 is a representation of an authorization ticket 120 of the type discussed herein that allows the controller 92 to validate that the engineer 94 is an authorized user. The server 96 generates the ticket 120 that includes the controller information at section 122 identifying the controller 92 and including the answer to the challenge question so that the authorization ticket 120 is only valid for a single specific controller 92. At section 124, the authorization ticket 120 may include a parameter that describes the purpose of why the engineer 94 wants to update the controller 92, such as by-passing the signature validation for the software file and/or calibration part, unlocking the controller 92, replacing a signature validation key, updating special parameters, etc. At section 126, the authorization ticket 120 may include a validity code that defines the life period of the ticket 120, such as a one time use, an ignition cycle, etc. At section 128, the ticket 120 may include signed information, such as a signature value, signer ID, etc. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known providing service parameters for the ITS entity. One of ordinary skilled in the art would readily know that "service parameters" refer to the settings and specifications that define how a service operates and interacts with other systems. These parameters dictate various aspects of the service, such as its capacity, resource allocation, and behavior. This process ensures that the software meets certain criteria, offering service to users regarding its reliability, safety, or functionality. Hence, these limitations would enable using the parameter to implement safety, or functionality with the entity, para 31. Claim(s) 3, 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of GHOSH, CHENG and Yang. Referring to claim(s) 3, 12, Kim discloses, a method at an Intelligent Transportation System (ITS) Entity, the method comprising: (PA can specify TLM. In particular, the PA may designate and authorize the TLM and the Central Point of Contact (CPOC) to operate within the ITS trust system. The PA may determine if the root CA is trustworthy and may approve / remove the root CA operation within the ITS trusted domain by notifying the TLM about approved / retired root CA certificates. In other words, the PA can authorize root CA operation and verify that the TLM can trust the root CA, last para, page 12 the security lifecycle may include an initial ITS station configuration phase, a registration phase, an authorization phase, an operation and maintenance phase, and an expiration phase of life during manufacture. In this specification, the initial ITS station configuration step may correspond to a before initialization step / state, the registration step may correspond to an initialized and unenrolled step / state, and the authorization step may be a registration step. And may be referred to as an enrolled and unauthorized phase / status, the operation and maintenance phase may correspond to an authorized for service phase / status, and the expiration phase of life is expiration of life. (end of life) may correspond to a phase / state, 2nd last para, page 13. sending a request for an Authorization Ticket or an Authorization certificate to an Authorization Authority ( In the authorization phase, the ITS station may request the AT from the AA. The AA is an entity responsible for issuing and monitoring the use of Authorization Tickets (ATs), which can provide authoritative proof that a V2X communication device can use a particular V2X service. Such AA may issue an AT. The V2X communication device may have an AT, 2nd last para, page 5 the V2X communication system may be a Root Certificate Authority (root CA), Enrollment Authority (EA), Authorization Authority (AA) and / or at least one V2X communication device. It may include, 3rd last para, page 12 receiving a response from the Authorization Authority, the response including the Authorization Ticket or the Authorization certificate ( the V2X communication device may request an EC and obtain an EC from the EA. Also, the V2X communication device may request an AT (PC) from AA and obtain an AT from AA. Also, the V2X communication device may transmit and receive a V2X message. For example, the V2X communication device may communicate a trust message with another V2X communication device using the EC and the AT. The V2X communication device can also forward the received V2X message to another V2X communication device. A V2X communication device that forwards to another V2X communication device is referred to as a relaying V2X communication device, last para, page 5. containing a safety assurance indication comprising information, The AA is an entity responsible for issuing and monitoring the use of Authorization Tickets (ATs), which can provide authoritative proof that a V2X communication device can use a particular V2X service, 8th para, page 5 A functional entities of the ITS security architecture and the relationships that exist between them and the ITS communication layer. In FIG. 10, the security layer is shown as a vertical layer adjacent to the ITS communication layer, but in fact, since the security service is provided on a layer by layer basis, the security layer can be subdivided into ITS layers. Such a security service may be provided on a layer basis in such a manner that each of the security services operates in one or several ITS architecture layers or in a security management layer. As shown in FIG. 10, functional entities of the ITS security architecture and the ITS communication layers may perform communication, last fifth para, page 12 sending a message to a second ITS entity, the message containing the information within the Authorization Ticket or Authorization certificate issued by the Authorization Authority. A V2X communication device that forwards to another V2X communication device is referred to as a relaying V2X communication device, last para, page 5. When in the “service authorization” state, the ITS station may have a set of ATs that allow transmission of signed messages to any other ITS station. 8th para, page 5 The entity may have an OBE Registration Certificate (EC), Anonymous Certificate (PC), and / or Identification Certificate (IC). The entity can use this EC to request a PC and / or IC from the AA. each EC may have at least one provider service ID (PSID), the owner's identity, IC can be used for authentication in V2I applications. The IC has a provisioning process similar to that of a PC, but can have different PSIDs and parameters. 3rd para page 10 the V2X communication device may communicate a trust message with another V2X communication device using the EC and the AT. The V2X communication device can also forward the received V2X message to another V2X communication device, last para, page 5. When in the “service authorization” state, the ITS station may have a set of ATs that allow transmission of signed messages to any other ITS station. 3rd para, page 14. Kim does not specifically mention about, which is well-known in the art, which GHOSH discloses, the safety assurance indication providing that at least one of hardware and software at the entity is certified, at least one of functional safety of the entity and a safety of an of the entity ( [0060] The approval certificate 728 includes the public key PubAK 724 of the attestation key 722. Authorization certificate 728 may indicate that attestation key 722 is used for software attestation and may be communicated to verifier 702. A verifier is any entity that wishes to verify the attestation of secure container 708, for example, verifier 702 desires that secure computation be performed inside secure container 708. Can be Verifier 702 may inspect the approval certificate using PubRK 732 to verify the integrity and the source of the approval certificate. The verifier may also extract PubAK 724 from the approval certificate. The authorization certificate indicates that the attestation key 722 is used only to provide an attestation signature, and that the private key PrivateAK 726 of the attestation key 722 is stored in the storage of the tamper-resistant hardware 730. It may be associated with a certification policy that may require that it be maintained exclusively in a storage device that is separate from the generally accessible computer memory. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known certified entity and functionality of the entity. One of ordinary skilled in the art would readily know that "Certified software" itself refers to software that has been officially recognized and approved by a third-party organization or entity, demonstrating compliance with specific standards, regulations, or quality requirements. This process ensures that the software meets certain criteria, offering assurance to users regarding its reliability, safety, or functionality. Hence, these limitations would enable implementing reliability, safety, or functionality with the entity, para 60. Kim and GHOSH do not specifically mention about, which is well-known in the art, which Cheng, discloses, to an indicated value, safety assurance indication within Authorization Ticket or Authorization certificate (expiry date, issuer device may generate authorization certificate in the trusted execution environment of the issuer device, and the value of each parameter of the authorization certificate set value of corresponding parameter in the authorization certificate parameter information. It should be understood that the authorization certificate may include parameter information of each parameter included in the authorization certificate parameter information. For example, the authorization certificate may include a publisher user identification, certificate identifier and the middleman user identifier, authorization certificate may also include an encryption algorithm identifier, encryption key, decryption algorithm identifier and a decryption key. It should be understood that the authorization certificate comprises the various parameters, in practice the authorization certificate may also include at least one of the following: a certificate type identifier, check code, certificate failure time, certificate fixed byte number and authorized content information of the configuration information, last para, page 9 apparatus generates corresponding to the target digital asset of the digital assets ciphertext, the authorization certificate ciphertext and witness information cipher text, and sends to the device, abstract) Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known safety assurance indication within Authorization Ticket or Authorization certificate. One of ordinary skilled in the art would readily know that "Certified software" itself refers to software that has been officially recognized and approved by a third-party organization or entity, demonstrating compliance with specific standards, regulations, or quality requirements. This process ensures that the software meets certain criteria, offering assurance to users regarding its reliability, safety, or functionality. Hence, these limitations would enable implementing reliability, safety, or functionality with the entity. The indication with the value of the certificate/ticket would enable providing information and communicating the information that is needed for the implementation of the safety/ functionality of the entity, abstract. Kim, GHOSH, CHENG, CN 110879876 A, do not specifically mention about, which Kim 2 discloses wherein: when the safety assurance indication is regarding the functional safety of the transmitter of the ITS entity, the safety assurance indication is an aggregation of a functional safety assurance level indication, 2nd last para, page 4, and at least one of; a Safety of the Intended Function assurance level indication, lines 1-20, page 9; and a cybersecurity assurance level indication; and when the safety assurance indication is regarding the safety of the intended functionality of the second ITS entity, the safety assurance indication is an aggregation of a Safety of the Intended Functionality assurance level indication and at least one of: the functional safety assurance level indication and a cybersecurity assurance level indication, 3rd last para, page 2. One of ordinary skilled in the art would readily know what these indications are used for. The usage of these indications is not novel but had been use for lot many years prior to the effective filling date of this application. As demonstrated above, Kim in view of Ghoshnd Cheng, CN 110879876 A shows that the certificate/ticket can have lots of indications in the certificate/ticket itself. Such indications to indicate these indications of claim 3 using the above taught certificate/ticket, is a design choice. One of ordinary skilled in art would readily know that having information for the indications in the certificate/ticket is well-known and expected in the art (as cited in the above rejections). For example, other inventors can merely add one more indication in the certificate/ticket and would overcome the claimed subject matter of this application. For example, further inventors can merely add further one more indication in the certificate/ticket and would overcome the claimed subject matter of this application. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known providing the claimed indications. One of ordinary skilled in the art would readily know that in computer science and networking, an octet refers to a sequence of eight bits It's essentially a unit of data that is often used to represent a character or small piece of data. While the term "byte" is commonly used for 8-bit units, octet is preferred in situations where there might be ambiguity, as "byte" has historically had different sizes depending on the system. Hence, the above taught certificate/ticket would enable using lots of sequence of eight bits for communicating lots of indications to another device. Claim(s) 5, 14, is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of GHOSH, CHENG, CN 110879876 A, Yang and TS 103 301 - V1.1.1 - Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Facilities layer protocols and communication requirements for infrastructure services, 2016. Referring to claim(s) 5, 14, Yang discloses, wherein the safety assurance indication for Service Specific Permissions (SSPs), as rejected in claim 1. Kim, GHOSH, CHENG, CN 110879876 A, Kim3 do not specifically mention about, Indication in encoded in octets, which is disclosed by TS 103 301 - V1.1.1 - Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Facilities layer protocols and communication requirements for infrastructure services table 9, 10, page 21, 2016 Hence, One of ordinary skilled in the art would readily know what encoding and octets is used for. Usage of octets is not novel rather had been use for lot many years prior to the effective filling date of this application. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known providing service parameters for the ITS entity. One of ordinary skilled in the art would readily know that in computer science and networking, an octet refers to a sequence of eight bits It's essentially a unit of data that is often used to represent a character or small piece of data. While the term "byte" is commonly used for 8-bit units, octet is preferred in situations where there might be ambiguity, as "byte" has historically had different sizes depending on the system. Hence, these limitations would enable using sequence of eight bits for communicating the indication to another device. Claim(s) 5, 14, is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of GHOSH, CHENG, CN 110879876 A, Yang and Official Notice. Referring to claim(s) 5, 14, Yang discloses, wherein the safety assurance indication for Service Specific Permissions (SSPs), as rejected in claim 1. Kim, GHOSH, CHENG, CN 110879876 A, Kim3 do not specifically mention about, Indication in encoded in octets. Hence, One of ordinary skilled in the art would readily know what encoding and octets is used for. Official Notice is taken that usage of octets is not novel rather had been use for lot many years prior to the effective filling date of this application. For example, WU, WO 2018096449 A1 discloses it. [0123] (The value of AT_CERT will be assigned by IANA. The Length field is two octets and indicates the length (in octet) of the AT_CERT attribute including the AT_CERT, Length, N, CP Length and CP. The N field indicate the next certificate payload. When N field is zero, it means the following certificate payload is the last one. Otherwise, a chain of certificates may be provided in which case there is one more certificate payload included in the same EAP message. The certificate payload, CP, length field indicates the length (in octet) of the certificate. The CP field includes one single DER-encoded X.509 certificate. If a chain of certificates is included in the attribute, N field, CP length field and CP field will be repeated but only the first CP holds the public key. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known providing service parameters for the ITS entity. One of ordinary skilled in the art would readily know that in computer science and networking, an octet refers to a sequence of eight bits It's essentially a unit of data that is often used to represent a character or small piece of data. While the term "byte" is commonly used for 8-bit units, octet is preferred in situations where there might be ambiguity, as "byte" has historically had different sizes depending on the system. Hence, these limitations would enable using sequence of eight bits for communicating the indication to another device. Claim(s) 6, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of GHOSH, CHENG, CN 110879876 A, Yang, and ALDANA et al., WO 2019010049 A1. Referring to claim(s) 6, 15, the safety assurance indication is cited in claim 1. Kim, GHOSH, CHENG, Kim 2 does not specifically mention about, which is well-known in the art, which ALDANA discloses, sending additional messages to the second ITS entity, wherein only messages conveying safety information include the indication [1843] to verify whether the certificate establishes the second communication device as a trusted source in vehicular radio communications by forwarding the certificate to a network. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known providing messages to the ITS entities. One of ordinary skilled in the art would readily know that communication of messages with the ITS entities would enable using the parameter in the messages to implement safety, or functionality with the entity, para 1843. Claim(s) 7, 16, is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of GHOSH, CHENG, CN 110879876 A, Yang and Official Notice. Referring to claim(s) 7, 16, when the safety assurance indication is within the Authorization ticket, the Authorization ticket includes defining: the functional safety of a transmitter of the ITS entity; and the safety of an intended functionality of the ITS entity, is met by the citations of claim 1, Kim, GHOSH, CHENG, Yang does not specifically mention about, explicit field, which is well-known in the art. One of ordinary skilled in the art would readily know what explicit field is, and for what it is used. Official Notice is taken that usage of explicit field is not novel and, rather it had been use for lot many years prior to the effective filling date of this application. For example, WU, WO 2018096449 A1 discloses it. [0123] (The value of AT_CERT will be assigned by IANA. The Length field is two octets and indicates the length (in octet) of the AT_CERT attribute including the AT_CERT, Length, N, CP Length and CP. The N field indicate the next certificate payload. When N field is zero, it means the following certificate payload is the last one. Otherwise, a chain of certificates may be provided in which case there is one more certificate payload included in the same EAP message. The certificate payload, CP, length field indicates the length (in octet) of the certificate. The CP field includes one single DER-encoded X.509 certificate. If a chain of certificates is included in the attribute, N field, CP length field and CP field will be repeated but only the first CP holds the public key. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known explicit for providing information / parameters for the ITS entity. One of ordinary skilled in the art would readily know that the field would enable communicating eight bits for information to represent a character or small piece of data. Hence, these limitations would enable using sequence of eight bits for communicating the indication to another device. Claim(s) 8, 17, is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of GHOSH, CHENG, Yang and Official Notice. Referring to claim(s) 8, 17, when the safety assurance indication is within the Authorization ticket, the Authorization ticket includes defining: the functional safety of a transmitter of the ITS entity; and the safety of an intended functionality of the ITS entity, is met by the citations of claim 1, Kim, GHOSH, CHENG, CN 110879876 A does not specifically mention about, the explicit field has enumerated, discrete values, which is well-known in the art. One of ordinary skilled in the art would readily know what explicit field and enumerated, discrete values is, and for what it is used. Official Notice is taken that usage of explicit field has enumerated, discrete values is not novel and, rather it had been use for lot many years prior to the effective filling date of this application. For example, Amin etal., US 20120079487 A1 discloses it. [0079] During a sending step 330, an embodiment sends a request's relative priority; the priority 230 may be sent by a process 122 or by a platform 128 acting on behalf of the process, for example. Priorities may be enumerated discrete values, for example. Sending step 330 may be accomplished using mechanisms such as those used in sending 326 requests. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known explicit for providing information / parameters for the ITS entity. One of ordinary skilled in the art would readily know that the field would enable communicating eight bits for information to represent a character or small piece of data. Hence, these limitations would enable using sequence of eight bits for communicating the indication to another device. Claim(s) 9, 18, is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of GHOSH, CHENG, CN 110879876 A, Kim 2 and Official Notice. Referring to claim(s) 9, 18, wherein the receiving comprises receiving a plurality of Authorization Tickets or Authorization certificates, wherein a subset of the Authorization Tickets or Authorization certificates contain the safety assurance indication, is met by the citations of claim 1, Kim, GHOSH, CHENG, CN 110879876 A, Kim 2 does not specifically mention about, the Authorization Ticket or Authorization certificate do not contain the safety assurance indication, which is well-known in the art. One of ordinary skilled in the art would readily know what the Authorization Ticket or Authorization certificate is and that it must not have the safety assurance indication. Official Notice is taken that usage of the Authorization Ticket or Authorization certificate do not contain the safety assurance indication is not novel and, rather a design choice of what would be included in it, and it had been use for lot many years prior to the effective filling date of this application. For example, D'Ercoli et al., US 20190312928 A1 [0036] With regard to FIG. 5, an illustrative broadcast 500 of a consensus block CBa is shown. In an embodiment, each of nodes 502, 504 may broadcast the same consensus block CBa. Node 506 may be faulty node not capable of transmitting or receiving a consensus block CBa. Node 508 may not be faulty and may receive the consensus block CBa from at least one or the nodes 502, 504. A malicious node (not shown) may generate and transmit a wrong consensus block CBw. However, as described below, as malicious node may not have access to a data certificate in the network and other nodes may determine that the consensus node CBw is wrong because of the incorrect certificate contained therein. In response to determining that the consensus node is wrong, the nodes 504, 506, 508 may ignore the consensus, thereby improving reliability and security. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known Authorization Ticket or Authorization certificate. The Authorization Tickets or Authorization certificate would not be used for safety assurance indication, but for what it is implemented for with the remote devices. Response to Arguments Remarks/Arguments filed 2/24/26, have been fully considered but they are not persuasive. Therefore, rejection of claims 1-3, 5-12, 14-20 is maintained. Regarding the concerned for the claims with amended limitations, the rejections are updated accordingly. Kim discloses, a method at an Intelligent Transportation System (ITS) Entity, the method comprising: An Intelligent Transportation System (ITS) Entity, the ITS Entity comprising: a processor; and a communications subsystem, wherein the ITS Entity is configured to, A non-transitory computer readable medium for storing instruction code, which, when executed by a processor of an Intelligent Transportation System (ITS) Entity, cause the ITS Entity to (PA can specify TLM. In particular, the PA may designate and authorize the TLM and the Central Point of Contact (CPOC) to operate within the ITS trust system. The PA may determine if the root CA is trustworthy and may approve / remove the root CA operation within the ITS trusted domain by notifying the TLM about approved / retired root CA certificates. In other words, the PA can authorize root CA operation and verify that the TLM can trust the root CA, last para, page 12 the security lifecycle may include an initial ITS station configuration phase, a registration phase, an authorization phase, an operation and maintenance phase, and an expiration phase of life during manufacture. In this specification, the initial ITS station configuration step may correspond to a before initialization step / state, the registration step may correspond to an initialized and unenrolled step / state, and the authorization step may be a registration step. And may be referred to as an enrolled and unauthorized phase / status, the operation and maintenance phase may correspond to an authorized for service phase / status, and the expiration phase of life is expiration of life. (end of life) may correspond to a phase / state, 2nd last para, page 13. sending a request for an Authorization Ticket or an Authorization certificate to an Authorization Authority ( In the authorization phase, the ITS station may request the AT from the AA. The AA is an entity responsible for issuing and monitoring the use of Authorization Tickets (ATs), which can provide authoritative proof that a V2X communication device can use a particular V2X service. Such AA may issue an AT. The V2X communication device may have an AT, 2nd last para, page 5 the V2X communication system may be a Root Certificate Authority (root CA), Enrollment Authority (EA), Authorization Authority (AA) and / or at least one V2X communication device. It may include, 3rd last para, page 12 receiving a response from the Authorization Authority, the response including the Authorization Ticket or the Authorization certificate ( the V2X communication device may request an EC and obtain an EC from the EA. Also, the V2X communication device may request an AT (PC) from AA and obtain an AT from AA. Also, the V2X communication device may transmit and receive a V2X message. For example, the V2X communication device may communicate a trust message with another V2X communication device using the EC and the AT. The V2X communication device can also forward the received V2X message to another V2X communication device. A V2X communication device that forwards to another V2X communication device is referred to as a relaying V2X communication device, last para, page 5. containing a safety assurance indication comprising information, The AA is an entity responsible for issuing and monitoring the use of Authorization Tickets (ATs), which can provide authoritative proof that a V2X communication device can use a particular V2X service, 8th para, page 5 A functional entities of the ITS security architecture and the relationships that exist between them and the ITS communication layer. In FIG. 10, the security layer is shown as a vertical layer adjacent to the ITS communication layer, but in fact, since the security service is provided on a layer by layer basis, the security layer can be subdivided into ITS layers. Such a security service may be provided on a layer basis in such a manner that each of the security services operates in one or several ITS architecture layers or in a security management layer. As shown in FIG. 10, functional entities of the ITS security architecture and the ITS communication layers may perform communication, last fifth para, page 12 sending a message to a second ITS entity, the message containing the information within the Authorization Ticket or Authorization certificate issued by the Authorization Authority. A V2X communication device that forwards to another V2X communication device is referred to as a relaying V2X communication device, last para, page 5. When in the “service authorization” state, the ITS station may have a set of ATs that allow transmission of signed messages to any other ITS station. 8th para, page 5 The entity may have an OBE Registration Certificate (EC), Anonymous Certificate (PC), and / or Identification Certificate (IC). The entity can use this EC to request a PC and / or IC from the AA. each EC may have at least one provider service ID (PSID), the owner's identity, IC can be used for authentication in V2I applications. The IC has a provisioning process similar to that of a PC, but can have different PSIDs and parameters. 3rd para page 10 the V2X communication device may communicate a trust message with another V2X communication device using the EC and the AT. The V2X communication device can also forward the received V2X message to another V2X communication device, last para, page 5. When in the “service authorization” state, the ITS station may have a set of ATs that allow transmission of signed messages to any other ITS station. 3rd para, page 14. Kim does not specifically mention about, which is well-known in the art, which GHOSH discloses, the safety assurance indication providing that at least one of hardware and software at the entity is certified to a safety assurance level, at least one of functional safety of the entity and a safety of an of the entity ( [0017] Furthermore, as the encryption is implemented in a FUSA manner, the system may be certified automotive safety integrity level (D), which requires FUSA execution of encryption operations. It is noted that ASIL D certification may be required for various automotive applications [0018] FIG. 1 to provide FUSA encryption for messages communicated over V2X network 140. [0012] In particular, the present disclosure provides an encryption system that is FUSA compliant. The disclosed FUSA encryption system can be implemented in hardware circuitry arranged to execute the encryption operations. Furthermore, the disclosure FUSA encryption system can be implemented in software, such as, at the application level in a V2X communication device. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known certified entity and functionality of the entity. One of ordinary skilled in the art would readily know that "Certified software" itself refers to software that has been officially recognized and approved by a third-party organization or entity, demonstrating compliance with specific standards, regulations, or quality requirements. This process ensures that the software meets certain criteria, offering assurance to users regarding its reliability, safety, or functionality. Hence, these limitations would enable implementing reliability, safety, or functionality with the entity, para 12. Kim and GHOSH do not specifically mention about, which is well-known in the art, which Cheng, CN 110879876 A discloses, to an indicated value, safety assurance indication within Authorization Ticket or Authorization certificate (expiry date, issuer device may generate authorization certificate in the trusted execution environment of the issuer device, and the value of each parameter of the authorization certificate set value of corresponding parameter in the authorization certificate parameter information. It should be understood that the authorization certificate may include parameter information of each parameter included in the authorization certificate parameter information. For example, the authorization certificate may include a publisher user identification, certificate identifier and the middleman user identifier, authorization certificate may also include an encryption algorithm identifier, encryption key, decryption algorithm identifier and a decryption key. It should be understood that the authorization certificate comprises the various parameters, in practice the authorization certificate may also include at least one of the following: a certificate type identifier, check code, certificate failure time, certificate fixed byte number and authorized content information of the configuration information, last para, page 9 apparatus generates corresponding to the target digital asset of the digital assets ciphertext, the authorization certificate ciphertext and witness information cipher text, and sends to the device, abstract) Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known safety assurance indication within Authorization Ticket or Authorization certificate. One of ordinary skilled in the art would readily know that "Certified software" itself refers to software that has been officially recognized and approved by a third-party organization or entity, demonstrating compliance with specific standards, regulations, or quality requirements. This process ensures that the software meets certain criteria, offering assurance to users regarding its reliability, safety, or functionality. Hence, these limitations would enable implementing reliability, safety, or functionality with the entity. The indication with the value of the certificate/ticket would enable providing information and communicating the information that is needed for the implementation of the safety/ functionality of the entity, abstract. Kim, GHOSH, CHENG, CN 110879876 A, do not specifically mention about, “a transmitter” “intended functionality”, “the indication is associated with PSID and SSP, wherein the PSID and the SSP indicate an application to which the safety assurance indication is applicable As demonstrated above, Kim in view of Ghoshnd Cheng, CN 110879876 A shows that the certificate/ticket can have lots of indications in the certificate/ticket itself. Such indications to indicate “a transmitter” “intended functionality” using the above taught certificate/ticket, is a design choice. For example, other inventors can merely add one more indication in the certificate/ticket and would overcome the claimed subject matter of this application. For example, further inventors can merely add further one more indication in the certificate/ticket and would overcome the claimed subject matter of this application. Yang disclose these limitations, Security profile: Indicate the security service profile / level to apply. ITS-AID length: Indicates the length of the value of the ITS-AID field. ITS-AID: indicates the ID of the application. Security permissions length: Indicates the length of the value of the Security permissions field. Security permissions: Service Specific Permissions (SSPs) associated with ITS-AID Security context information: Provides information for selecting security protocol properties. Security target ID list length: Indicates the length of the value of the Security target ID list field. Security target ID list: Provides a list of target IDs used by security entities, middle portion, page 21 Smart cars connect drivers, vehicles, and traffic infrastructure to provide a variety of customized mobility services, as well as traditional vehicle technologies such as traffic safety and complexity. This connectivity can be implemented using Vehicle to Everything (V2X) communication technology, 1st para, page 2. Application layer: The application layer may implement and support various use cases. For example, the application may provide road safety, efficient traffic information, and other application information. The application layer can classify and define ITS applications and provide services to end vehicles / users / infrastructures through lower layers. The application can be defined / applied by use-case, or the use-case can be grouped as road-safety, traffic efficiency, local service, infotainment to define / apply It may be. As an embodiment, application classification, use-case, etc. may be updated when new application scenarios occur. Layer management can manage and service information related to the operation and security of the application layer. Information and services are communicated and shared in both directions through the interface between management entity and application layer (MAMA) and the interface between security entity and ITS-S applications (SA) or Service Access Points (eg MA-SAP, SA-SAP) 3rd para, page 5 FCW technology is a V2V safety communication technology that warns of a collision with a preceding vehicle. If a vehicle with a V2X communication device stops suddenly or stops in an accident, it can send an FCW safety message to prevent subsequent vehicle collisions. Subsequent vehicles may receive FCW messages and warn the driver or perform controls such as speed reduction or lane change. 5th para, page 8 The network / transport layer of FIG. 5 may send a vehicle safety message, The PSID field is a provider service identifier and may be allocated according to an application in a higher layer. The PSID field helps the receiver determine the appropriate higher layer. 6th para, page 9 Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Kim to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known providing indication associated with PSID and SSP. One of ordinary skilled in the art would readily know that in computer science and networking, A Public Service Identifier (PSID) is a unique code with different meanings depending on the context, most commonly referring to an ID for emergency responders (tracking training/certs). It can also mean an identifier for Intelligent Transportation Systems (ITS) applications in vehicle-to-vehicle communication. Service-specific permissions are granular access controls defining what users or applications can do within particular services. Hence, the associated PSID would enable responders to track information, and the SSP would enable defining permission for the access control associated with the service, 3rd para, page 5. Conclusion One of ordinary skilled in the art would readily know that one may add lots of well-known information in the messages that are communicated between a sender and a received. 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 HARESH PATEL whose telephone number is (571)272-3973. The examiner can normally be reached on M-F 9-5:30. 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, Jorge L. Ortiz-Criado, can be reached at (571) 272-7624. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /HARESH N PATEL/Primary Examiner, Art Unit 2496
Read full office action

Prosecution Timeline

Jul 21, 2023
Application Filed
Dec 21, 2022
Response after Non-Final Action
Jun 07, 2025
Non-Final Rejection — §103
Aug 05, 2025
Response Filed
Sep 16, 2025
Final Rejection — §103
Nov 06, 2025
Interview Requested
Nov 13, 2025
Applicant Interview (Telephonic)
Nov 17, 2025
Response after Non-Final Action
Nov 27, 2025
Request for Continued Examination
Dec 06, 2025
Response after Non-Final Action
Dec 08, 2025
Non-Final Rejection — §103
Dec 30, 2025
Examiner Interview Summary
Feb 17, 2026
Applicant Interview (Telephonic)
Feb 18, 2026
Examiner Interview Summary
Feb 24, 2026
Response Filed
Mar 18, 2026
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12598058
MUTABLE DIGITAL ASSET STORAGE UNITS FOR VERIFYING OTHER STORAGE UNITS IN A DECENTRALISED PEER-TO-PEER STORAGE NETWORK
2y 5m to grant Granted Apr 07, 2026
Patent 12568384
BOOTSTRAPPING AND TROUBLESHOOTING OF REMOTE DEVICES
2y 5m to grant Granted Mar 03, 2026
Patent 12563036
DISTRIBUTED MANAGEMENT SYSTEM AND MANAGEMENT METHOD FOR SMART CARD MANAGEMENT APPARATUSES
2y 5m to grant Granted Feb 24, 2026
Patent 12563388
SYSTEMS AND METHODS FOR SECURITY ASSOCIATION ENABLING MAKE-BEFORE-BREAK-ROAMING (MBBR)
2y 5m to grant Granted Feb 24, 2026
Patent 12542805
DETECTING AND MITIGATING BLUETOOTH BASED ATTACKS
2y 5m to grant Granted Feb 03, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

5-6
Expected OA Rounds
78%
Grant Probability
99%
With Interview (+22.1%)
3y 1m
Median Time to Grant
High
PTA Risk
Based on 815 resolved cases by this examiner. Grant probability derived from career allow 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