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 .
Election/Restrictions
Applicant’s election without traverse of Invention I in the reply filed on July 28, 2026 is acknowledged.
Response to Amendment
Claims 10-15 have been canceled and Claims 16-24 have been added.
Claims 1-9 and 16-24 are pending for examination.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/29/2024 and 08/14/2025 was filed in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The disclosure is objected to because of the following informalities:
Typographical error: Unnecessary “c” in para 43, line 4. “The V2P policy may c information to enable a VAE server to perform V2P detection to alert vehicular and pedestrian UEs of a potential collision.” should be “The V2P policy may [[c]] information to enable a VAE server to perform V2P detection to alert vehicular and pedestrian UEs of a potential collision.”
Examiner notes that the sentence needs further editing to be grammatical correct. Examiner is unclear what applicant means by “The V2P policy may [[c]] information to enable a VAE….”
Appropriate explanation, clarification and correction is required.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-9 and 16-24 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Pateromichelakis et al. (US Publication No. US 20240430655 A1 and Pateromichelakis hereinafter).
Regarding Claim 1, Pateromichelakis discloses a method (i.e. FIGS. 5A-5B depict a procedure (i.e. method) 500 for the configuration and provisioning of the VRU high risk zone) Para [0142] performed by a vehicle to everything (V2X) application enabler (VAE) client (i.e. FIGS. 5A-5B, the middleware layer which supports the configuration and provisioning of the VRU high risk zone is an application enabler server, which has a client counterpart (i.e. VAE client) at the UE side.) Para [0143], the method comprising: receiving a first request from an application client on a user equipment (UE) (Figure 5A; i.e. At Step 4a, the application of target UE 503 (or VAE client 507 or SEAL LMS client) or other UEs on behalf of the target UE 503 may send a UE mobility event (or expected/predicted event) to VAE-S 513, indicating the mobility/handover to a target geographical or topological area (see messaging 533)) Para [0205] to enable vulnerable road user protection (VRUP) services associated with the UE (i.e. Described herein are solutions for how the VRU high risk area zones are configured and provisioned to the UEs, and what is the impact/needed enhancements at the 5GS to assist the corresponding UEs to access the VRUP services.) Para [0063]; sending a second request to a VAE server to create a vehicle to pedestrian (V2P) policy (Figure 5A; i.e. At Step 4a, the application of target UE 503 (or VAE client 507 or SEAL LMS client) or other UEs on behalf of the target UE 503 may send a UE mobility event (or expected/predicted event) to VAE-S 513, indicating the mobility/handover to a target geographical or topological area (see messaging 533)) Para [0205], wherein the V2P policy is configured to request creation of a vulnerable road user (VRU) zone associated with the UE (Figure 5A; i.e. At Step 4b, the VAE-S 513 translates the target UE 503 mobility event to an expected entrance to a VRU high risk zone, and based on the configuration of the zone, it identifies when an action needs to be taken and when to communicate this with the involved application and network entities (i.e. V2P policy) (see block 537).) Para [0207]; receiving a first response to the second request indicating a status of the second request, the first response comprising information of the V2P policy that applies to the UE (Figure 2; i.e. At Step 5b, the VAE-S 513 may also alert the VAE client (if deployed at the target UE 503) that it is expected to enter the VRU zone and requests the confirmation for allowing the push of VRU messages within the zone (see messaging 541). Such notification/request will include zone area information and configuration (or this can be provided after the response from the VAE client 507 and Step 5c).) Para [0209]; and sending a second response to the first request indicating the status of the first request (Figure 5B; i.e. At Step 7a, the VAE-S 513 sends the VRU zone configuration parameters to the target UE 503 via VAE layer connection (see messaging 547).) Para [0218] and (i.e. For V2P communications, e.g., VRU, CPM messages could be used as input for triggering an action at application layer of the device (e.g., activating a VRU app). This may also help detecting a VRU at risk.) Para [0052].
Regarding Claim 16, Pateromichelakis suggests all the limitations of claim 1 in device form rather than method form. Pateromichelakis discloses a device with a processor (Figure 8, elements 800 & 805; i.e. The transceiver 825 communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver 825 operates under the control of the processor 805 to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor 805 may selectively activate the transceiver 825 (or portions thereof) at particular times in order to send and receive messages.) Para [0294]. Therefore, the rejection of claim 1 applies equally as well to the limitations of claim 16.
Regarding Claim 2 and Claim 17, Pateromichelakis discloses all the limitations of claims 1 and 16, respectively, as discussed above. Further Pateromichelakis discloses wherein at least one of the first response or the second response (i.e. The VRU zone configuration parameters may be any combination of the parameters which were provided in Step 3a, and will allow the target UE 503 to receive/transmit VRU messages within the zone. The VRU zone configuration parameters may be any combination of the parameters which were provided in Step 3a, and will allow the target UE 503 to receive/transmit VRU messages within the zone.) Para [0218 & 0220] comprises one or more of the status of the first request, the status of the second request, a policy identifier, a policy expiration (i.e. Time of validity for the zone…Time duration, expected start/finish times,) Para [0178-0179] and (i.e. The notification/alert message may include the UE ID (GPSI, or external ID), the group ID (if it is a group of UEs), a VRU candidate flag, an expected start time of VRUP, an expected duration (i.e. policy duration)) Para [0208], V2P status, information about the VRU zone (i.e. the processor 905 configures a broadcast message for communicating zone status information to devices within the high-risk zone area) Para [0311], an indicator whether the VRU zone is dynamic (i.e. At Step 3a, the VAE-S 513 sends a message including the VRU zone configuration parameters (see messaging 527). This configuration will be provided to the V2X-UEs (and pedestrians) within the area that will be covered by the VRU zone, and will also indication when the zone will be activated, for how much time and if the zone configuration will be dynamically changing (e.g., where a school bus moves) and parameters related to the dynamicity (as discussed in Steps 1 and 2).) Para [0171] and (i.e. the VAE-S 513 provides information for setting up policies for a future communication within the high-risk zone. Here, the policies and corresponding information may include: …Zone ID, Zone type (static, dynamic)) Para [0174 & 0180], a V2X profile indicator, notification alert settings, V2P communication parameters, a location reporting configuration, temporary constraints, application server identifiers (i.e. Application ID and type,) Para [0176], application context reporting, battery information (i.e. Step 5a, the VAE-S 513 alerts the VASS that the target UE 503 is expected to move to the VRU zone area in X time and also provides information on its mobility as well as the capabilities (e.g., VRU capable) and optionally the battery status (see messaging 539) Para [0208], or opportunistic critical information delivery conditions.
Examiner notes that claims 2 and 17 recite “one or more… or”, therefore only some limitations were directly mapped above, however Pateromichelakis suggest several of the limitations in claim 2 in paragraphs [0171-0183] and [0208]: (i.e. At Step 3c, the VAE-S 513 sends the configuration parameters related to the 5GS 511 (e.g., to PCF 147) for the zone creation (see messaging 531). Such parameters may be one or more of the following: For communication over Uu, the VAE-S 513 provides information for setting up policies for a future communication within the high-risk zone. Here, the policies and corresponding information may include: [0175] Area of interest (geographical (coordinates, civic/street addresses) or topological, e.g., cell IDs, or DN service area) [0176] Application ID and type, [0177] UE ID (e.g., GPSI) and IP address, group ID, slice ID, DNN (if the target UE is known and the zone is dynamic) [0178] Time of validity for the zone [0179] Time duration, expected start/finish times, [0180] Zone ID, Zone type (static, dynamic), [0181] A maximum number of active UEs/VRUs within the zone, [0182] Supported UE types (pedestrian/VRU, V2X UE), and [0183] Service profile/app QoS requirements per UE type) Para [0174-0183] and (i.e. Step 5a, the VAE-S 513 alerts the VASS that the target UE 503 is expected to move to the VRU zone area in X time and also provides information on its mobility as well as the capabilities (e.g., VRU capable) and optionally the battery status (see messaging 539)... The notification/alert message may include the UE ID (GPSI, or external ID), the group ID (if it is a group of UEs), a VRU candidate flag, an expected start time of VRUP, an expected duration (i.e. policy duration), UE context information, expected mobility/speed/direction, etc.) Para [0208].
Regarding Claim 3 and Claim 18, Pateromichelakis discloses all the limitations of claims 1 and 16, respectively, as discussed above. Further Pateromichelakis discloses wherein the second request comprises at least one of an identifier of the UE, a location of the UE (Figure 5A, Step 4a; Figure 5B, Step 551; i.e. The 5GS 511 and VAE-S 513 track the location of the target UE 503 (see block 551). Upon entry of the target UE 503 to the VRU zone, the VAE-S 513 notifies the VASS/VRU server 515 (see messaging 553). Subsequently, the target UE 503 is within the zone and the service operation is ongoing (see block 555).) Para [0221], an indication for creating a V2P policy, location reporting configuration of the UE (Figure 5B; i.e. The 5GS 511 and VAE-S 513 track the location of the target UE 503 (see block 551). Upon entry of the target UE 503 to the VRU zone, the VAE-S 513 notifies (i.e. location reporting) the VASS/VRU server 515 (see messaging 553). Subsequently, the target UE 503 is within the zone and the service operation is ongoing (see block 555).) Para [0221], conditions for which to send the UE alerts, V2P communication parameters, temporal constraints for V2P detection, or an indication of whether the VRU zone is dynamic (Figure 6, element 619, 621; i.e. At Step 2b, the VAE server 513 receives the requirement for the alerting V2X UE 601 by the V2X server 513, and optionally receives the requirement for a new dynamic zone creation (see messaging 619)… At Step 3, the VAE server 513 determines the zone parameters and creates a dynamic zone (see messaging 621).) Para [0229-0230].
Regarding Claim 4 and Claim 19, Pateromichelakis discloses all the limitations of claims 3 and 18, respectively, as discussed above. Further Pateromichelakis discloses wherein the V2P communication parameters comprise at least one of
authorization and authentication information (i.e. The AMF 143 is responsible for termination of NAS signaling, NAS ciphering & integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management.) Para [0084],
radio communication parameters (i.e. VRU-ZCF 703 may provide pre-configured provisioning policies/parameters for the zone, such as QoS parameters and/or radio parameters, such as those defined in 3GPP TS 23.287.) Para [0269],
access type parameters (i.e. The UPF(s) 141 is/are responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU session for interconnecting Data Network (DN), in the 5G architecture. The AMF 143 is responsible for termination of NAS signaling, NAS ciphering & integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management. The SMF 145 is responsible for session management (i.e., session establishment, modification, release), remote unit (i.e., UE) IP address allocation & management, DL data notification, and traffic steering configuration of the UPF 141 for proper traffic routing.) Para [0084],
V2X identifiers (i.e. maintaining the mapping between the V2X user ID and the V2X UE ID) Para [0071],
V2X communication identifiers (i.e. The VAE client 165 provides the client-side V2X application layer support functions, including registration of VAE clients 165 for receiving V2X messages, receiving V2X messages from the VAE server 163 and the delivery to V2X application specific client(s) according to the V2X service ID) Para [0072],
a mode of communication (i.e. maintaining the mapping between the V2X user ID and the V2X UE ID) Para [0066],
V2P communication mechanisms (i.e. A remote unit 105 may be provided with different V2X communication resources for different V2X modes. Mode-1 corresponds to a NR network-scheduled V2X communication mode. Mode-2 corresponds to a NR UE-scheduled V2X communication mode. Mode-3 corresponds to an LTE network-scheduled V2X communication mode. Mode-4 corresponds to an LTE UE-scheduled V2X communication mode.) Para [0066],
a communication schedule (i.e. A remote unit 105 may be provided with different V2X communication resources for different V2X modes. Mode-1 corresponds to a NR network-scheduled V2X communication mode. Mode-2 corresponds to a NR UE-scheduled V2X communication mode. Mode-3 corresponds to an LTE network-scheduled V2X communication mode. Mode-4 corresponds to an LTE UE-scheduled V2X communication mode.) Para [0066],
a network protocol (Figure 3 & 4; i.e. FIG. 3 depicts a V2X protocol stack 300.) Para [0135] and (i.e. FIG. 4 depicts a NR protocol stack 400) Para [0138],
a device type (i.e. , and a plurality of V2X UEs-including a target VRU device 227 (i.e. pedestrian) and multiple vehicular UEs (e.g., a first vehicular V2X UE 215 and a second vehicular V2X UE 217)…the network 200 may include different numbers and/or types of V2X UEs) Para [0094],
a V2X service identifier and message type (i.e. The VAE client 165 provides the client-side V2X application layer support functions, including registration of VAE clients 165 for receiving V2X messages, receiving V2X messages from the VAE server 163 and the delivery to V2X application specific client(s) according to the V2X service ID) Para [0072],
a transmission profile (i.e. As depicted, the vehicles 161 include a remote unit 105 and may communicate directly with each other (e.g., device-to-device communication) using V2X communication signals 103. Here, V2X transmissions may occur on V2X resources. A remote unit 105 may be provided with different V2X communication resources for different V2X modes.) Para [0066] and (i.e. the transmission modes (unicast, groupcast, broadcast) within the applications within the zone) Para [0161], and
QoS parameters (i.e. VRU-ZCF 703 may provide pre-configured provisioning policies/parameters for the zone, such as QoS parameters and/or radio parameters, such as those defined in 3GPP TS 23.287.) Para [0269].
Examiner notes that claims 4 and 19 recite “one or more…and”, therefore each limitation was mapped above, as each limitation is required.
Regarding Claim 5 and Claim 20, Pateromichelakis discloses all the limitations of claims 1 and 16, respectively, as discussed above. Further Pateromichelakis discloses receiving a vehicle to pedestrian notification from a VAE server (Figure 5B; i.e. At Step 5b, the VAE-S 513 may also alert (i.e. the recited notification) the VAE client (if deployed at the target UE 503) that it is expected to enter the VRU zone and requests the confirmation for allowing the push of VRU messages within the zone (see messaging 541). Such notification/request will include zone area information and configuration (or this can be provided after the response from the VAE client 507 and Step 5c).) Para [0209].
Regarding Claim 6 and Claim 21, Pateromichelakis discloses all the limitations of claims 5 and 20, respectively, as discussed above. Further Pateromichelakis discloses wherein the VAE client sends a notification to an application client on the UE in response to receiving a vehicle to pedestrian (Figure 2) notification from a VAE server (Figure 5B; i.e. At Step 5b, the VAE-S 513 may also alert the VAE client (if deployed at the target UE 503) that it is expected to enter the VRU zone and requests the confirmation for allowing the push of VRU messages within the zone (see messaging 541). Such notification/request will include zone area information and configuration (or this can be provided after the response from the VAE client 507 and Step 5c).) Para [0209].
Regarding Claim 7 and Claim 22, Pateromichelakis discloses all the limitations of claims 1 and 16, respectively, as discussed above. Further Pateromichelakis discloses wherein the VAE client receives a VRUP notification from an application on the UE (Figure 5A; i.e. At Step 4a, the application of target UE 503 (or VAE client 507 or SEAL LMS client) or other UEs on behalf of the target UE 503 may send a UE mobility event (or expected/predicted event) (i.e. based on the policy information provided by VAE server in step 3c) to VAE-S 513, indicating the mobility/handover to a target geographical or topological area (see messaging 533)(i.e. first arrow in figure)) Para [0205] with application context information policy (i.e. At Step 3c… the VAE-S 513 provides information for setting up policies for a future communication within the high-risk zone. Here, the policies and corresponding information may include: Area of interest (geographical (coordinates, civic/street addresses) or topological, e.g., cell IDs, or DN service area),Application ID and type, UE ID (e.g., GPSI) and IP address, group ID, slice ID, DNN (if the target UE is known and the zone is dynamic), Time of validity for the zone, Time duration, expected start/finish times,
Zone ID, Zone type (static, dynamic), A maximum number of active UEs/VRUs within the zone, Supported UE types (pedestrian/VRU, V2X UE), and Service profile/app QoS requirements per UE type) Para [0174]. Examiner notes that Pateromichelakis [0037-0042] includes examples of application context information of user activity.
Regarding Claim 8 and Claim 23, Pateromichelakis discloses all the limitations of claims 7 and 22, respectively, as discussed above. Further Pateromichelakis discloses the VAE client sending the application context information to a VAE server (Figure 5A; i.e. At Step 4a, the application of target UE 503 (or VAE client 507 or SEAL LMS client) or other UEs on behalf of the target UE 503 may send a UE mobility event (or expected/predicted event) to VAE-S 513 (i.e. VAE server), indicating the mobility/handover to a target geographical or topological area (see messaging 533)(i.e. second arrow in figure)) Para [0205].
Regarding Claim 9 and Claim 24, Pateromichelakis discloses all the limitations of claims 7 and 22, respectively, as discussed above. Further Pateromichelakis discloses wherein the application context information comprises one or more of an application identifier, an indication that an application type is active on the UE, an indication that the UE is within a threshold distance of a crosswalk (i.e. Pedestrian in crosswalks—send out alerts to motorists when pedestrian in a mid-block crossing. (Can be infrastructure-based messages to motorists). Pedestrians in crosswalks at intersections. Provide alerts to motorist when pedestrians are crossing a side street on right or left of vehicle. Also provide alerts when pedestrian in crosswalk and signal is green for vehicle. (Can be infrastructure-based messages to motorist). ) Para [0058-59], a route of navigation associated with the application (Figure 5A; i.e. At Step 4a, the application of target UE 503 (or VAE client 507 or SEAL LMS client) or other UEs on behalf of the target UE 503 may send a UE mobility event (or expected/predicted event) to VAE-S 513, indicating the mobility/handover to a target geographical or topological area (i.e. route of navigation) (see messaging 533)) Para [0205], or an indication that an additional device associated with the UE is in use.
Pertinent Prior Art
The prior art made of record is considered pertinent to applicant's disclosure.
Pateromichelakis (US 20230179969 A1) “CONTROLLING V2X MESSAGE DISTRIBUTION” (June 8, 2023) is directed to controlling V2X message distribution. One apparatus includes a transceiver that receives at least one application requirement from at least one V2X application. The apparatus includes a processor that determines a configuration policy for a plurality of V2X UEs based on the at least one application requirement. Here, the configuration policy controls the V2X message distribution among the plurality of V2X UEs. The processor controls the transceiver to transmit the determined configuration policy to at least one V2X UE of the plurality of V2X UEs.
Siboni (US 20200035103 A1) “A System And Method For Preventing Car Accidents And Collisions Between Vehicles And Pedestrians” (January 30, 2020) is directed to predicting and preventing car accidents and collisions between vehicles and pedestrians, which comprises a plurality of mobile devices each carried by a pedestrian user or a user riding in a vehicle; a dedicated software application installed on each of the mobile devices adapted to detect the location of the mobile device; one or more geographic servers. The software application is adapted to receive and process updates associated with position and motion of other mobile devices from the geographic server, calculate a collision probability (that may be calculated for a danger domain in the surrounding of the user), and accordingly issue a collision alert to mobile users who are of high probability of collision.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Iyonda L. Lewis whose telephone number is (571)272-4440. The examiner can normally be reached Monday - Friday 8:00am - 4:00pm.
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, Alison Slater can be reached at (571) 270-0375. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/IYONDA L LEWIS/Patent Examiner, Art Unit 2647
Iyonda.Lewis@USPTO.gov
/Alison Slater/Supervisory Patent Examiner, Art Unit 2647
Prosecution Insights