一种由边缘计算设备执行的用于生成本地动态地图（LDM）数据的方法，包括：接收所述边缘计算设备的服务区域的第一LDM数据，其中所述第一LDM数据包括在阈值时间量内获得的高度动态的信息的数据；

基于所接收的所述第一LDM数据是否与来自另一个源的LDM数据相证实以及基于一个或多个附加信任参数，确定所接收的所述第一LDM数据的信任度量；

响应于确定所述信任度量超过所述信任度量阈值，将所述第一LDM数据集成到LDM数据模型中；

确定所述LDM数据模型的、与移动设备相关的第二LDM数据，其中所述第二LDM数据包括在所述阈值时间量内获得的高度动态的信息的数据；以及将所确定的第二LDM数据提供给所述移动设备。

基于您提供的无效宣告请求审查决定书（第583305号），以下是对该决定存在的事实认定错误和法律适用错误的专业严谨分析。该分析旨在为后续的行政诉讼提供核心的诉讼理由和逻辑支撑。

核心观点综述

合议组维持专利权有效的核心理由在于：认为证据1和证据6均未公开“基于...相证实以及基于一个或多个附加信任参数，确定信任度量”且“响应于超过阈值...集成到LDM”的特征。

决定的根本错误在于：

1. 事实认定错误（漏读证据6）： 决定书在引用证据6内容时，已经明确记录了证据6公开了“恶意软件识别”、“上下文信息比较”等内容，但在结论部分却无视这些内容，错误地认定证据6仅给出了“另一个源证实”的启示，忽略了证据6同时公开了“附加信任参数”。

2. 法律适用错误（结合逻辑错误）： 决定书割裂了证据1和证据6的结合逻辑。证据1已公开“可信车辆（信任参数）”，证据6公开了“证实”及“阈值判定逻辑”。两者结合已完全覆盖权利要求1的特征，合议组却要求证据6必须独立公开“至少两个参数+集成”的完整方案，提高了创造性结合的门槛。

详细逻辑分析

一、 事实认定错误：证据6实际上公开了“附加信任参数”及“信任度量/阈值判定”

1. 权利要求1的特征要求：
权利要求1要求确定信任度量的依据是两部分：
(A) 是否与来自另一个源的LDM数据相证实（Corroboration）；
(B) 一个或多个附加信任参数（Additional Trust Parameters）。

2. 决定的错误认定：
决定书第12页第3段认定：“可见证据6给出了采用另一个源的验证作为信任参数的技术启示，但是证据6并未公开上述使用至少两个信任参数确定信任度量……”。
这意味着合议组认为证据6只公开了（A），没有公开（B）。

3. 证据6的实际公开内容（反驳依据）：
请注意决定书第12页第2段引用的证据6译文内容，证据6实际上公开了除“传感器证实”以外的多个评估维度（即附加信任参数）：

• 附加参数1：恶意软件/网络攻击状态

  • 证据6译文[0015]段： “……以确定信息对于各种用途的可靠性、识别恶意软件做出更好或更明智的决策。”

  • 分析： 识别是否为恶意软件，显然是独立于“传感器数据是否一致”之外的另一个信任评估维度。如果车辆被识别为感染恶意软件，即便其数据与传感器一致，其信任度也会降低。这完全符合“附加信任参数”的定义。

• 附加参数2：上下文信息

  • 证据6译文[0015]段： “将接收到的车辆信息与上下文信息进行比较……使用比较结果来确定是否应对接收到的车辆信息进行更严格的评估。”

  • 证据6译文[0023]段： “基于接收到的车辆信息的内容或上下文……选择传感器”。

  • 分析： “上下文信息”（如时间、地理位置合理性等）是独立于“轮询其他传感器进行证实”这一动作之前的比对参数。这也是一个典型的“附加信任参数”。

• 关于“信任度量”与“阈值”的公开：

  • 证据6译文[0026]段： “……比较车辆值与传感器值，以确定是否将接收到的车辆信息标记/标签为已验证、已认证、值得信赖、有效等。”

  • 分析： “比较值”隐含了阈值判定（只有差异在一定范围内才算一致），而最终生成的“已验证/值得信赖”标签，在技术本质上就是一种定性的“信任度量”（Trust Metric）。

结论：
证据6不仅公开了“另一个源的证实”（传感器轮询），还明确公开了利用“恶意软件检测”和“上下文信息”来评估信息的可靠性。合议组在事实认定上存在重大遗漏，无视了证据6中关于恶意软件和上下文信息的记载，错误地认为证据6未公开附加信任参数。

二、 法律适用错误：错误的结合逻辑与创造性标准

1. 决定的错误逻辑：
决定书第12页认为：“证据1和证据6均未公开使用至少两个信任参数……因此……不具备创造性的主张不成立。”
其逻辑隐含要求：要么证据1有“2个参数+集成”，要么证据6有“2个参数+集成”。

2. 正确的结合逻辑（反驳依据）：
创造性判断应遵循“拼图原则”，即各证据特征的有机结合。

• 证据1（D1）的贡献：

  • 基础架构： 边缘设备（RSU）接收数据、更新地图（集成到LDM）。

  • 参数A： 决定书第11页倒数第3段已承认，D1[0048]段公开了“可信车辆（如警车）”对应于一个信任参数。

  • 技术缺口： 如何更准确地验证数据？

• 证据6（D6）的贡献：

  • 改进手段（证实）： 引入“另一个源（传感器）”进行证实。

  • 改进手段（流程）： 计算比较值 -> 阈值判定 -> 标记为“已验证”（信任度量） -> 若验证通过则存储/使用，若未通过则丢弃（集成逻辑）。

• 结合后的方案（D1 + D6）：
  当本领域技术人员为了解决D1中“保证数据真实性”的问题（决定书认定的技术问题），将D6的验证机制引入D1时，形成的方案是：

  • 参数来源： D1提供了“车辆类型（可信车辆）”作为参数1；D6提供了“传感器证实”作为参数2（以及D6自带的恶意软件检测作为参数3）。

  • 处理逻辑： 采用D6教导的逻辑——综合考虑这些因素（车辆是不是警车？传感器证实了吗？有没有恶意软件？），确定数据是否“值得信赖”（信任度量）。

  • 执行动作： 如果值得信赖（超过阈值），则执行D1原本的动作——更新地图（集成到LDM模型）。

3. 错误所在：
合议组错误地割裂了证据。既然D1已经有了一个参数（可信车辆），D6只要提供“证实”机制，两者结合自然就满足了权利要求1中“基于证实...以及基于一个或多个附加信任参数”的要求。
权利要求1并不要求所有参数都必须来自同一份对比文件。合议组以D6没有“使用至少两个参数”为由否定结合，是无视了D1本身已经存在的参数，属于对创造性判断标准的错误适用。

三、 关于“集成到LDM数据模型”的特定反驳

决定书认为D6未公开“将第一LDM数据集成到LDM数据模型中”。

反驳逻辑：

1. 功能对应性：

   • D1的目的是“更新基础地图”（见决定书第11页第2段）。

   • D6的目的是验证信息后“执行响应操作”（如存储、控制）。

   • 将D6的验证方法用于D1，其自然结果就是：验证通过的数据被用于更新D1的地图。 “更新D1的地图”即等同于“集成到LDM数据模型中”。

2. 阈值逻辑的公开：

   • D6[0026]段公开了“比较车辆值与传感器值...确定...标记为已验证”。这种“比较”必然隐含了差值是否在允许范围（阈值）内的判断。

   • D6公开了验证通过才被标记有效，验证失败则丢弃（隐含逻辑或公知常识：无效数据不应被使用）。这与权利要求1“超过阈值才集成”的逻辑完全一致。

四、 总结（用于行政诉讼起诉状）

综上所述，原无效决定存在以下具体错误，应予撤销：

1. 事实认定不清： 决定书遗漏了证据6（US2017272450A1）说明书第[0015]、[0020]、[0023]段关于“识别恶意软件”、“上下文信息比较”的明确记载。这些特征构成了权利要求1所述的“附加信任参数”。

2. 创造性判断逻辑错误： 决定书承认证据1公开了“可信车辆”这一信任参数，承认证据6公开了“证实”机制。两份证据结合显而易见地构成了“基于证实以及基于一个附加参数（可信车辆）确定信任度”的技术方案。决定书强行要求证据6必须独立公开“至少两个参数”，违反了专利法关于现有技术结合的判断原则。

3. 对技术特征的理解僵化： 证据6公开的“验证通过后标记为值得信赖并存储/使用”，与D1的“更新地图”结合，实质上已经公开了“基于信任度量超过阈值而集成到模型”的步骤。决定书对此进行了不当的狭义解释。

结论： 权利要求1相对于证据1结合证据6具备显而易见性，原决定维持专利权有效的理由不能成立。

这是一份针对行政诉讼的高强度法律意见分析。本分析的核心策略在于：回归本专利说明书对“信任参数”的宽泛定义，以此为“尺”，去衡量证据1和证据6的公开内容，从而证明无效决定的事实认定存在根本性错误。

请在撰写行政诉讼起诉状或代理意见时，直接引用以下逻辑和证据比对。

关于证据1和证据6均已公开“两个以上信任参数”的事实认定分析意见

案号： [填写案号]
原告： [填写请求人名称]
争议焦点： 无效决定错误地认定证据1仅公开了一个信任参数，且错误地认定证据6未公开两个信任参数。

一、 法律大前提：本专利说明书对“信任参数”的定义

在判断现有技术是否公开了“信任参数”之前，必须首先明确本专利对该术语的界定。根据本专利说明书的记载，“信任参数”的定义极为宽泛，涵盖了任何影响信任判定的因素。

• 说明书第 [0013] 段： “基于多个信任参数确定所接收的第一LDM数据的信任度量。”

• 说明书第 [0164] 段（定义核心）：

  “处理器可以基于多个因素和/或确定来确定信任度量，其中每一个这样的因素和/或确定可以增加或减少总体信任度量。每个这样的因素或确定在此被称为‘信任参数’。”

• 说明书第 [0165] 段（具体举例）：

  列举的信任参数包括：“连接类型（蜂窝/蓝牙）”、“网络节点跳数”、“通信链路安全级别（加密/非加密）”、“源设备的可信度（是否认证）”、“是否向网络注册”等。

法律结论： 根据说明书定义，凡是参与到对数据可信度进行评估、能增加或减少总体信任度量的任何“因素（Factor）”或“确定（Determination）”，均属于本专利所述的“信任参数”。 无效决定若将“信任参数”狭隘地理解为某种特定的数值变量，则属于错误解释权利要求。

二、 证据1（D1）事实认定错误分析：D1公开了至少两个独立信任参数

无效决定仅认定证据1公开了“可信车辆（如警车）”这一个参数，完全遗漏了D1同段落中明确记载的“历史数据准确性”这一独立参数。

对照说明书定义，证据1公开内容如下：

1. 信任参数一：车辆身份类型（决定已认定）

• D1原文 [0048]： “Telemetry could be limited to certain 'trusted vehicles' such as... police cars...”

• 对应性： 对应说明书[0165]段的“源设备的可信度”。

2. 信任参数二：历史数据准确性（决定遗漏，核心反驳点）

• D1原文 [0048]：

  "Higher weights may be given to selected vehicles whose past data has consistently proven to be accurate."
  （对于那些过去的数据已被持续证明是准确的选定车辆，可以给予更高的权重。）

• 结合说明书分析：

  • 根据本专利说明书[0164]段，“增加或减少总体信任度量”的因素即为信任参数。

  • D1中明确记载：基于“过去的数据持续准确（Past data accuracy）”这一因素，给予“更高的权重（Higher weights）”。这里的“权重”即为信任度量，“历史准确性”即为决定权重的因素。

  • 独立性： “历史准确性”与“车辆身份”是独立的。一辆警车（身份参数符合）如果传感器老化导致历史数据偏差大，其历史准确性参数就不符合。

• 结论： D1公开了基于**“身份”和“历史表现”**两个维度的信任参数。

3. 信任参数三：统计样本数量（决定遗漏）

• D1原文 [0048]：

  "...weighting might not begin until telemetry from a threshold number of vehicles has been received."
  （...直到接收到阈值数量的车辆的遥测数据后才开始加权。）

• 结合说明书分析：

  • “样本数量是否达到阈值”是一个“确定（Determination）”。未达到阈值时，数据不可信（不加权/不使用）；达到后可信度提升。

  • 这是一个基于统计学的信任参数。

综上，证据1自身已经公开了至少三个信任参数，无效决定认定其仅公开了一个，属于严重的事实认定错误。

三、 证据6（D6）事实认定错误分析：D6公开了至少三个独立信任参数

无效决定承认D6公开了“证实（传感器比对）”，但以D6未公开“至少两个参数”为由否定结合。事实上，D6在传感器证实之外，还引入了“恶意软件检测”和“上下文比对”作为独立参数。

对照说明书定义，证据6公开内容如下：

1. 信任参数一：传感器证实（决定已认定，即“另一个源”）

• D6原文 [0026]： “比较车辆值与传感器值...确定是否将接收到的车辆信息标记/标签为已验证...”

• 对应性： 对应权利要求1中的“是否与来自另一个源的LDM数据相证实”。

2. 信任参数二：恶意软件/网络攻击状态（决定遗漏，核心反驳点）

• D6原文 [0005] & [0020]：

  [0020]: “...server computing device may evaluate and verify the received vehicle information... ensure the reporting vehicle is not infected with malware and/or has not been subject to a cyberattack.”
  （...服务器计算设备可以评估和验证接收到的车辆信息...确保报告车辆未感染恶意软件和/或未受到网络攻击。）

• 结合说明书分析：

  • 根据本专利说明书[0165]段，**“通信链路安全级别”**是信任参数的典型例子。

  • D6明确记载：在作出控制决策前，必须确保车辆“未感染恶意软件”。这是一个典型的**“安全状态（Security Status）”**因素。

  • 如果“恶意软件检测=阳性”，则信任度量降为零（丢弃数据）；如果“阴性”，则信任度量提升（继续评估）。这完全符合说明书[0164]段关于“增加或减少总体信任度量”的定义。

• 结论： “恶意软件状态”是独立于“传感器证实”之外的附加信任参数。

3. 信任参数三：上下文信息一致性（决定遗漏）

• D6原文 [0002]：

  “...compare the received vehicle information with context information to generate a comparison result... determine whether the received vehicle information should be evaluated more critically.”
  （...将接收到的车辆信息与上下文信息进行比较以生成比较结果...确定是否应对接收到的车辆信息进行更严格的评估。）

• 结合说明书分析：

  • D6先用“上下文信息”进行初筛。如果上下文不匹配（例如车辆注册地与报告地跨度过大，见D6 [0023]），则认为数据可疑（降低信任度），需要更严格评估。

  • 这完全符合说明书[0164]段定义的“因素或确定”。

• 结论： “上下文信息”是独立于“传感器证实”之外的另一个附加信任参数。

综上，证据6公开了“传感器证实”+“恶意软件状态”+“上下文一致性”至少三个参数。

四、 总结与诉讼逻辑

1. 对于权利要求1的“信任参数”，本专利说明书给予了极宽的定义： 任何影响信任评估的因素都是信任参数。

2. 在此定义下，证据1事实认定错误： D1不仅有“车辆类型”，还有“历史准确性权重”和“统计样本阈值”。D1自身已满足多参数逻辑。

3. 在此定义下，证据6事实认定错误： D6不仅有“传感器证实”，还有“恶意软件检测”和“上下文比对”。D6自身已满足“证实+附加参数”的逻辑。

4. 结合逻辑的必然性：

   • 权利要求1 = 证实 + 附加信任参数。

   • D1（提供附加参数：历史准确性/身份） + D6（提供证实：传感器比对 + 附加参数：恶意软件）。

   • 两者结合，不仅数量上远超“两个”，在逻辑上也构成了完整的“基于多维度因素确定数据可信度”的技术方案。

结论： 无效决定基于错误的事实认定（遗漏了D1和D6中明确记载的多个评估因素），得出了错误的非显而易见性结论。请求法院予以纠正。

这是一份针对行政诉讼的**无效决定分析意见书**。你需要将此内容转化为正式的法律代理意见或诉讼理由。

**核心策略提示：**
该无效决定（下称“决定”）的致命错误在于**事实认定不清**。决定承认了证据6公开了“另一源证实”，但错误地认定证据6**未公开**“附加信任参数”以及“基于多参数确定信任度量并集成”的逻辑。
实际上，证据6不仅公开了“另一源证实”，还明确公开了“恶意软件检测”、“上下文信息比对”等**附加信任参数**，并且明确记载了基于验证结果（即信任度量）决定“存储（集成）”或“丢弃”的完整逻辑。

以下是详细的分析逻辑：

---

### 关于无效决定中证据1结合证据6事实认定错误的法律分析

**案号：** [填写案号]
**原告：** [填写请求人名称]
**被告：** 国家知识产权局

#### 一、 决定要点回顾与错误综述

**无效决定观点：**
决定承认：
1.  证据1公开了“可信车辆”作为一个信任参数。
2.  证据6公开了“来自另一个源（相邻传感器）的证实”作为验证手段。

决定驳回理由：
决定认为证据6**未公开**“使用至少两个信任参数（即：证实+附加参数）确定信任度量”且**未公开**“在信任度量超过阈值时将数据集成到模型”的技术内容。因此认为D1+D6未给出完整技术启示。

**错误分析综述：**
该认定属于严重的**事实认定错误**。证据6实际上完整公开了权利要求1中关于信任度量计算的所有要素，包括：
1.  **证实（Corroboration）：** 利用传感器信息比对。
2.  **附加信任参数（Additional Trust Parameters）：** 证据6明确记载了检查**“恶意软件（Malware）”**、**“网络攻击”**以及**“上下文信息（Context Information）”**。
3.  **集成逻辑：** 证据6明确记载了验证通过则**“存储在数据库”**（集成），验证不通过则**“丢弃”**。

---

#### 二、 详细举证与逻辑分析

以下分析将严格对照权利要求1的区别特征，逐一指出决定中遗漏和误读的证据6内容。

##### 1. 关于“一个或多个附加信任参数”的事实认定错误

**决定错误点：** 决定仅认定证据6公开了“传感器轮询证实”，而忽略了证据6中关于车辆自身状态（恶意软件、上下文）的检查。

**证据6的实际公开内容：**
证据6除了通过传感器进行外部证实外，还明确引入了其他参数来辅助确定信息的可信度。

*   **引用证据6译文第[0005]段：**
    > “某些实施例还可能包括在确定接收到的车辆信息未被接收到的传感器信息证实时，**确定报告车辆是否感染了恶意软件**。”
*   **引用证据6译文第[0020]段：**
    > “...为了保护车辆免受恶意软件的侵害并做出更好或更明智的决策，服务器计算设备可在作出控制决策...之前，对接收到的车辆信息进行评估和验证。...通过验证信息，服务器计算设备还确保报告的车辆**未被恶意软件感染和/或未遭受网络攻击**。”
*   **引用证据6译文第[0002]段：**
    > “...包括在服务器计算设备中接收来自报告车辆的车辆信息，并比较接收到的车辆信息与**上下文信息**以生成比较结果。”

**逻辑分析：**
权利要求1要求的“附加信任参数”是指除了“与其他源证实”之外的参数。
在证据6中，服务器不仅进行传感器数据的比对（这是“证实”），还同时检查车辆是否“感染恶意软件”或“遭受网络攻击”（见[0020]），以及将车辆信息与“上下文信息”（如车辆注册地、历史位置等，见[0023]举例）进行比对。
**“是否感染恶意软件”**和**“上下文信息是否匹配”**显然属于权利要求1所述的**“附加信任参数”**。
因此，证据6实际上公开了：为了确定数据的真实性（即信任度量），既使用了传感器比对（证实），也使用了恶意软件检测/上下文比对（附加信任参数）。决定忽略了证据6关于恶意软件和上下文信息的记载，导致事实认定错误。

##### 2. 关于“确定信任度量”及“阈值判断”的事实认定错误

**决定错误点：** 决定声称证据6未公开确定信任度量且在超过阈值时集成。

**证据6的实际公开内容：**
证据6明确记载了通过计算差值并与阈值比较来生成“已验证”的标记（即确定信任度量），并据此决定存储。

*   **引用证据6译文第[0003]段：**
    > “...将接收到的车辆信息应用于第一行为模型以生成第一值，将接收到的传感器信息应用于第二行为模型以生成第二值，并且当确定第一值与第二值之间的**差异超过阈值**时，由服务器计算设备**标记车辆信息为已验证**。”
    *(注：此处译文若为“超过阈值时标记为已验证”可能存在翻译逻辑表述差异，通常逻辑是差异“小于”阈值或符合阈值范围即验证通过，但不影响其公开了“阈值比较”这一逻辑手段。或者证据6逻辑是计算匹配度超过阈值。无论如何，公开了基于阈值的判定逻辑)*
*   **引用证据6译文第[0026]段：**
    > “...比较车辆值与传感器值，以确定是否将接收到的车辆信息**标记/标签为已验证、已认证、值得信赖、有效**等。”

**逻辑分析：**
证据6中的“第一值与第二值的比较”、“确定差异是否超过阈值”、“标记为已验证/值得信赖”，这一过程完全对应权利要求1中的**“确定...信任度量”**（即验证结果/可信度标签）以及**“信任度量超过阈值”**（即满足验证条件）。
“标记为值得信赖（Trustworthy）”本身就是一种定性的信任度量。决定无视了证据6中明确存在的模型计算、阈值比较和标签生成过程。

##### 3. 关于“集成到LDM数据模型中”的事实认定错误

**决定错误点：** 决定认为证据6未公开在满足条件时将数据“集成”。

**证据6的实际公开内容：**
*   **引用证据6译文第[0005]段：**
    > “...响应于确定接收到的车辆信息被接收到的传感器信息证实，将接收到的车辆信息**存储在数据库中**，并在确定接收到的车辆信息未被接收到的传感器信息证实时，**丢弃**接收到的车辆信息。”
*   **引用证据6译文第[0022]段：**
    > “...服务器/处理器可以在块222中将接收的车辆信息**存储在数据库中**。在可选块224中...基于所接收的车辆信息做出智能控制决策。”

**逻辑分析：**
在证据1（D1）的场景下，RSU的功能是维护和更新地图（LDM）。
在证据6（D6）的场景下，验证通过后的数据被**“存储在数据库中”**并用于后续控制。
当本领域技术人员将证据6的验证机制应用于证据1时，证据6中的“存储在数据库中”直接对应于证据1中的“更新地图/集成到LDM模型”。因为在证据1中，只有真实的数据才会被用于更新地图。证据6明确给出了“验证通过则存储（集成），不通过则丢弃”的筛选逻辑。决定称证据6未公开此技术内容，属于对技术方案的机械割裂。

---

#### 三、 结合启示的必然性分析（D1+D6）

**本专利试图解决的技术问题：**
决定中认定为：“如何进一步保证更新本地动态地图的第一LDM数据的真实性”。

**D1与D6结合的显而易见性：**
1.  **D1已提出需求：** 证据1说明书第[0048]段明确指出了数据可能存在不可靠的情况，因此提出了“限制为可信车辆”或“统计加权”的需求。这表明D1已经意识到了需要对数据来源进行筛选和信任评估。
2.  **D6提供完整解决方案：** 证据6恰好解决的是“确定车辆信息真实性”（D6标题及[0001]段）的问题。D6教导了不仅仅依赖单一因素，而是通过**“上下文比对”**（附加参数1）、**“恶意软件检测”**（附加参数2）以及**“传感器轮询证实”**（另一源证实）来进行综合验证。
3.  **技术方案的对应性：**
    *   **权利要求1：** 证实 + 附加信任参数 -> 信任度量 > 阈值 -> 集成。
    *   **D1+D6结合：**
        *   **证实：** D6的传感器轮询比对（D6 [0002]）。
        *   **附加信任参数：** D1自身的“可信车辆类型”（D1 [0048]） + D6的“恶意软件检测/上下文检查”（D6 [0005],[0020]）。
        *   **信任度量/阈值：** D1的“统计加权（statistically weigh）”（D1 [0048]）结合 D6的“模型值比较/阈值判定/标记为值得信赖”（D6 [0003],[0026]）。
        *   **集成：** D1的地图更新（D1 [0027]）结合 D6的“验证通过即存储”（D6 [0005]）。

**结论：**
本领域技术人员在D1明确提出需要对车辆数据进行加权和筛选（[0048]）的指引下，有充分的动机引入D6这种成熟的车辆信息验证机制。
一旦引入，本领域技术人员自然会采用D6教导的**全套验证流程**：即不仅看传感器是否一致（证实），还要看车辆是否被黑客攻击（恶意软件-附加参数），并基于这些结果计算一个可信状态（信任度量），最终决定是否将数据用于D1的地图更新（集成）。

---

#### 四、 总结陈词（用于诉状核心理由）

无效决定主要存在以下错误，应予撤销：

1.  **事实认定错误：** 决定错误地认为证据6未公开“附加信任参数”。事实上，证据6第[0005]、[0020]段明确公开了检测“恶意软件”和“网络攻击”，第[0002]段公开了比对“上下文信息”，这些均是独立于“传感器证实”之外的附加信任参数。
2.  **事实认定错误：** 决定错误地认为证据6未公开“基于多参数确定信任度量并集成”。事实上，证据6第[0003]、[0026]段公开了基于模型生成值、比较阈值并标记为“已验证/值得信赖”（即确定信任度量），第[0005]段公开了仅在验证通过时“存储在数据库”（即集成），否则“丢弃”。
3.  **法律适用错误：** 在证据1提出了数据可信度筛选的需求（统计加权、可信车辆），而证据6提供了包含“证实+附加参数（恶意软件检测）”的完整验证方案的情况下，两者结合得到权利要求1的技术方案是显而易见的。决定割裂了证据6的整体技术方案，仅承认其公开了“证实”，而无视了其同时公开的配套验证逻辑（附加参数+阈值判定+存储机制），导致得出了错误的非显而易见性结论。

因此，权利要求1相对于证据1结合证据6不具备专利法第22条第3款规定的创造性。

这是一个非常敏锐且关键的法律逻辑问题。你的直觉是正确的：**无效决定中关于“D6必须至少公开两个信任参数”的要求，确实存在逻辑上的混淆，并且涉嫌错误解释了权利要求的保护范围，属于适用法律错误。**

这个点如果打得准，可以直接推翻无效决定的逻辑基础。

以下是针对这一“矛盾点”的专业严谨分析，请将其加入你的行政诉讼代理意见中：

### 关于无效决定错误解释权利要求、提高创造性门槛的法律分析

**核心观点：**
无效决定中认为证据6未公开“使用至少两个信任参数确定信任度量”从而否定创造性，这一推论存在双重错误：
1.  **错误解释权利要求范围（逻辑矛盾）：** 权利要求1仅要求“一个或多个”附加信任参数，决定中隐含要求“至少两个”属于擅自缩小权利要求保护范围，提高了现有技术的结合门槛。
2.  **错误适用创造性判断原则（割裂结合）：** 决定承认D1公开了一个参数，D6公开了证实（另一源），两者结合本已满足权利要求要求，但决定却强行要求D6必须**独自**公开“两个参数+集成逻辑”，这是对“多份对比文件结合”原则的错误适用。

#### 一、 权利要求1的逻辑结构解析

权利要求1关于确定信任度量的逻辑是：
> **条件A：** 基于...是否与来自另一个源的LDM数据相证实（Corroboration）；
> **AND**
> **条件B：** 基于**一个或多个**附加信任参数（Additional Trust Parameters）。

**逻辑公式：** 信任度量 = f(证实, 附加参数≥1)。

**结论：** 只要现有技术中存在“证实”机制，并且存在“至少一个”附加信任参数，且两者被结合用于确定信任度，就落入了权利要求1的保护范围。

#### 二、 无效决定的逻辑矛盾分析

**无效决定的原文回顾：**
> “...证据 6 并未公开上述使用**至少两个信任参数**确定信任度量...因此证据 1 和证据 6 均未公开使用至少两个信任参数确定信任度量...”

**错误点 1：偷换概念，擅自修改权利要求界定**
*   **分析：** 权利要求1原文写的是“基于...相证实...以及基于**一个或多个**附加信任参数”。
    *   如果决定中的“至少两个信任参数”是指“证实+1个附加参数”，那么D1（1个附加参数）+ D6（证实）显然已经满足了数量要求（1+1=2）。
    *   如果决定中的“至少两个信任参数”是指“2个附加参数”，那么这直接**违反了权利要求1中“一个或多个”的界定**。专利法并不要求必须有两个附加参数，只要有一个即可。决定以此为由否定D6的公开性，属于错误地提高了创造性判断的标准。

**错误点 2：无视D1与D6的叠加效应（割裂式对比）**
*   **事实：**
    *   决定**承认**：D1公开了“可信车辆”作为**一个信任参数**。
    *   决定**承认**：D6公开了“另一个源的验证（证实）”。
*   **逻辑推演：**
    *   本领域技术人员将D6的“证实机制”引入到D1中。
    *   结合后的系统拥有：D1的“可信车辆（参数1）” + D6的“证实（另一个源）”。
    *   这完全满足权利要求1的“证实 + 一个附加参数”的要求。
*   **决定的谬误：**
    决定却以“D6并未公开上述使用至少两个信任参数...”为由，否定了结合的可能性。这隐含了一个错误的逻辑前提：即要求**D6必须独自公开**权利要求1的所有区别特征（即D6必须自己就有两个参数且有集成逻辑）。
    **法律反驳：** 在创造性判断中，区别特征可以由D6和D1共同贡献，或者由D6补足D1的缺陷。既然D1已经有了一个参数，D6只需要提供“证实机制”和“基于验证结果进行集成”的逻辑即可。决定强行要求D6“单打独斗”完成所有特征的披露，违反了《专利审查指南》关于显而易见性的判断原则。

#### 三、 结合D6实际内容的深度打击（事实与逻辑的双重错误）

退一步讲，即便按照无效决定那“苛刻且错误”的标准——即要求D6必须公开“至少两个参数”，决定依然是**事实认定错误**的。

**证据6（D6）实际上公开了多个参数：**
正如之前分析的，证据6不仅公开了“传感器证实（另一个源）”，还公开了：
1.  **“恶意软件检测”**（附加参数1，D6 [0005], [0020]）；
2.  **“上下文信息比对”**（附加参数2，D6 [0002]）。

**致命一击：**
*   决定声称D6未公开“至少两个参数”。
*   **事实是：** D6公开了 **证实 + 恶意软件检测 + 上下文比对**。
*   这不仅满足了权利要求1的“一个或多个”，甚至满足了决定自己设定的“至少两个”的错误标准。

#### 四、 总结与诉讼策略建议

在撰写诉状时，建议采用以下逻辑链条：

1.  **前提：** 权利要求1仅要求“证实”+“至少1个附加参数”。
2.  **第一重错误（逻辑错误）：** 决定承认D1有“可信车辆（参数）”，D6有“证实”。两者结合（D1+D6）在逻辑上已经满足了权利要求的要素。决定以“D6未公开使用至少两个参数”为由拒绝结合，是割裂了现有技术的整体性，忽略了D1已有的贡献。
3.  **第二重错误（标准错误）：** 若决定意指必须有“两个附加参数”，则属于错误解释权利要求，违反了权利要求“一个或多个”的明确限定。
4.  **第三重错误（事实错误 - 兜底绝杀）：** 即使完全顺着决定的逻辑（要求D6必须有多个参数），决定也犯了基本的事实认定错误。D6明确记载了“恶意软件检测”和“上下文信息”作为验证维度的参数。因此，无论从法律逻辑还是事实查明角度，该决定都站不住脚。

**结论：**
无效决定中关于“D6必须公开至少两个信任参数”的要求，既与权利要求1的“一个或多个”相**矛盾**，也违反了创造性判断中多份证据**结合**的基本原则，同时还伴随着对D6内容的**事实认定遗漏**。这三个错误叠加，足以推翻该无效决定。

这是一个非常棒的反击角度。针对对方可能提出的“逻辑耦合”攻击（即声称权利要求1要求一种特定的、复杂的数学算法将两个参数融合，而D6只是松散的步骤），**目标专利说明书中有非常强有力的内容可以用来驳斥这种“不当缩小权利要求范围”的观点。**

你需要向法院证明：**说明书对“信任度量”和“确定过程”的定义非常宽泛，完全涵盖了证据6那种“多步骤验证最终得出一个结论”的逻辑。**

以下是具体的说明书支持点及法律分析，请加入你的代理意见：

### 针对“逻辑耦合”攻击的说明书支持分析

**核心反驳逻辑：**
对方试图将“基于A和B确定信任度量”解释为一种复杂的、并行的数学运算（如加权求和）。但**本专利说明书明确记载，“信任度量”可以仅仅是一个“等级（Level）”或“判定结果（Determination）”，且计算方式是基于多个“因素（Factor）”的综合影响。** 因此，D6中“先检查A，再检查B，最终标记为已验证（即高信任度）”的过程，完全落入说明书定义的保护范围。

#### 支持点一：说明书定义了“信任度量”可以是定性的“等级”

*   **说明书原文（对应 [0163] 段）：**
    > “在一些实施例中，信任度量可以表示接收的LDM数据的**可信度得分（trustworthiness score）**或**可信度等级（confidence level）**。……信任度量可以包括**信任图**或另一类似的可信度得分。”

*   **反驳逻辑：**
    1.  说明书明确指出，信任度量不一定是非要是一个连续的数值（如0-100分），它可以是一个**“可信度等级”**（例如：高/中/低，或者 值得信赖/不可信）。
    2.  **对应D6：** 证据6第[0026]段记载将信息**“标记/标签为已验证、已认证、值得信赖、有效”**。这种“标签（Label）”或“标记（Flag）”在技术上完全等同于本专利说明书所述的“可信度等级”。
    3.  **结论：** 对方如果声称D6的“标记”不是“度量”，就是违反说明书定义的错误解释。

#### 支持点二：说明书定义了“信任参数”可以是独立的“确定（Determination）”

*   **说明书原文（对应 [0164] 段）：**
    > “处理器可以基于多个因素和/或确定来确定信任度量，其中每一个这样的因素和/或确定可以增加或减少总体信任度量。**每个这样的因素或确定在此被称为‘信任参数’**。”

*   **反驳逻辑：**
    1.  说明书给出的定义极宽：任何能影响最终信任判断的“因素（Factor）”或“确定（Determination）”都是信任参数。
    2.  **逻辑耦合的松散性：** 说明书承认这些参数是**“每一个这样的因素（each such factor）”**。这意味着，系统可以像列清单一样逐个检查这些因素。
    3.  **对应D6：** 
        *   D6中的“传感器比对”是一个因素（确定是否一致）。
        *   D6中的“恶意软件检查”是另一个因素（确定是否安全）。
        *   这两个因素共同导致了最终的“标记为已验证（高信任度）”。
    4.  **结论：** 只要这两个因素都参与了最终结果的产出，就符合说明书关于“基于多个因素确定信任度量”的描述。说明书**从未**要求必须将所有参数代入同一个数学公式（如 $Y = aX1 + bX2$）进行计算。逻辑与（AND）关系（即：通过证实 AND 未感染恶意软件 = 信任）也是一种确定信任度量的方式。

#### 支持点三：说明书列举的参数本质上是离散的、布尔型的

*   **说明书原文（对应 [0165] 段）：**
    > “...处理器可以评估与接收LDM数据的通信链路相关的一个或多个因素。此类因素可以包括，例如，**连接类型**（蜂窝通信通常比蓝牙或Wi-Fi通信更可信）... **通信链路安全级别**（例如，加密与非加密...）... **源设备是否向网络注册**...”

*   **反驳逻辑：**
    1.  说明书中列举的很多参数是**布尔型（Yes/No）**或**分类型**的。例如“是否加密”、“是否注册”。
    2.  对于这类参数，工程上最常见的处理方式就是**逻辑门判断（Logical Gating）**或**条件分支**，而不是复杂的加权公式。
        *   例如：如果未注册 -> 信任度=0；如果已注册 -> 检查下一步。
    3.  **对应D6：** D6的逻辑正是这种典型的工程实现：如果未通过传感器证实 -> 丢弃；如果通过 -> 检查恶意软件 -> 通过 -> 标记为可信。这种**串行筛选机制**完全符合说明书对于处理离散型信任参数的教导。
    4.  **结论：** 对方攻击D6是“串行检查”而非“逻辑耦合”，这是站不住脚的。因为本专利说明书所列举的参数性质（如是否加密、是否注册），决定了串行检查是本领域最合理的实施方式之一。本专利并未排除串行逻辑。

#### 支持点四：说明书并未限定具体的计算算法

*   **通篇审查：**
    说明书第[0162]-[0165]段（即描述图15流程的段落）**没有任何地方**公开具体的数学公式、权重系数表或复杂的融合算法。它只说“基于...确定”。

*   **法律推论：**
    1.  如果专利权人现在声称权利要求1要求一种“特定紧密耦合的算法”，那么根据**“公开换保”**原则，由于说明书并未公开该特定算法，该权利要求将因**公开不充分**或**得不到说明书支持**而无效。
    2.  为了维持专利有效，专利权人必须承认“基于...确定”涵盖了广泛的实现方式，包括简单的逻辑组合。
    3.  既然涵盖了简单的逻辑组合，那么D6的“证实 + 恶意软件检查 -> 确认可信”就必然落入该范围。

### 诉讼策略总结

在法庭上，你可以这样陈述：

> “审判长，被告声称权利要求1要求一种特殊的、紧密耦合的计算方式，而D6只是松散的步骤。这种观点**直接违背了本专利说明书的记载**。
>
> 请看说明书第[0163]段，专利权人明确定义‘信任度量’可以是‘可信度等级’。
> 请看说明书第[0165]段，列举的参数包括‘是否注册’、‘是否加密’等布尔型特征。
>
> 对于这类特征，**逻辑叠加（例如：既要注册，又要加密，还要数据一致）是本领域最常规的‘确定’方式。**
>
> 证据6（D6）正是采用了这种逻辑：既要通过传感器证实（参数A），又要通过恶意软件检测（参数B），最终才标记为‘值得信赖’（即信任度量）。这完全符合说明书的定义。
>
> 如果被告坚持认为权利要求1要求一种D6所不具备的‘特殊复杂算法’，请被告指出说明书中哪里记载了这种算法？如果指不出，那就是被告在**事后虚构技术特征，试图不当缩小权利要求范围**以规避现有技术。这在法律上是不允许的。”

权利要求1要求保护一种由边缘计算设备执行的用于生成本地动态地图(LDM)数据的方法。对比文件1(US2018299274A1，说明书第11-47段及图1-5)公开了一种用于自主导航的地图的实时更新，其实际涉及一种由边缘计算设备执行的用于生成本地动态地图(LDM)数据的方法，包括:网络接口可以用于与给定的RSU进行通信，每个RSU被配置为存储基础图，云服务器可以在某个时间点将基图递送到RSU中，且为自适应边缘计算（即公开接收所述边缘计算设备的服务区域的第一LDM 数据）﹔将所述基础地图动态数据集成到LDM数据模型中;在420处，RSU从邻居RSU接收用于扩增map 的数据;在422处，RSU基于数据更新所选择的地图(或地图的类型）以扩增地图以获得更新的地图（即公开确定所述LDM数据模型的、与移动设备相关的第二LDM数据)﹔以及将所确定的扩增与新增地图动态数据提供给所述移动设备。由此可见，权利要求1所要求保护的技术方案与对比文件1所公开的内容相比，仅仅是文字表达方式上略有差别，技术方案实质上是相同的，且两者均属于相同的动态地图生成方法的领域，能够解决相同的技术问题，并能产生相同的效果。因此，权利要求1不具备专利法第22条第⒉款规定的新颖性。

技术特征：

接收所述边缘计算设备的服务区域的第一LDM数据，

其中所述第一LDM数据包括在阈值时间量内获得的高度动态的信息的数据；

基于所接收的所述第一LDM数据是否与来自另一个源的LDM数据相证实以及基于一个或多个附加信任参数，确定所接收的所述第一LDM数据的信任度量；

响应于确定所述信任度量超过所述信任度量阈值，将所述第一LDM数据集成到LDM数据模型中；

确定所述LDM数据模型的、与移动设备相关的第二LDM数据，其中所述第二LDM数据包括在所述阈值时间量内获得的高度动态的信息的数据；

以及将所确定的第二LDM数据提供给所述移动设备。

对比文件US2018299274A1记载：

[0009] 本文介绍了用于更新自动驾驶车辆导航所用详细地图的技术。该技术包括确定车辆进入道路旁单元的预定范围内，与车辆建立通信链接，从车辆接收足以识别车辆类型的数据，根据车辆类型选择道路旁单元存储的地图，为增强地图向邻近道路旁单元发送查询，响应查询从邻近道路旁单元接收增强地图的数据，基于数据更新地图以获取更新后的地图，并将更新后的地图的至少部分内容发送到车辆。

[0011] 图1展示了用于维护自动驾驶车辆的更新地图和相关信息的场景100及网络组件，符合一个示例性实施例。具体来说，在该示例性实施例中，场景100包括一个路口110。几辆车辆105a (V1), 105b (V2), 105c (V3) 出现在道路上。在路口110附近和沿着道路（例如，临近、上方）部署了多个道路旁单元（RSUs） 300a, 300b, 300c。每个RSU还与中央或云服务器150以及一个或多个外部传感器或信息提供者160通信。云服务器150可配置为对RSUs进行总体控制，以及实现地图生成和分发。也就是说，云服务器150可以作为RSUs的管理员和地图生成处理器，或者至少提供数据以便RSUs在本地生成地图。

[0030] 传送给车辆105d的地图偏差数据集可以取决于（1）车辆的位置、（2）当前方向（例如速度）和车辆类型，以及（3）预期或预计的下一步驾驶轨迹。根据上下文（如位置、方向、速度、预期轨迹等），可以传送诸如交通的动态信息覆盖层。这种上下文在“边缘”，即在RSU网络层面上，尤其相关和可扩展，而不是在云服务器150层面上。

[0047] 在502，RSU从一辆或多辆车接收数据或遥测信息。例如，如上所述，RSU可能从激光器、摄像机、雷达单元等处接收信息。在504，RSU处理数据或遥测信息，以检测一个或多个物体及其一个或多个特征（如位置、大小、颜色、运动等）。在506，对于每个检测到的物体，RSU将其一个或多个特征与其存储的地图进行比较。例如，静止物体的位置或大小特征可与地图中的物体位置进行比较。在508，RSU对一个或多个特征的比较值确定偏差值。偏差值可以基于百分比偏差，最小或最大偏差等。在510，RSU确定偏差值是否在相关特征的阈值范围内。这些阈值可由管理员确定，并且不同类型的物体可能有不同的阈值。如果偏差值在阈值内，将从车辆收集更多数据以进行处理。如果在510，偏差值不在相关阈值范围内，RSU，即地图更新逻辑332，将更新其地图。在514，RSU将更新后的地图或地图偏差数据集发送到云服务器150。那些熟悉此领域技术的人士应该理解，同样的更新地图或地图偏差数据集也可以与邻近的RSU和车辆共享。

以上内容公开技术特征“接收所述边缘计算设备的服务区域的第一LDM数据”

[0012] 尽管图1中未展示，相关技术人员会明白，场景100可能包括其他许多元素，例如车道标记（白线，黄线等）、路缘、护栏、公路隔离带、建筑物、树木、停放的汽车、行人、道路施工现场、停车标志、交通信号灯等。这些特征都可以成为生成和供应给车辆的详细地图的一部分。

[0028] 当另一辆例如105d的车辆进入RSU 300b覆盖的区域时，车辆105d将与RSU 300b通信，以验证该车辆当前存储的基础地图与RSU中存储的基础地图是否匹配。例如，可以通过车辆向RSU 300b发送存储在车辆105d中的基础地图的哈希值来完成这种比较。RSU 300b然后可以确认基础地图是否匹配。然后，RSU 300b可以基于RSU 300b先前从早些经过的车辆105b接收到的信息，向车辆105d发送例如一个地图偏差数据集。也就是说，RSU 300b可能向车辆105d发送一组信息，描述存储在车辆105d中的基础地图与RSU最近生成的更新地图之间的差异。值得注意的是，由于偏差数据集通常比完整地图的数据量少，因此车辆从RSU 300b获取地图偏差数据集所需的传输时间少于传送完整地图所需的时间。

以上内容公开技术特征“其中所述第一LDM数据包括在阈值时间量内获得的高度动态的信息的数据；”

[0048] 还应注意，地图更新不需要从所有车辆接收遥测数据。传感数据可以限制为某些“可信车辆”，例如公共交通工具（如公交车、轻轨列车）、警车、消防车等。或者，RSU可以配置为对从车辆接收到的遥测数据进行统计加权，并且这种加权可能在接收到超过阈值数量的车辆的遥测数据之前不会开始。对于那些过去数据一贯准确的选定车辆可能给予更高权重。此外，可以由例如云服务器150提供较少的瞬变更改，从而减轻需要向每辆车提供频繁更新的需求。也就是说，云服务器150可以负责在场景或环境发生重大非瞬变更改时分发新的基础地图。

以上内容公开技术特征“基于所接收的所述第一LDM数据是否与来自另一个源的LDM数据相证实以及基于一个或多个附加信任参数，确定所接收的所述第一LDM数据的信任度量；”

[0047] 在502，RSU从一辆或多辆车接收数据或遥测信息。例如，如上所述，RSU可能从激光器、摄像机、雷达单元等处接收信息。在504，RSU处理数据或遥测信息，以检测一个或多个物体及其一个或多个特征（如位置、大小、颜色、运动等）。在506，对于每个检测到的物体，RSU将其一个或多个特征与其存储的地图进行比较。例如，静止物体的位置或大小特征可与地图中的物体位置进行比较。在508，RSU对一个或多个特征的比较值确定偏差值。偏差值可以基于百分比偏差，最小或最大偏差等。在510，RSU确定偏差值是否在相关特征的阈值范围内。这些阈值可由管理员确定，并且不同类型的物体可能有不同的阈值。如果偏差值在阈值内，将从车辆收集更多数据以进行处理。如果在510，偏差值不在相关阈值范围内，RSU，即地图更新逻辑332，将更新其地图。在514，RSU将更新后的地图或地图偏差数据集发送到云服务器150。那些熟悉此领域技术的人士应该理解，同样的更新地图或地图偏差数据集也可以与邻近的RSU和车辆共享。

 [0048] 还应注意，地图更新不需要从所有车辆接收遥测数据。传感数据可以限制为某些“可信车辆”，例如公共交通工具（如公交车、轻轨列车）、警车、消防车等。或者，RSU可以配置为对从车辆接收到的遥测数据进行统计加权，并且这种加权可能在接收到超过阈值数量的车辆的遥测数据之前不会开始。对于那些过去数据一贯准确的选定车辆可能给予更高权重。此外，可以由例如云服务器150提供较少的瞬变更改，从而减轻需要向每辆车提供频繁更新的需求。也就是说，云服务器150可以负责在场景或环境发生重大非瞬变更改时分发新的基础地图。

响应于确定所述信任度量超过所述信任度量阈值，将所述第一LDM数据集成到LDM数据模型中；

[0012] 尽管图1中未展示，相关技术人员会明白，场景100可能包括其他许多元素，例如车道标记（白线，黄线等）、路缘、护栏、公路隔离带、建筑物、树木、停放的汽车、行人、道路施工现场、停车标志、交通信号灯等。这些特征都可以成为生成和供应给车辆的详细地图的一部分。

[0022] 数据234还可以包括交通模式模型信息238，例如详细模型，指示在地图236的位置的典型或预期速度、轨迹、位置、加速/减速（速度变化）或其他此类车辆或其他移动对象的特性。这个数据例如可以通过观察车辆、行人、自行车等在地图236的不同位置的移动方式生成。也就是说，交通模式模型信息238的数据可能基于长期观察和学习交通模式生成。

[0028] 当另一辆例如105d的车辆进入RSU 300b覆盖的区域时，车辆105d将与RSU 300b通信，以验证该车辆当前存储的基础地图与RSU中存储的基础地图是否匹配。例如，可以通过车辆向RSU 300b发送存储在车辆105d中的基础地图的哈希值来完成这种比较。RSU 300b然后可以确认基础地图是否匹配。然后，RSU 300b可以基于RSU 300b先前从早些经过的车辆105b接收到的信息，向车辆105d发送例如一个地图偏差数据集。也就是说，RSU 300b可能向车辆105d发送一组信息，描述存储在车辆105d中的基础地图与RSU最近生成的更新地图之间的差异。值得注意的是，由于偏差数据集通常比完整地图的数据量少，因此车辆从RSU 300b获取地图偏差数据集所需的传输时间少于传送完整地图所需的时间。

[0030] 传送给车辆105d的地图偏差数据集可以取决于（1）车辆的位置、（2）当前方向（例如速度）和车辆类型，以及（3）预期或预计的下一步驾驶轨迹。根据上下文（如位置、方向、速度、预期轨迹等），可以传送诸如交通的动态信息覆盖层。这种上下文在“边缘”，即在RSU网络层面上，尤其相关和可扩展，而不是在云服务器150层面上。

[0031] 例如，如果一辆车辆在一条道路上向北行驶，最有价值的信息可能与向南行驶相关的信息不同。同样，当车辆接近一个交叉路口时，最有价值的信息取决于（a）它来自何处以及（b）它要去哪里，例如，向北行驶（从南面来）并计划在交叉口右转。因此，当车辆与RSU 300通信时，车辆可以提供此类信息，使得RSU 300能够向车辆提供最合适的信息。

[0033] 图4是一个流程图，描述了示例实施例中由路边单元300操作的地图更新逻辑332可以执行的一系列操作。在410，RSU确定一辆车辆进入预定范围内。在412，RSU与车辆建立通信链接。在414，RSU从车辆接收足够识别车辆类型的数据（或其行进位置，或与车辆相关的其他信息）。这一步可能还包括获取车辆存储的地图类型/版本以确定基础地图。在416，基于车辆类型（或其他特征），RSU选择存储在路边单元中的地图。选择地图可以包括，例如，选择基础地图中最相关于该类型车辆或该车辆预定行驶路径的内容。在418，RSU向邻近的RSU发送查询，寻求数据来增强所选地图（或地图类型）。在420，RSU从邻近的RSU接收增强地图的数据。在422，RSU基于增强地图数据更新所选地图（或地图类型），以获得更新后的地图。在424，RSU将至少一部分更新地图发送给车辆。也就是说，RSU将地图偏差数据集发送给车辆或将完整的更新地图发送给车辆。

[0047] 在502，RSU从一辆或多辆车接收数据或遥测信息。例如，如上所述，RSU可能从激光器、摄像机、雷达单元等处接收信息。在504，RSU处理数据或遥测信息，以检测一个或多个物体及其一个或多个特征（如位置、大小、颜色、运动等）。在506，对于每个检测到的物体，RSU将其一个或多个特征与其存储的地图进行比较。例如，静止物体的位置或大小特征可与地图中的物体位置进行比较。在508，RSU对一个或多个特征的比较值确定偏差值。偏差值可以基于百分比偏差，最小或最大偏差等。在510，RSU确定偏差值是否在相关特征的阈值范围内。这些阈值可由管理员确定，并且不同类型的物体可能有不同的阈值。如果偏差值在阈值内，将从车辆收集更多数据以进行处理。如果在510，偏差值不在相关阈值范围内，RSU，即地图更新逻辑332，将更新其地图。在514，RSU将更新后的地图或地图偏差数据集发送到云服务器150。那些熟悉此领域技术的人士应该理解，同样的更新地图或地图偏差数据集也可以与邻近的RSU和车辆共享。

上述内容公开了技术特征“确定所述LDM数据模型的、与移动设备相关的第二LDM数据，其中所述第二LDM数据包括在所述阈值时间量内获得的高度动态的信息的数据；”

[0030] 传送给车辆105d的地图偏差数据集可以取决于（1）车辆的位置、（2）当前方向（例如速度）和车辆类型，以及（3）预期或预计的下一步驾驶轨迹。根据上下文（如位置、方向、速度、预期轨迹等），可以传送诸如交通的动态信息覆盖层。这种上下文在“边缘”，即在RSU网络层面上，尤其相关和可扩展，而不是在云服务器150层面上。

[0031] 例如，如果一辆车辆在一条道路上向北行驶，最有价值的信息可能与向南行驶相关的信息不同。同样，当车辆接近一个交叉路口时，最有价值的信息取决于（a）它来自何处以及（b）它要去哪里，例如，向北行驶（从南面来）并计划在交叉口右转。因此，当车辆与RSU 300通信时，车辆可以提供此类信息，使得RSU 300能够向车辆提供最合适的信息。

[0032] 因此，在即时实施例中，一旦给定的RSU 300了解车辆下一步可能去的地方，或确定其自身存储的地图中可能缺少的信息，RSU可以与邻近的RSU通信和查询，以获取进一步的地图数据来更新其地图，然后将更新的地图或地图偏差数据集传递给车辆。

[0033] 图4是一个流程图，描述了示例实施例中由路边单元300操作的地图更新逻辑332可以执行的一系列操作。在410，RSU确定一辆车辆进入预定范围内。在412，RSU与车辆建立通信链接。在414，RSU从车辆接收足够识别车辆类型的数据（或其行进位置，或与车辆相关的其他信息）。这一步可能还包括获取车辆存储的地图类型/版本以确定基础地图。在416，基于车辆类型（或其他特征），RSU选择存储在路边单元中的地图。选择地图可以包括，例如，选择基础地图中最相关于该类型车辆或该车辆预定行驶路径的内容。在418，RSU向邻近的RSU发送查询，寻求数据来增强所选地图（或地图类型）。在420，RSU从邻近的RSU接收增强地图的数据。在422，RSU基于增强地图数据更新所选地图（或地图类型），以获得更新后的地图。在424，RSU将至少一部分更新地图发送给车辆。也就是说，RSU将地图偏差数据集发送给车辆或将完整的更新地图发送给车辆。

上述内容公开技术特征“以及将所确定的第二LDM数据提供给所述移动设备。”

方案2：对比文件us2018051998A1与该专利领域相同，解决的技术问题相同，取得的技术效果也相同属于最接近的现有技术。

对比文件us2018051998A1全文公开：

[0016] 根据一个实施例，来自大量车辆或其他数据源的驾驶数据存储在连接车辆中并上传到网络。例如，车辆可以使用车辆传感器获取驾驶环境数据，并将这些数据或任何派生数据上传到云存储位置。用户可以通过网络使用连接设备（如车辆、计算系统、智能手机等）访问云存储位置，并下载相关数据到车辆中。这些数据可以本地存储在车辆的地图数据库中，并运行路线算法以优化车辆在相关路线上的行为。

[0018] 根据一个示例性实施例，车道线或车道标记质量对辅助驾驶功能或自动驾驶功能可能很重要。地图数据库或驾驶历史数据库可以存储车道线质量的一些指标。例如，车道线/标记质量可以由车辆本地存储，或作为聚合数据的一部分上传存储。地图数据库和/或驾驶历史数据库可以基于云，在车辆制造时加载到车辆上，和/或由车辆根据探测或传感器数据创建和更新。使用地图或驾驶历史数据库，可以执行路线算法，评估并优先考虑基于最低成本的路线。与车道线质量相关的一个示例成本项是：

J = Σ(i=1到n)(1 - Qi)，

其中Qε{0,1}是车道质量的布尔指标（0表示车道质量差，1表示车道质量好）。在一个实施例中，地图数据库或驾驶历史数据库可能包括除道路车道线质量外的指标，如道路曲率、道路车道线几何形状、道路车道线/标记类型（如单线、双线、虚线、反光标识或其他车道标记类型的指示）和/或道路车道线/标记颜色（如白色、黄色或其他颜色的指示）。在一实施例中，路线算法可能考虑这些额外的指标或其他指标，在优先考虑路线时。例如，路线算法可能考虑其他成本，如最短距离、最快行驶时间、交通状况等，以基于各种成本因素找到最佳全方位路线。在一个实施例中，出于路线目的确定的线质量成本可能是一个动态函数，考虑天气和交通因素。例如，一些类型的车道标记可能根据一天中的时间或天气条件，对于车辆传感器来说更易见或更难检测。

[0027] 在一个实施例中，摄像系统210可能包括多个摄像头。例如，摄像系统210可能包括面向不同方向的摄像头，以提供车辆附近或周围区域的不同视角和视场。同样，雷达系统206、激光雷达系统208和/或超声波系统214可能包括多个传感器，从车辆周围的不同方向获取数据，以提供关于母车周围环境的详细信息。在一个实施例中，这些数据可以上传进行远程存储，例如通过一个或多个聚合服务器102。

[0029] 地图数据库306包括由一个或多个车辆的车载传感器生成的车辆数据，以及来自传感器如基础设施传感器或图1中的其他数据源106的基础设施/环境数据。地图数据库306可以向聚合网络308上传数据和/或从聚合网络308下载数据。聚合网络308可能包括一个或多个聚合服务器102。例如，地图数据库306可以位于车辆内，并与聚合网络共享收集的车辆或基础设施数据，以便其他车辆可以访问和使用该数据。同样，地图数据库306也可以从聚合网络308下载数据，以利用基于大量贡献车辆或数据源的数据聚合。例如，地图数据库306可以维护一份聚合网络308存储的聚合数据的同步副本，用于车辆附近区域或车辆行驶路线上的数据。聚合数据可以与其他地图数据或驾驶历史数据一起存储，以供路由算法304使用。

[0044] 成本组件608被配置为确定由路线组件602确定的每条路线的路线成本和/或由分类组件606确定的可靠性或类别的路线成本。例如，成本组件608可能基于驾驶数据聚合来确定基于自动驾驶功能或驾驶辅助功能可靠性的路线成本。成本组件608可能基于感知系统、控制系统和/或车辆类型，来确定路线成本。成本组件608可能基于预测的功能可靠性（基于聚合或本地数据）与任何其他路线成本结合来确定路线成本。其他路线成本示例包括当前的交通状况、当前的天气条件、路线总驾驶时间、路线总距离等。在一个实施例中，成本组件608可能确定每段道路的功能可靠性成本，并将这些成本相加以计算整个路线的总体功能可靠性成本。在一个实施例中，道路段或路线的功能可靠性成本可能取决于当前天气或当前交通。

以上内容公开一种由边缘计算设备执行的用于生成本地动态地图（LDM）数据的方法。

[0016] 根据一个实施例，来自大量车辆或其他数据源的驾驶数据存储在连接车辆中并上传到网络。例如，车辆可以使用车辆传感器获取驾驶环境数据，并将这些数据或任何派生数据上传到云存储位置。用户可以通过网络使用连接设备（如车辆、计算系统、智能手机等）访问云存储位置，并下载相关数据到车辆中。这些数据可以本地存储在车辆的地图数据库中，并运行路线算法以优化车辆在相关路线上的行为。

[0027] 在一个实施例中，摄像系统210可能包括多个摄像头。例如，摄像系统210可能包括面向不同方向的摄像头，以提供车辆附近或周围区域的不同视角和视场。同样，雷达系统206、激光雷达系统208和/或超声波系统214可能包括多个传感器，从车辆周围的不同方向获取数据，以提供关于母车周围环境的详细信息。在一个实施例中，这些数据可以上传进行远程存储，例如通过一个或多个聚合服务器102。

以上内容公开接收所述边缘计算设备的服务区域的第一LDM数据

[0016] 根据一个实施例，来自大量车辆或其他数据源的驾驶数据存储在连接车辆中并上传到网络。例如，车辆可以使用车辆传感器获取驾驶环境数据，并将这些数据或任何派生数据上传到云存储位置。用户可以通过网络使用连接设备（如车辆、计算系统、智能手机等）访问云存储位置，并下载相关数据到车辆中。这些数据可以本地存储在车辆的地图数据库中，并运行路线算法以优化车辆在相关路线上的行为。

[0018] 根据一个示例性实施例，车道线或车道标记质量对辅助驾驶功能或自动驾驶功能可能很重要。地图数据库或驾驶历史数据库可以存储车道线质量的一些指标。例如，车道线/标记质量可以由车辆本地存储，或作为聚合数据的一部分上传存储。地图数据库和/或驾驶历史数据库可以基于云，在车辆制造时加载到车辆上，和/或由车辆根据探测或传感器数据创建和更新。使用地图或驾驶历史数据库，可以执行路线算法，评估并优先考虑基于最低成本的路线。与车道线质量相关的一个示例成本项是：

J = Σ(i=1到n)(1 - Qi)，

其中Qε{0,1}是车道质量的布尔指标（0表示车道质量差，1表示车道质量好）。在一个实施例中，地图数据库或驾驶历史数据库可能包括除道路车道线质量外的指标，如道路曲率、道路车道线几何形状、道路车道线/标记类型（如单线、双线、虚线、反光标识或其他车道标记类型的指示）和/或道路车道线/标记颜色（如白色、黄色或其他颜色的指示）。在一实施例中，路线算法可能考虑这些额外的指标或其他指标，在优先考虑路线时。例如，路线算法可能考虑其他成本，如最短距离、最快行驶时间、交通状况等，以基于各种成本因素找到最佳全方位路线。在一个实施例中，出于路线目的确定的线质量成本可能是一个动态函数，考虑天气和交通因素。例如，一些类型的车道标记可能根据一天中的时间或天气条件，对于车辆传感器来说更易见或更难检测。

[0021] 路线优化组件112可访问数据存储器114中的聚合数据以优化路线或向一个或多个车辆104提供聚合数据。例如，车辆104可能使用聚合数据向驾驶员或控制系统116提供有关未来驾驶路径的信息，以优化车辆104的驾驶。车辆104还可以积累驾驶数据，包括关于道路或驾驶环境的任何信息，并将积累的驾驶数据发送到聚合服务器102进行存储或聚合。其他数据来源106也可以上传数据到聚合服务器102进行聚合。其他数据源106可能包括用于基础设施的系统或传感器，如交通摄像头、车辆或交通传感器、天气传感器等。在一个实施例中，路线优化组件112可确定优先考虑驾驶路线的驾驶路线，基于自动驾驶或辅助驾驶是否对车辆可用。在一个实施例中，路线优化组件112可以位于一个或多个车辆104中，如车辆的控制系统116中。例如，路线优化组件112可以在车辆104上本地操作，并结合本地存储的驾驶历史数据和/或地图数据使用数据存储器114中的聚合数据。

[0035] 图5A和图5B展示了示例的车道标线质量。图5A展示了高质量车道标线502的顶视图。例如，车道标线502具有清晰的边界，直线和锐角，从而为自动驾驶系统或驾驶辅助系统提供高质量。车道标线502还可能具有高对比度的路面，高度清晰的几何形状，以及可以轻易被自动驾驶系统或驾驶辅助系统检测到的厚度。图5B展示了低质量车道标线504的顶视图。例如，车道标线504可能是褪色或磨损的油漆，主要由细线宽组成，或其他难以被自动驾驶或驾驶辅助系统检测到的情况。在车道标线高质量的道路上行驶的车辆（类似于图5A中的车道标线502），可能存储该道路具有高质量车道标线502的指示，并可能将高质量车道标线的指示上传至网络位置，被存储为聚合数据，供以后及其他车辆访问。在车道标线低质量的道路上行驶的车辆（类似于图5B中的车道标线504），可能存储该道路具有低质量车道标线504的指示，并可能将低质量车道标线的指示上传至网络位置，被存储为聚合数据，供以后及其他车辆访问。进一步来说，车辆还可能检测到不存在车道标线或仅包括反光车道标线的情况。例如，当不存在车道标线或仅包括反光车道标线时，某些自动驾驶系统或驾驶辅助系统可能无法稳健运行。

[0036] 除了存储车道标线质量的指示，车辆还可能存储车道标线类型（油漆线和/或反光标记）的指示、车道标线颜色、车道标线几何形状等。车辆还可能存储车道标线在不同天气或时间条件下的可见性/可检测性的指示。例如，一些车道线在良好天气或白天时间内是可见的，但在恶劣天气或夜间时间内变得难以检测。车辆还可能存储道路曲率、道路陡峭程度、道路颠簸情况、当前时间段的交通水平或关于道路或驾驶环境的任何其他信息。此信息可能本地存储和/或上传至远程位置，通过通信网络访问。

以上内容公开将所述第一LDM数据集成到LDM数据模型中；

[0016] 根据一个实施例，来自大量车辆或其他数据源的驾驶数据存储在连接车辆中并上传到网络。例如，车辆可以使用车辆传感器获取驾驶环境数据，并将这些数据或任何派生数据上传到云存储位置。用户可以通过网络使用连接设备（如车辆、计算系统、智能手机等）访问云存储位置，并下载相关数据到车辆中。这些数据可以本地存储在车辆的地图数据库中，并运行路线算法以优化车辆在相关路线上的行为。

[0029] 地图数据库306包括由一个或多个车辆的车载传感器生成的车辆数据，以及来自传感器如基础设施传感器或图1中的其他数据源106的基础设施/环境数据。地图数据库306可以向聚合网络308上传数据和/或从聚合网络308下载数据。聚合网络308可能包括一个或多个聚合服务器102。例如，地图数据库306可以位于车辆内，并与聚合网络共享收集的车辆或基础设施数据，以便其他车辆可以访问和使用该数据。同样，地图数据库306也可以从聚合网络308下载数据，以利用基于大量贡献车辆或数据源的数据聚合。例如，地图数据库306可以维护一份聚合网络308存储的聚合数据的同步副本，用于车辆附近区域或车辆行驶路线上的数据。聚合数据可以与其他地图数据或驾驶历史数据一起存储，以供路由算法304使用。

确定所述LDM数据模型的、与移动设备相关的第二LDM数据，以及将所确定的第二LDM数据提供给所述移动设备。

[0042] 分类组件606被配置为确定车辆的自动驾驶功能或辅助驾驶功能在特定道路段上是否能够稳健运行。例如，分类组件606可能基于路线组件602和/或数据组件604获取的数据，来确定操作是否可能是可靠的。在一个实施例中，分类组件606被配置为将一个或多个自动驾驶功能或车辆的驾驶辅助功能在道路段上运行的可靠性进行分类（可靠类别或不可靠类别）。在一个实施例中，分类组件606可以确定特定道路段功能的可靠性。例如，这些功能的可靠性可能在排名系统中进行评估，提供一个数值（比如1到10范围内的值）或其他值，用于指示这些功能是否高度可靠。

[0043] 分类组件606可能使用由聚合服务器102聚合的数据或车辆存储的本地数据。分类组件606还可能使用关于车辆的数据，例如车辆类型、车辆感知系统的信息或车辆控制系统的信息，来确定分类。例如，一些感知系统可能比其他系统更可靠地检测环境条件。同样，一些控制系统或车辆可能在不同环境或驾驶条件下能够更可靠地运行。另一个例子是，可靠性还可能基于人类驾驶员及其驾驶习惯以及他们希望避免的条件。因此，由分类组件606确定的可靠性可能是特定于车辆和/或车辆驾驶员的。

[0044] 成本组件608被配置为确定由路线组件602确定的每条路线的路线成本和/或由分类组件606确定的可靠性或类别的路线成本。例如，成本组件608可能基于驾驶数据聚合来确定基于自动驾驶功能或驾驶辅助功能可靠性的路线成本。成本组件608可能基于感知系统、控制系统和/或车辆类型，来确定路线成本。成本组件608可能基于预测的功能可靠性（基于聚合或本地数据）与任何其他路线成本结合来确定路线成本。其他路线成本示例包括当前的交通状况、当前的天气条件、路线总驾驶时间、路线总距离等。在一个实施例中，成本组件608可能确定每段道路的功能可靠性成本，并将这些成本相加以计算整个路线的总体功能可靠性成本。在一个实施例中，道路段或路线的功能可靠性成本可能取决于当前天气或当前交通。

[0045] 在一个实施例中，成本组件608可以根据车道标记（例如它们的存在或缺失或质量）确定路线成本。例如，本地存储或远程存储可能包括车道标记质量、车道标记几何形状、车道标记类型、车道标记颜色和/或车道标记类型（例如，油漆线或反光材料）的指示。在一个实施例中，成本组件608可以通过计算对应路线沿每段道路的车道标记质量总和来确定路线成本。成本组件608还可以基于数据组件604获取的数据和/或由分类组件606提供的分类或可靠性来确定某一段道路是否具有良好的车道标记质量。在一个实施例中，成本组件608可以确定沿路线的一段道路上的车道标记是否可被自动驾驶系统或驾驶辅助系统检测到。如果车道标记不可检测，则可能无法使用自动驾驶或辅助驾驶功能，并且在其他路线成本没有显著增加的情况下，可能需要避免这些区域。在一个实施例中，路线成本组件608根据从本地或远程存储获取的道路段中的车道标记质量指示来确定路线成本。

以上内容公开

基于所接收的所述第一LDM数据是否与来自另一个源的LDM数据相证实以及基于一个或多个附加信任参数，确定所接收的所述第一LDM数据的信任度量；响应于确定所述信任度量超过所述信任度量阈值，将所述第一LDM数据集成到LDM数据模型中；确定所述LDM数据模型的、与移动设备相关的第二LDM数据，其中所述第二LDM数据包括在所述阈值时间量内获得的高度动态的信息的数据；以及将所确定的第二LDM数据提供给所述移动设备。

由此可见us2018051998A1与公知常识的组合公开了权利要求1的全部技术特征。

对比文件JUN ZHANG ET AL: "Mobile Edge Intelligence and Computingfor the Internet of Vehicles",与该专利领域相同，解决的技术问题相同，取得的技术效果也相同属于最接近的现有技术。

对比文件JUN ZHANG ET AL: "Mobile Edge Intelligence and Computingfor the Internet of Vehicles"公开：

车辆。配备各种传感器、通信模块和具有计算和存储能力的车载单元，智能车辆是强大的节点[49]。车载计算堆栈必须同时实现高性能，功耗最小，散热低，同时成本可接受[45]。车辆能够通过V2V通信相互通信，或通过V2I通信与rsu通信。V2I通信的吞吐量通常大于V2V通信[50]。

1)车辆作为客户端(VaaC):首先，车辆可以作为客户端访问rsu或BSs的边缘资源。关键思想是将数据采集和处理放在同一位置。边缘服务器充当数据采集的锚节点，然后为本地应用程序处理数据。例如，他们可以从过往车辆收集地图数据，建立和更新HD地图，并可以主动监控当地的道路状况和交通状况。这些应用与车联网高度相关。虽然一辆车产生的数据可能有限，但每台边缘服务器都可以积累来自多辆车的大量数据，这对于训练强大的机器学习模型和车辆/交通数据分析至关重要。

2)车辆即服务器(Vehicle as a Server, VaaS):车辆也可以作为车辆乘客、第三方接收方和其他车辆的移动服务提供商。这可用于改善用户体验，例如，通过驾驶员识别实现个性化驾驶体验，并实现丰富的信息娱乐应用。与基于边缘服务器的方法相比，VaaS受移动性的影响较小。此外，它还允许相邻车辆之间的合作，例如，实现合作感知和合作驾驶，这将通过增强单个车辆的能力来实现互联智能。

业界在构建HD地图方面做出了很大的努力，例如TomTom[60]和HERE[61]。尽管如此，在实际实施中仍存在困难。制作HD地图很费时间。生成HD地图需要配备MMS (Mobile mapping System)的专用测绘车辆，整个过程包括三个步骤:数据采集获取测绘数据，数据积累积累测绘车辆获取的特征，数据确认手动对地图进行细化和确认。此外，HD地图是动态的，需要及时更新[62]，为此我们需要及时收集新鲜的HD数据，并从新鲜数据中发现变化[63]。一些HD地图供应商与汽车制造商合作，从智能车辆获取新的地图数据，但这将大大增加车辆的车载处理负担[64]。

此外，HD地图数据由于精度高、几何信息和语义丰富而具有非常大的尺寸[63]。这给传输和存储HD地图带来了困难。它们通常是从云端提供服务的，附近的几个小区域的地图下载到车辆上。厘米级精度的三维HD地图需要下载的数据量可以达到每公里3 ~ 4gb。这不仅给从云端下载数据带来了延迟，也给骨干网带来了沉重的负担。

EIS具有固有的地理局部性，将在智能车的HD地图绘制中发挥重要作用。可以采用不同的边缘辅助方法。边缘缓存可以帮助HD地图的传播，以及地图数据的聚合。边缘计算可以通过利用本地缓存的数据来辅助地图构建和地图变化检测。边缘服务器还可以协调通过该区域的车辆进行众包地图绘制。这样，通过在本地保存和处理数据，并在需要的地方构建地图，可以实现更高效的HD地图。

在设计卸载策略时，应仔细考虑特定算法的特点。例如，对于定位，基于视觉的方法享有高度并行的数据处理阶段，如特征提取、视差图生成、光流、特征匹配和高斯模糊[132]。因此，通过将部分任务卸载到边缘服务器，它们更适合于客户端-服务器联合处理，这可能提供丰富的GPU资源。相比之下，基于lidar的定位大量使用迭代最近点算法，该算法难以并行化[133]，因此可能难以卸载。

2)边缘辅助地图更新:考虑到环境的动态性，HD地图需要及时更新，为此我们需要收集新的HD地图数据，并从这些数据中检测变化。为了构建或更新HD地图，在一个区域收集的数据将仅用于该特定区域。因此，为了减轻存储和通信负担，车辆收集的数据应该在附近的边缘服务器上进行汇总，并辅以V2I通信。在获得足够的新鲜数据后，可以在边缘服务器上执行道路变化检测和道路事件(例如道路封闭)检测[63]，例如，应用基于dnn的方法[62]。一旦每个服务器都构建了自己的地图，就可以使用多会话映射来将多个地图组合在一个共同的测量坐标系中[134]。更新后的地图将被缓存在边缘服务器上，然后边缘服务器帮助通知变化并将地图分发给覆盖区域内的车辆。

3)边缘辅助SLAM技术:SLAM技术是自动驾驶的关键技术[68]。与通常处于室内环境的移动机器人相比，自动驾驶的SLAM更具挑战性。为了克服机载计算的限制，已经有了基于云的SLAM研究，即将部分计算负载卸载到云服务器上。例如，用于协同跟踪和测绘的云框架(C2TAM)[70]是一种分布式框架，其中昂贵的地图优化和存储在云上执行，而轻型相机跟踪客户端在本地计算机上运行。它应用了并行跟踪和映射(PTAM)算法，该算法有两个并行线程。一方面，通过对一组选定的关键帧进行非线性优化来计算几何映射。这种背景过程能够以低帧率生成精确的3D地图。另一方面，前景跟踪过程能够在假设已知地图的帧率下估计相机位置。虽然该框架是在假设云平台的情况下开发的，但论文中的实验使用桌面作为“云”。因此，它本质上是一种基于边的SLAM方法。因此，本研究证明了边缘辅助SLAM的可行性。DAvinCi[135]和Rapyuta[136]等其他基于云的移动机器人SLAM研究也为开发智能车联网的边缘辅助SLAM提供了宝贵的经验。

上述内容公开一种由边缘计算设备执行的用于生成本地动态地图（LDM）数据的方法

此外，HD地图数据由于精度高、几何信息和语义丰富而具有非常大的尺寸[63]。这给传输和存储HD地图带来了困难。它们通常是从云端提供服务的，附近的几个小区域的地图下载到车辆上。厘米级精度的三维HD地图需要下载的数据量可以达到每公里3 ~ 4gb。这不仅给从云端下载数据带来了延迟，也给骨干网带来了沉重的负担。

EIS具有固有的地理局部性，将在智能车的HD地图绘制中发挥重要作用。可以采用不同的边缘辅助方法。边缘缓存可以帮助HD地图的传播，以及地图数据的聚合。边缘计算可以通过利用本地缓存的数据来辅助地图构建和地图变化检测。边缘服务器还可以协调通过该区域的车辆进行众包地图绘制。这样，通过在本地保存和处理数据，并在需要的地方构建地图，可以实现更高效的HD地图。

3)同时定位和绘图(SLAM):基于地图的定位对于沿着不经常变化的道路行驶是有效的。但是，如果发生剧烈的变化，损失在精度上可能会影响驾驶安全。SLAM包括对车辆状态的同时估计和环境地图的构建[65]，[66]，[67]，[68]。它不严重依赖先验信息，允许车辆持续观察环境并随时适应新情况。为了实现完全自主，智能车辆必须能够在其环境中执行精确的SLAM[66]。此外，为了提高安全性和确保道路上的一致行为，需要重复冗余，因此应考虑不同的局部化方法，即基于地图和基于SLAM-based的方法。SLAM被认为是自动驾驶的关键使能技术，2007年DARPA城市挑战赛中的车辆已经使用了基于SLAM-based方法[69]。

虽然已经开发了许多SLAM算法，但它们主要用于室内，高度结构化的环境。au自治车辆需要在室外、光线多变、基于道路的环境中运行，因此需要更快、更高效的al-算法。对于SLAM在自动驾驶中的挑战，读者可以参考[68]进行更详细的讨论。我们将主要讨论与EIS相关的方面。特别是对于自动驾驶来说，SLAM的计算需求将是非常密集的。一小时的驾驶时间可以产生1tb的数据，而通过高计算能力解释1tb收集的数据需要两天的时间才能得出可用的导航数据[64]。而且，为了实时执行，延迟必须低于10ms，这给板载计算带来了很高的压力。

上述内容公开接收所述边缘计算设备的服务区域的第一LDM数据，其中所述第一LDM数据包括在阈值时间量内获得的高度动态的信息的数据；

考虑到不同技术的预算和特点，开发人员可能会为智能车辆选择不同的传感器组合。例如，Waymo使用的是基于激光雷达的技术，而Mobileye和特斯拉则依赖于摄像头和传感器[53]。目前，可用车载传感器的局限性和高成本是商用车只能实现1级到2级自动化的主要原因之一[54]。智能车辆的感知面临几个主要挑战，例如在恶劣天气和光照条件下的感知，或者在复杂的城市环境下的感知，以及有限的感知范围。传感器融合等技术可以通过利用来自不同传感器的传感数据来弥补单个传感器的缺点[55]，[56]，[57]。然而，这将显著增加机载计算量。

通过提供额外的近似计算和存储资源，EIS能够增强感知能力。它可以帮助提高相机和立体视觉的感知精度，例如，通过强大的深度学习技术，并通过将计算密集型子任务卸载到边缘服务器来实现复杂的多传感器融合。此外，通过共享车载传感和计算能力，在V2V和V2I通信的协助下，通过边缘服务器进行协调，协作感知可以显著提高感知的鲁棒性和准确性，并扩展感知范围[58]。

2)HD地图:地图是任何移动机器人应用的基础，对自动驾驶尤为重要。最近，HD地图受到了很多关注。HD地图将道路表面建模到10 ~ 20厘米的精度。它包含道路所有关键方面的三维表示，例如坡度和曲率、车道标记类型和路边物体。HD地图的定位可以达到厘米级的精度。它使用车载传感器将车辆感知到的环境与相应的HD地图进行比较。这可以克服基于GNSS的方法(例如GPS)的局限性，包括低定位精度和不同的可用性。预计，基于HD地图的定位将成为4级和5级自动驾驶系统的通用方法。HD地图还有助于解决基于车载传感器的两个主要感知问题[59]:

•缺乏完整性:从内部传感器获取的信息的完整性不能得到保证，因为传感器容易受到环境噪声的影响，并且由于成本方面的考虑，其能力可能受到限制。

•有限的感知范围:传感器的感知范围有限，它们无法测量位于其视场(FoV)之外的目标物体或被其他障碍物遮挡的目标物体。

上述内容公开，将所述第一LDM数据集成到LDM数据模型中；

业界在构建HD地图方面做出了很大的努力，例如TomTom[60]和HERE[61]。尽管如此，在实际实施中仍存在困难。制作HD地图很费时间。生成HD地图需要配备MMS (Mobile mapping System)的专用测绘车辆，整个过程包括三个步骤:数据采集获取测绘数据，数据积累积累测绘车辆获取的特征，数据确认手动对地图进行细化和确认。此外，HD地图是动态的，需要及时更新[62]，为此我们需要及时收集新鲜的HD数据，并从新鲜数据中发现变化[63]。一些HD地图供应商与汽车制造商合作，从智能车辆获取新的地图数据，但这将大大增加车辆的车载处理负担[64]。

此外，HD地图数据由于精度高、几何信息和语义丰富而具有非常大的尺寸[63]。这给传输和存储HD地图带来了困难。它们通常是从云端提供服务的，附近的几个小区域的地图下载到车辆上。厘米级精度的三维HD地图需要下载的数据量可以达到每公里3 ~ 4gb。这不仅给从云端下载数据带来了延迟，也给骨干网带来了沉重的负担。

EIS具有固有的地理局部性，将在智能车的HD地图绘制中发挥重要作用。可以采用不同的边缘辅助方法。边缘缓存可以帮助HD地图的传播，以及地图数据的聚合。边缘计算可以通过利用本地缓存的数据来辅助地图构建和地图变化检测。边缘服务器还可以协调通过该区域的车辆进行众包地图绘制。这样，通过在本地保存和处理数据，并在需要的地方构建地图，可以实现更高效的HD地图。

上述内容公开确定所述LDM数据模型的、与移动设备相关的第二LDM数据，其中所述第二LDM数据包括在所述阈值时间量内获得的高度动态的信息的数据；以及将所确定的第二LDM数据提供给所述移动设备。

由此可见对比文件JUN ZHANG ET AL: "Mobile Edge Intelligence and Computingfor the Internet of Vehicles"与权利要求1包括区别技术特征（1）

基于所接收的所述第一LDM数据是否与来自另一个源的LDM数据相证实以及基于一个或多个附加信任参数，确定所接收的所述第一LDM数据的信任度量；

对比文件us2017272450公开:

[0044] In block 214 , the server/processor may use the received sensor information to corroborate the vehicle information or verify the veracity of the suspicious information. For example, the server computing device may compare the received vehicle information to the received sensor information by applying the received vehicle information to a first behavior model to generate a first value, applying received sensor information to a second behavior model to generate a second value, computing a difference value that identifies the difference between the first value and the second value, comparing the difference value to a threshold value to determine whether the difference value exceeds the threshold value.

[0045] Thus, in blocks 206 through 214 , the server/processor may compare the received vehicle information to contextual information to generate a comparison result. Based on the comparison result, the server/processor may determine whether the received vehicle information should be evaluated. In response to determining that the received vehicle information should be evaluated, the server/processor may identify sensors for polling based on the received vehicle information, and poll identified sensors to receive sensor information. The server/processor may then corroborate the received vehicle information based on the received sensor information. In some embodiments, the server/processor may be configured to corroborate the received vehicle information by comparing the received vehicle information to directly the received sensor information. In other embodiments, server/processor may be configured to corroborate the received vehicle information by applying the received vehicle information to a first behavior model to generate a first value, applying received sensor information to a second behavior model to generate a second value, and labeling the vehicle information as corroborated in response to determining that a difference between the first value and the second value exceeds a threshold value.

【0044】在步骤214中，服务器/处理器可能使用接收到的传感器信息来证实车辆信息或验证可疑信息的真实性。例如，服务器计算设备可能通过将接收到的车辆信息应用于第一行为模型以生成第一值，将接收到的传感器信息应用于第二行为模型以生成第二值，计算出一个差值，该差值表示第一值和第二值之间的差异，并将差值与阈值比较，以确定差值是否超过该阈值。

【0045】因此，在步骤206至214中，服务器/处理器可能将接收到的车辆信息与上下文信息比较，以生成比较结果。基于比较结果，服务器/处理器可能确定是否应评估接收到的车辆信息。在确定应评估接收到的车辆信息后，服务器/处理器可能根据接收到的车辆信息确定需要轮询的传感器，并轮询所确定的传感器以接收传感器信息。然后，服务器/处理器可能基于接收到的传感器信息来证实接收到的车辆信息。在某些实施例中，服务器/处理器可能被配置为通过直接比较接收到的车辆信息和接收到的传感器信息来证实接收到的车辆信息。在其他实施例中，服务器/处理器可能被配置为通过将接收到的车辆信息应用于第一行为模型以生成第一值，将接收到的传感器信息应用于第二行为模型以生成第二值，并在确定第一值与第二值之间的差异超过阈值时，标记车辆信息为已证实。

由此可见对比文件us2017272450公开了区别技术特征（1）

根据权利要求1所述的方法，其中，所述LDM数据模型被维护在所述边缘计算设备中，并且包括所述边缘计算设备的所述服务区域的LDM数据。

对比文件US2018299274A1记载：

[0027] 在操作中，每个RSU 300被配置为存储一个基础地图，并通过使用地图更新逻辑332来更新该基础地图。例如，云服务器150可能在某个时间点将基础地图传送到RSU 300。相同的基础地图也可能提供给任何一辆车辆105。之后，假设车辆105b途经RSU 300b并向RSU 300b提供传感器数据，从而使RSU 300b能够增强或更新其基础地图。对基础地图的更新可能包括停放的车辆、事故、新的道路标志、已在道路上检测到冰的事实，或特定位置的坑洞等其他可能进一步详细说明或更新基础地图的元素。RSU 300b还可能从云服务器150和外部传感器/信息提供者160（例如天气预报、即将进行的施工通知等）获得更新，以进一步更新其基础地图。

由此可见上述附加技术特征已经被对比文件US2018299274A1公开：

根据权利要求1所述的方法，其中，所述移动设备是车辆中的计算设备，并且将所确定的第二LDM数据提供给所述移动设备包括：生成包含所述车辆的预定距离内的区域的数字地图；以及将所述数字地图发送到所述车辆，其中，所述数字地图以适用于所述车辆的自主导航的格式而被生成和发送。

对比文件US2018299274A1公开：

[0011] 图1展示了用于维护自动驾驶车辆的更新地图和相关信息的场景100及网络组件，符合一个示例性实施例。具体来说，在该示例性实施例中，场景100包括一个路口110。几辆车辆105a (V1), 105b (V2), 105c (V3) 出现在道路上。在路口110附近和沿着道路（例如，临近、上方）部署了多个道路旁单元（RSUs） 300a, 300b, 300c。每个RSU还与中央或云服务器150以及一个或多个外部传感器或信息提供者160通信。云服务器150可配置为对RSUs进行总体控制，以及实现地图生成和分发。也就是说，云服务器150可以作为RSUs的管理员和地图生成处理器，或者至少提供数据以便RSUs在本地生成地图。

[0013] 如下面更详细描述的那样，车辆105a, 105b, 105c 通过参考存储的详细（3D）地图计算行驶/导航位置。因此，确保详细地图尽可能准确和最新是很重要的。不幸的是，场景的元素，例如场景100，可能相对于存储在给定车辆中的基准地图变化得相对较快。某个变化可能是短暂的，比如车道关闭或事故。其他变化可能更永久，比如新建的交通标志或新建的建筑物。当车辆遇到与其当前存储地图不匹配的场景时，可能会感到困惑，并且或进入安全模式停止，或以不安全的方式行驶/导航。

[0028] 当另一辆例如105d的车辆进入RSU 300b覆盖的区域时，车辆105d将与RSU 300b通信，以验证该车辆当前存储的基础地图与RSU中存储的基础地图是否匹配。例如，可以通过车辆向RSU 300b发送存储在车辆105d中的基础地图的哈希值来完成这种比较。RSU 300b然后可以确认基础地图是否匹配。然后，RSU 300b可以基于RSU 300b先前从早些经过的车辆105b接收到的信息，向车辆105d发送例如一个地图偏差数据集。也就是说，RSU 300b可能向车辆105d发送一组信息，描述存储在车辆105d中的基础地图与RSU最近生成的更新地图之间的差异。值得注意的是，由于偏差数据集通常比完整地图的数据量少，因此车辆从RSU 300b获取地图偏差数据集所需的传输时间少于传送完整地图所需的时间。

[0047] 在502，RSU从一辆或多辆车接收数据或遥测信息。例如，如上所述，RSU可能从激光器、摄像机、雷达单元等处接收信息。在504，RSU处理数据或遥测信息，以检测一个或多个物体及其一个或多个特征（如位置、大小、颜色、运动等）。在506，对于每个检测到的物体，RSU将其一个或多个特征与其存储的地图进行比较。例如，静止物体的位置或大小特征可与地图中的物体位置进行比较。在508，RSU对一个或多个特征的比较值确定偏差值。偏差值可以基于百分比偏差，最小或最大偏差等。在510，RSU确定偏差值是否在相关特征的阈值范围内。这些阈值可由管理员确定，并且不同类型的物体可能有不同的阈值。如果偏差值在阈值内，将从车辆收集更多数据以进行处理。如果在510，偏差值不在相关阈值范围内，RSU，即地图更新逻辑332，将更新其地图。在514，RSU将更新后的地图或地图偏差数据集发送到云服务器150。那些熟悉此领域技术的人士应该理解，同样的更新地图或地图偏差数据集也可以与邻近的RSU和车辆共享。

由此可见对比文件US2018299274A1公开了附加技术特征。

对比文件us2018051998A1全文公开：

[0029] 地图数据库306包括由一个或多个车辆的车载传感器生成的车辆数据，以及来自传感器如基础设施传感器或图1中的其他数据源106的基础设施/环境数据。地图数据库306可以向聚合网络308上传数据和/或从聚合网络308下载数据。聚合网络308可能包括一个或多个聚合服务器102。例如，地图数据库306可以位于车辆内，并与聚合网络共享收集的车辆或基础设施数据，以便其他车辆可以访问和使用该数据。同样，地图数据库306也可以从聚合网络308下载数据，以利用基于大量贡献车辆或数据源的数据聚合。例如，地图数据库306可以维护一份聚合网络308存储的聚合数据的同步副本，用于车辆附近区域或车辆行驶路线上的数据。聚合数据可以与其他地图数据或驾驶历史数据一起存储，以供路由算法304使用。

由此可见对比文件us2018051998A1公开了附加技术特征

对比文件US20210103481公开

[0014]终端设备170 (例如，诸如智能手机、车辆信息娱乐系统等的客户端设备）可以在操作中沿着云的边缘行进并临时与一个边缘站（例如，边缘站）通信。在边缘站130失去连接(例如，通过离开边缘站130的无线通信范围、通过从有线网络连接180断开等)并且与另一个边缘站132(例如，边缘站132)建立连接之前，通过进入边缘站132的无线通信范围、通过连接到有线网络连接182 )。当终端设备170继续行进时，终端设备170可以与边缘站132断开连接并与又一个边缘站134连接(例如，通过进入边缘站134的无线通信范围、通过连接到有线网络连接)。184），等等。在说明性实施例中，每个边缘站130、132、134中的一个或多个服务器设备140、142、144被配置为代表终端设备170执行工作负载160、162 (例如，服务)。例如，服务器设备140可以为终端设备提供自主车辆控制服务（例如，对象识别、转向、加速和制动控制）、地图服务（例如，路线查找服务）和音乐流服务。170 .当终端设备170离开边缘站130的通信范围或者以其他方式继续行进使得与边缘站130的连接性将丢失（例如，在预定义的时间量内）时，服务器设备140暂停服务的执行并通过高速网络连接将服务所使用的数据发送至下一个边缘站132的服务器设备142。

由此可见对比文件US20210103481公开了附加技术特征。

根据权利要求1所述的方法，还包括从所述移动设备接收注册消息，其中，确定与移动设备相关的所述第二LDM数据包括基于与所述注册消息一起包括的信息确定与移动设备相关的所述第二LDM数据。

对比文件US2018299274A1公开

[0030] 传送给车辆105d的地图偏差数据集可以取决于（1）车辆的位置、（2）当前方向（例如速度）和车辆类型，以及（3）预期或预计的下一步驾驶轨迹。根据上下文（如位置、方向、速度、预期轨迹等），可以传送诸如交通的动态信息覆盖层。这种上下文在“边缘”，即在RSU网络层面上，尤其相关和可扩展，而不是在云服务器150层面上。

[0033] 图4是一个流程图，描述了示例实施例中由路边单元300操作的地图更新逻辑332可以执行的一系列操作。在410，RSU确定一辆车辆进入预定范围内。在412，RSU与车辆建立通信链接。在414，RSU从车辆接收足够识别车辆类型的数据（或其行进位置，或与车辆相关的其他信息）。这一步可能还包括获取车辆存储的地图类型/版本以确定基础地图。在416，基于车辆类型（或其他特征），RSU选择存储在路边单元中的地图。选择地图可以包括，例如，选择基础地图中最相关于该类型车辆或该车辆预定行驶路径的内容。在418，RSU向邻近的RSU发送查询，寻求数据来增强所选地图（或地图类型）。在420，RSU从邻近的RSU接收增强地图的数据。在422，RSU基于增强地图数据更新所选地图（或地图类型），以获得更新后的地图。在424，RSU将至少一部分更新地图发送给车辆。也就是说，RSU将地图偏差数据集发送给车辆或将完整的更新地图发送给车辆。

[0042] RSU可以配置为使用传感器信息来优化地图或模型，并仅将优化后的部分发送到云服务器150。

由此可见上述技术特征已经被对比文件US2018299274A1公开

根据权利要求1所述的方法，还包括由所述边缘计算设备接收关于所述移动设备的计划路线的信息，其中，确定与移动设备相关的所述第二LDM数据包括沿着所述计划路线确定与所述移动设备相关的所述第二LDM数据。

对比文件US2018299274A1公开

[0030] 传送给车辆105d的地图偏差数据集可以取决于（1）车辆的位置、（2）当前方向（例如速度）和车辆类型，以及（3）预期或预计的下一步驾驶轨迹。根据上下文（如位置、方向、速度、预期轨迹等），可以传送诸如交通的动态信息覆盖层。这种上下文在“边缘”，即在RSU网络层面上，尤其相关和可扩展，而不是在云服务器150层面上。

[0031] 例如，如果一辆车辆在一条道路上向北行驶，最有价值的信息可能与向南行驶相关的信息不同。同样，当车辆接近一个交叉路口时，最有价值的信息取决于（a）它来自何处以及（b）它要去哪里，例如，向北行驶（从南面来）并计划在交叉口右转。因此，当车辆与RSU 300通信时，车辆可以提供此类信息，使得RSU 300能够向车辆提供最合适的信息。

[0034] 通过使RSU之间相互通信，可以将与云服务器150交换的信息量最小化（云服务器可能原本负责收集所有RSU的数据并协调应向哪些车辆提供哪些信息），从而最小化网络中消耗的带宽量。

由此可见对比文件US2018299274A1公开了上述附加技术特征。

对比文件us2018051998A1全文公开：

[0029] 地图数据库306包括由一个或多个车辆的车载传感器生成的车辆数据，以及来自传感器如基础设施传感器或图1中的其他数据源106的基础设施/环境数据。地图数据库306可以向聚合网络308上传数据和/或从聚合网络308下载数据。聚合网络308可能包括一个或多个聚合服务器102。例如，地图数据库306可以位于车辆内，并与聚合网络共享收集的车辆或基础设施数据，以便其他车辆可以访问和使用该数据。同样，地图数据库306也可以从聚合网络308下载数据，以利用基于大量贡献车辆或数据源的数据聚合。例如，地图数据库306可以维护一份聚合网络308存储的聚合数据的同步副本，用于车辆附近区域或车辆行驶路线上的数据。聚合数据可以与其他地图数据或驾驶历史数据一起存储，以供路由算法304使用。

由此可见对比文件us2018051998A1全文公开了附加技术特征。

对比文件US20180051998公开

[0021]路线优化组件112可以访问数据存储114中的聚合数据以优化路线或向车辆104中的一个或多个车辆提供聚合数据。例如，车辆104可以使用聚合数据来向驾驶员或控制系统116提供关于未来驾驶路径的信息，以优化车辆104的驾驶。车辆104还可累积驾驶数据，包括关于道路或驾驶环境的任何信息，并将所累积的驾驶数据发送到聚合服务器102用于存储或聚合。其他数据源106也可以将用于聚合的数据上传到聚合服务器102。其他数据源106可以包括用于基础设施的系统或传感器，例如交通摄像机、车辆或交通传感器、天气传感器等。在一个实施例中，路线优化组件112可基于自动驾驶或辅助驾驶对车辆是否可用来确定对驾驶路线进行优先级排序的驾驶路线。在一个实施例中，路线优化部件112可以位于一辆或多辆车辆104内，例如位于车辆的控制系统116内。例如，路线优化组件112可以在车辆104上本地操作并且利用存储在数据存储114中的聚合数据结合本地存储到车辆104的驾驶历史数据和/或地图数据。

由此可见对比文件US20180051998公开了区别技术特征。

对比文件CN109405841A公开

[0061] 在另一个示例中，事件洞察模块314被配置为通过将识别预先规划的车辆路径上的结构特征的地图数据与预期存在该结构特征的实际区域的感知数据(例如，激光雷达和/或相机数据)进行比较来分析车辆感测数据和预先规划的轨迹数据。在该示例中，事件洞察模块314可以进一步被配置为通过识别地图数据与关于结构特征的存在的感知数据之间的不一致来根据分析识别异常。作为示例，当地图数据指示应当存在护栏时，感知传感器可能不会检测到护栏。示例事件洞察地图可以检测地图数据与车辆体验之间的不一致，并且将不一致性识别为异常。

由此可见，对比文件CN109405841A公开了附加技术特征。

根据权利要求1所述的方法，还包括从所述移动设备接收移动设备运动学信息；其中，确定与移动设备相关的所述第二LDM数据包括基于所述移动设备运动学信息确定与移动设备相关的第二LDM数据。

对比文件US2018299274A1公开

[0030] 传送给车辆105d的地图偏差数据集可以取决于（1）车辆的位置、（2）当前方向（例如速度）和车辆类型，以及（3）预期或预计的下一步驾驶轨迹。根据上下文（如位置、方向、速度、预期轨迹等），可以传送诸如交通的动态信息覆盖层。这种上下文在“边缘”，即在RSU网络层面上，尤其相关和可扩展，而不是在云服务器150层面上。

[0031] 例如，如果一辆车辆在一条道路上向北行驶，最有价值的信息可能与向南行驶相关的信息不同。同样，当车辆接近一个交叉路口时，最有价值的信息取决于（a）它来自何处以及（b）它要去哪里，例如，向北行驶（从南面来）并计划在交叉口右转。因此，当车辆与RSU 300通信时，车辆可以提供此类信息，使得RSU 300能够向车辆提供最合适的信息。

由此可见对比文件US2018299274A1公开了上述附加技术特征。

对比文件us2018051998A1全文公开：

[0044] 成本组件608被配置为确定由路线组件602确定的每条路线的路线成本和/或由分类组件606确定的可靠性或类别的路线成本。例如，成本组件608可能基于驾驶数据聚合来确定基于自动驾驶功能或驾驶辅助功能可靠性的路线成本。成本组件608可能基于感知系统、控制系统和/或车辆类型，来确定路线成本。成本组件608可能基于预测的功能可靠性（基于聚合或本地数据）与任何其他路线成本结合来确定路线成本。其他路线成本示例包括当前的交通状况、当前的天气条件、路线总驾驶时间、路线总距离等。在一个实施例中，成本组件608可能确定每段道路的功能可靠性成本，并将这些成本相加以计算整个路线的总体功能可靠性成本。在一个实施例中，道路段或路线的功能可靠性成本可能取决于当前天气或当前交通。

由此可见对比文件us2018051998A1公开了区别技术特征。

根据权利要求1所述的方法，其中，接收所述边缘计算设备的服务区域的第一LDM数据包括：从所述移动设备接收数据，其中所接收的数据包括由所述移动设备获得的传感器数据、图像数据、音频数据或操作状态数据中的一个或多个；以及从所接收的数据确定应该集成到所述LDM数据模型中的信息。

对比文件US2018299274A1记载

[0047] 在502，RSU从一辆或多辆车接收数据或遥测信息。例如，如上所述，RSU可能从激光器、摄像机、雷达单元等处接收信息。在504，RSU处理数据或遥测信息，以检测一个或多个物体及其一个或多个特征（如位置、大小、颜色、运动等）。在506，对于每个检测到的物体，RSU将其一个或多个特征与其存储的地图进行比较。例如，静止物体的位置或大小特征可与地图中的物体位置进行比较。在508，RSU对一个或多个特征的比较值确定偏差值。偏差值可以基于百分比偏差，最小或最大偏差等。在510，RSU确定偏差值是否在相关特征的阈值范围内。这些阈值可由管理员确定，并且不同类型的物体可能有不同的阈值。如果偏差值在阈值内，将从车辆收集更多数据以进行处理。如果在510，偏差值不在相关阈值范围内，RSU，即地图更新逻辑332，将更新其地图。在514，RSU将更新后的地图或地图偏差数据集发送到云服务器150。那些熟悉此领域技术的人士应该理解，同样的更新地图或地图偏差数据集也可以与邻近的RSU和车辆共享。

由此可见对比文件US2018299274A1公开了上述附加技术特征。

对比文件us2018051998A1全文公开：

[0016] 根据一个实施例，来自大量车辆或其他数据源的驾驶数据存储在连接车辆中并上传到网络。例如，车辆可以使用车辆传感器获取驾驶环境数据，并将这些数据或任何派生数据上传到云存储位置。用户可以通过网络使用连接设备（如车辆、计算系统、智能手机等）访问云存储位置，并下载相关数据到车辆中。这些数据可以本地存储在车辆的地图数据库中，并运行路线算法以优化车辆在相关路线上的行为。

[0018] 根据一个示例性实施例，车道线或车道标记质量对辅助驾驶功能或自动驾驶功能可能很重要。地图数据库或驾驶历史数据库可以存储车道线质量的一些指标。例如，车道线/标记质量可以由车辆本地存储，或作为聚合数据的一部分上传存储。地图数据库和/或驾驶历史数据库可以基于云，在车辆制造时加载到车辆上，和/或由车辆根据探测或传感器数据创建和更新。使用地图或驾驶历史数据库，可以执行路线算法，评估并优先考虑基于最低成本的路线。与车道线质量相关的一个示例成本项是：

J = Σ(i=1到n)(1 - Qi)，

其中Qε{0,1}是车道质量的布尔指标（0表示车道质量差，1表示车道质量好）。在一个实施例中，地图数据库或驾驶历史数据库可能包括除道路车道线质量外的指标，如道路曲率、道路车道线几何形状、道路车道线/标记类型（如单线、双线、虚线、反光标识或其他车道标记类型的指示）和/或道路车道线/标记颜色（如白色、黄色或其他颜色的指示）。在一实施例中，路线算法可能考虑这些额外的指标或其他指标，在优先考虑路线时。例如，路线算法可能考虑其他成本，如最短距离、最快行驶时间、交通状况等，以基于各种成本因素找到最佳全方位路线。在一个实施例中，出于路线目的确定的线质量成本可能是一个动态函数，考虑天气和交通因素。例如，一些类型的车道标记可能根据一天中的时间或天气条件，对于车辆传感器来说更易见或更难检测。

[0023] 车载控制系统116还可能包括一个或多个传感系统/设备，用于检测附近物体、车道标记的存在，和/或确定母车（例如，包含车载控制系统116的车辆）的位置。例如，车载控制系统116可能包括一个或多个雷达系统206，一个或多个激光雷达（LIDAR）系统208，一个或多个摄像系统210，一个全球定位系统（GPS）212，和/或一个或多个超声波系统214。车载控制系统116可能包含一个数据存储器216，用于存储导航与安全相关或有用的数据，如地图数据、驾驶历史或其他数据。车载控制系统116还可能包括一个收发器218，用于与移动或无线网络、其他车辆、基础设施或任何其他通信系统（如图1中的聚合服务器102）进行无线通信。

[0027] 在一个实施例中，摄像系统210可能包括多个摄像头。例如，摄像系统210可能包括面向不同方向的摄像头，以提供车辆附近或周围区域的不同视角和视场。同样，雷达系统206、激光雷达系统208和/或超声波系统214可能包括多个传感器，从车辆周围的不同方向获取数据，以提供关于母车周围环境的详细信息。在一个实施例中，这些数据可以上传进行远程存储，例如通过一个或多个聚合服务器102。

[0042] 分类组件606被配置为确定车辆的自动驾驶功能或辅助驾驶功能在特定道路段上是否能够稳健运行。例如，分类组件606可能基于路线组件602和/或数据组件604获取的数据，来确定操作是否可能是可靠的。在一个实施例中，分类组件606被配置为将一个或多个自动驾驶功能或车辆的驾驶辅助功能在道路段上运行的可靠性进行分类（可靠类别或不可靠类别）。在一个实施例中，分类组件606可以确定特定道路段功能的可靠性。例如，这些功能的可靠性可能在排名系统中进行评估，提供一个数值（比如1到10范围内的值）或其他值，用于指示这些功能是否高度可靠。

[0043] 分类组件606可能使用由聚合服务器102聚合的数据或车辆存储的本地数据。分类组件606还可能使用关于车辆的数据，例如车辆类型、车辆感知系统的信息或车辆控制系统的信息，来确定分类。例如，一些感知系统可能比其他系统更可靠地检测环境条件。同样，一些控制系统或车辆可能在不同环境或驾驶条件下能够更可靠地运行。另一个例子是，可靠性还可能基于人类驾驶员及其驾驶习惯以及他们希望避免的条件。因此，由分类组件606确定的可靠性可能是特定于车辆和/或车辆驾驶员的。

由此可见对比文件us2018051998A1全文公开了附加技术特征。

对比文件US20190244517记载

[0022]车辆组件被配置为获得（例如，接收或检索）具有与地图块集合中的地图块相对应的地点的传感器导出数据。传感器导出的数据是指直接来自车辆105中的传感器、来自另一车辆（例如，第二车辆115）中的传感器、来自RSU 110中的传感器的数据，或者来自处理后的传感器数据——诸如由分类器（例如， 、人工神经网络 (ANN)）或对传感器数据进行操作的聚合器。因此，在示例中，从RSU 110接收传感器导出数据的一部分作为来自其他车辆（例如，第二车辆115）的众包传感器数据。

由此可见对比文件US20190244517公开了附加技术特征。

对比文件US20190132709记载

[0024]基础设备61, 61b 可以提供环境传感服务，在本例中，基础设施设备61, 61b可以为车辆64提供环境感测服务。基础设施设备提供的环境传感服务61, 61b可以用于动态环境的实时绘图，例如道路63。动态环境的实时映射用于高可靠性决策系统，例如当车辆64是CA/AD车辆64时。在智能交通系统 (ITS) 中，实时地图可用于称为本地动态地图 (LDM) 的实时交通状态地图，该地图构建车辆操作的所有相关数据，并提供有关高度动态对象的信息，例如道路63上的车辆64。 LDM的输入可以由配备有传感器的用户设备（UE）提供，例如一辆或多辆车辆64，或者由固定传感器阵列62提供, 62b 沿道路部署63。无论传感器数据的来源如何，根据传感器数据构建的环境模型都需要尽可能完整和准确，以便可靠地提供实时地图服务。

由此可见对比文件US20190132709公开了附加技术特征。

对比文件CN107449433A公开

[0070] 在动作S201，定位电路207检测移动设备122的位置，并且处理器200从定位电路207接收位置数据。位置数据可以以地图不可知的坐标(例如，纬度和经度)进行测量。位置数据可以包括取决于地图的IAO(例如，基于地图瓦片中的相对位置)。该位置数据可以包括高度值。
[0071] 在动作S203，处理器200检测来自第一传感器213的针对道路场景或道路对象的初始观测数据。处理器200可以首先从服务器125接收进行初始观测的请求。初始观测数据可以被临时存储在存储器204中，或者更为持久地被记录在存储器204中。在一些实例中，初始观测数据被存储在存储器204中直到建立了到服务器125的数据连接，其取决于用于小区覆盖的地理区域或无线网络可用性。

由此可见对比文件CN107449433A公开了附加技术特征。

根据权利要求1所述的方法，其中，所述第一LDM数据包括在相关欧洲电信标准协会标准中定义的类型4的高度动态的信息的数据。

[0012] 尽管图1中未展示，相关技术人员会明白，场景100可能包括其他许多元素，例如车道标记（白线，黄线等）、路缘、护栏、公路隔离带、建筑物、树木、停放的汽车、行人、道路施工现场、停车标志、交通信号灯等。这些特征都可以成为生成和供应给车辆的详细地图的一部分。

根据目标专利说明的说明，行人属于类型4的高度动态的信息数据。

由此可见US2018299274A1公开了附加技术特征。

根据权利要求1所述的方法，其中，所确定的第二LDM数据包括在相关欧洲电信标准协会标准中定义的类型4的高度动态的LDM信息。

[0012] 尽管图1中未展示，相关技术人员会明白，场景100可能包括其他许多元素，例如车道标记（白线，黄线等）、路缘、护栏、公路隔离带、建筑物、树木、停放的汽车、行人、道路施工现场、停车标志、交通信号灯等。这些特征都可以成为生成和供应给车辆的详细地图的一部分。

根据目标专利说明的说明，行人属于类型4的高度动态的信息数据。

由此可见US2018299274A1公开了附加技术特征。

根据权利要求1所述的方法，其中，所述第一LDM数据是经由边缘网络接口被接收的。

对比文件US2018299274A1公开

[0047] 在502，RSU从一辆或多辆车接收数据或遥测信息。例如，如上所述，RSU可能从激光器、摄像机、雷达单元等处接收信息。在504，RSU处理数据或遥测信息，以检测一个或多个物体及其一个或多个特征（如位置、大小、颜色、运动等）。在506，对于每个检测到的物体，RSU将其一个或多个特征与其存储的地图进行比较。例如，静止物体的位置或大小特征可与地图中的物体位置进行比较。在508，RSU对一个或多个特征的比较值确定偏差值。偏差值可以基于百分比偏差，最小或最大偏差等。在510，RSU确定偏差值是否在相关特征的阈值范围内。这些阈值可由管理员确定，并且不同类型的物体可能有不同的阈值。如果偏差值在阈值内，将从车辆收集更多数据以进行处理。如果在510，偏差值不在相关阈值范围内，RSU，即地图更新逻辑332，将更新其地图。在514，RSU将更新后的地图或地图偏差数据集发送到云服务器150。那些熟悉此领域技术的人士应该理解，同样的更新地图或地图偏差数据集也可以与邻近的RSU和车辆共享。

由此可见对比文件US2018299274A1公开了附加技术特征。

根据权利要求1所述的方法，还包括：

生成所述移动设备的状态表示，

其中，确定与所述移动设备相关的所述第二LDM数据包括基于所生成的所述移动设备的状态表示来确定与移动设备相关的所述第二LDM数据。

对比文件US2018299274A1公开

[0030] 传送给车辆105d的地图偏差数据集可以取决于（1）车辆的位置、（2）当前方向（例如速度）和车辆类型，以及（3）预期或预计的下一步驾驶轨迹。根据上下文（如位置、方向、速度、预期轨迹等），可以传送诸如交通的动态信息覆盖层。这种上下文在“边缘”，即在RSU网络层面上，尤其相关和可扩展，而不是在云服务器150层面上。

由此可见US2018299274A1公开了附加技术特征。

对比文件us2018051998A1全文公开：

[0029] 地图数据库306包括由一个或多个车辆的车载传感器生成的车辆数据，以及来自传感器如基础设施传感器或图1中的其他数据源106的基础设施/环境数据。地图数据库306可以向聚合网络308上传数据和/或从聚合网络308下载数据。聚合网络308可能包括一个或多个聚合服务器102。例如，地图数据库306可以位于车辆内，并与聚合网络共享收集的车辆或基础设施数据，以便其他车辆可以访问和使用该数据。同样，地图数据库306也可以从聚合网络308下载数据，以利用基于大量贡献车辆或数据源的数据聚合。例如，地图数据库306可以维护一份聚合网络308存储的聚合数据的同步副本，用于车辆附近区域或车辆行驶路线上的数据。聚合数据可以与其他地图数据或驾驶历史数据一起存储，以供路由算法304使用。

由此可见，对比文件us2018051998A1公开了附加技术特征。

根据权利要求11所述的方法，还包括：基于所述状态表示和所述第二LDM数据确定增量信息；以及将所确定的增量信息提供给所述移动设备。

对比文件US2018299274A1公开

[0030] 传送给车辆105d的地图偏差数据集可以取决于（1）车辆的位置、（2）当前方向（例如速度）和车辆类型，以及（3）预期或预计的下一步驾驶轨迹。根据上下文（如位置、方向、速度、预期轨迹等），可以传送诸如交通的动态信息覆盖层。这种上下文在“边缘”，即在RSU网络层面上，尤其相关和可扩展，而不是在云服务器150层面上。

由此可见对比文件US2018299274A1公开了区别技术特征。

对比文件us2018051998A1全文公开：

[0029] 地图数据库306包括由一个或多个车辆的车载传感器生成的车辆数据，以及来自传感器如基础设施传感器或图1中的其他数据源106的基础设施/环境数据。地图数据库306可以向聚合网络308上传数据和/或从聚合网络308下载数据。聚合网络308可能包括一个或多个聚合服务器102。例如，地图数据库306可以位于车辆内，并与聚合网络共享收集的车辆或基础设施数据，以便其他车辆可以访问和使用该数据。同样，地图数据库306也可以从聚合网络308下载数据，以利用基于大量贡献车辆或数据源的数据聚合。例如，地图数据库306可以维护一份聚合网络308存储的聚合数据的同步副本，用于车辆附近区域或车辆行驶路线上的数据。聚合数据可以与其他地图数据或驾驶历史数据一起存储，以供路由算法304使用。

由此可见对比文件us2018051998A1公开了附加技术特征。

根据权利要求11所述的方法，还包括：

接收LDM数据查询，

其中，确定与所述移动设备相关的所述第二LDM数据包括基于所生成的所述移动设备的状态表示和所接收的LDM数据查询确定与移动设备相关的所述第二LDM数据。

对比文件US2018299274A1公开

[0036] 根据进一步的实施例，可以在RSU 300与车辆105之间进行通信交换，在此期间RSU 300查询车辆以确定哪些数据是最有用的传输的，以及哪些数据可能是不必要传输的。也就是说，车辆可能请求特定的信息。例如，乘客可能想知道几条街外是否有交通拥堵。然后，RSU可以与相关的邻近RSU通信以获取请求的数据。

由此可见对比文件US2018299274A1公开了附加技术特征。

对比文件us2018051998A1全文公开：

[0028] 图3是数据流图300，展示了一个实施例中的数据流和处理。用户可以通过用户界面302提供导航到目的地的请求。用户请求可以提供给路由算法304。路由算法304生成一个数据库查询，以获取关于从当前位置到目的地的一个或多个路线的数据。数据库查询被发送到地图数据库306。地图数据库306向路由算法304提供请求的数据，路由算法304生成并发送优化路径到用户界面302。例如，优化路径可能包括最小化一个或多个成本的路径，这些成本可能包括距离成本、时间成本、驾驶辅助功能或自动驾驶功能的可靠性成本等。例如，优化路径可能提供短的旅行时间，同时将车辆/用户引导到驾驶辅助功能或自动驾驶功能可靠的道路上。

由此可见对比文件us2018051998A1全文公开了附加技术特征。

对比文件CN104883382A公开

[0051] 在416，方法400包括确定目标信息是否包括导航数据。例如，如果由其它设备检测到的用户活动包括或涉及前往兴趣点，那么至所述兴趣点的导航信息可被包括在目标信息中。如果目标信息包括导航数据(例如，416处的“是”)，那么方法400进行到418以启动导航应用。在420，方法400包括将与导航数据有关的目标信息输入到导航应用。例如，输入目标信息可包括将地址/路线标识输入到导航应用以启动到所述地址的导航，如在422指示。输入目标信息可包括输入兴趣点类别，如在424指示。例如，如果导航信息包括用户在不识别特定兴趣点的情况下可能前往的位置的可能类型的标识，那么与位置的类型(例如，餐馆、机场、博物馆等)有关的兴趣点类别可能被输入到导航应用，以便生成可供驾驶员选择的可能的目的地列表。

由此可见对比文件CN104883382A公开了附加技术特征。

一种被配置为用作边缘计算设备的计算设备，包括：

处理器，其配置有处理器可执行指令以执行操作，所述操作包括：接收所述计算设备的服务区域的第一本地动态地图（LDM）数据，其中第一LDM数据包括在阈值时间量内获得的高度动态的信息的数据；

基于所接收的所述第一LDM数据是否与来自另一个源的LDM数据相证实以及基于一个或多个附加信任参数，确定所接收的所述第一LDM数据的信任度量；

响应于确定所述信任度量超过所述信任度量阈值，将所述第一LDM数据集成到LDM数据模型中；

确定所述LDM数据模型的、与移动设备相关的第二LDM数据，其中所述第二LDM数据包括在所述阈值时间量内获得的高度动态的信息的数据；以及将所确定的第二LDM数据提供给所述移动设备。

权利要求14是与权利要求1对应的装置权利要求，基于相同的理由没有创造性。

根据权利要求14所述的计算设备，其中，所述移动设备是车辆中的计算设备，并且其中所述处理器配置有处理器可执行指令以执行操作，使得将所确定的第二LDM数据提供给所述移动设备包括：生成包含所述车辆的预定距离内的区域的数字地图；以及将所述数字地图发送到所述车辆，其中，所述数字地图以适用于所述车辆的自主导航的格式而被生成和发送。

v>

权利要求15是与权利要求3对应的装置权利要求。

根据权利要求14所述的计算设备，其中，所述处理器配置有处理器可执行指令以执行操作，所述操作还包括从所述移动设备接收注册消息，以及其中，所述处理器配置有处理器可执行指令以执行操作，使得确定与移动设备相关的所述第二LDM数据包括基于与所述注册消息一起包括的信息确定与移动设备相关的所述第二LDM数据。

与权利要求4对应

根据权利要求14所述的计算设备，其中，所述处理器配置有处理器可执行指令以执行操作，所述操作还包括由所述计算设备接收关于所述移动设备的计划路线的信息，其中，所述处理器配置有处理器可执行指令以执行操作，使得确定与移动设备相关的所述第二LDM数据包括沿着所述计划路线确定与所述移动设备相关的所述第二LDM数据。

与权利要求5对应

根据权利要求14所述的计算设备，其中，所述处理器配置有处理器可执行指令以执行操作，所述操作还包括从所述移动设备接收移动设备运动学信息；其中，所述处理器配置有处理器可执行指令以执行操作，使得确定与移动设备相关的所述第二LDM数据包括基于所述移动设备运动学信息确定与移动设备相关的第二LDM数据。

与权利要求6对应

根据权利要求14所述的计算设备，其中，所述处理器配置有处理器可执行指令以执行操作，使得接收所述计算设备的服务区域的第一LDM数据包括：从所述移动设备接收数据，其中所接收的数据包括由所述移动设备获得的传感器数据、图像数据、音频数据或操作状态数据中的一个或多个；以及从所接收的数据确定应该集成到所述LDM数据模型中的信息。

与权利要求7对应

根据权利要求14所述的计算设备，其中，所述处理器配置有处理器可执行指令以执行操作，使得接收第一LDM数据包括接收在相关欧洲电信标准协会标准中定义的类型4的高度动态的信息的数据。

与权利要求8对应

根据权利要求14所述的计算设备，其中，所述处理器配置有处理器可执行指令以执行操作，使得确定第二LDM数据包括确定在相关欧洲电信标准协会标准中定义的类型4的高度动态的LDM信息。

与权利要求9对应

根据权利要求14所述的计算设备，其中，所述处理器配置有处理器可执行指令以执行操作，所述操作还包括生成所述移动设备的状态表示，其中，所述处理器配置有处理器可执行指令以执行操作，使得确定与所述移动设备相关的所述第二LDM数据包括基于所生成的所述移动设备的状态表示来确定与移动设备相关的所述第二LDM数据。

与权利要求11对应

根据权利要求22所述的计算设备，其中，所述处理器配置有处理器可执行指令以执行操作，所述操作还包括：基于所述状态表示和所述第二LDM数据确定增量信息；以及将所确定的增量信息提供给所述移动设备。

与权利要求12对应

根据权利要求22所述的计算设备，其中，所述处理器配置有处理器可执行指令以执行操作，所述操作还包括：接收LDM数据查询，其中，确定与所述移动设备相关的所述第二LDM数据包括基于所生成的所述移动设备的状态表示和所接收的LDM数据查询确定与移动设备相关的所述第二LDM数据。

与权利要求13对应

一种在其上存储有处理器可执行指令的非暂时性处理器可读介质，所述处理器可执行指令被配置为使边缘计算设备的处理器执行操作，所述操作包括：接收所述计算设备的服务区域的第一本地动态地图（LDM）数据，其中第一LDM数据包括在阈值时间量内获得的高度动态的信息的数据；

基于所接收的所述第一LDM数据是否与来自另一个源的LDM数据相证实以及基于一个或多个附加信任参数，确定所接收的所述第一LDM数据的信任度量；

响应于确定所述信任度量超过所述信任度量阈值，将所述第一LDM数据集成到LDM数据模型中；

确定所述LDM数据模型的、与移动设备相关的第二LDM数据，其中所述第二LDM数据包括在所述阈值时间量内获得的高度动态的信息的数据；以及将所确定的第二LDM数据提供给所述移动设备。

v>

与权利要求1对应

一种被配置为用作边缘计算设备的计算设备，包括：

用于接收所述计算设备的服务区域的第一本地动态地图（LDM）数据的部件，其中第一LDM数据包括在阈值时间量内获得的高度动态的信息的数据；

用于基于所接收的所述第一LDM数据是否与来自另一个源的LDM数据相证实以及基于一个或多个附加信任参数，确定所接收的所述第一LDM数据的信任度量的部件；

用于响应于确定所述信任度量超过所述信任度量阈值，将所述第一LDM数据集成到LDM数据模型中的部件；

用于确定所述LDM数据模型的、与移动设备相关的第二LDM数据的部件，其中所述第二LDM数据包括在所述阈值时间量内获得的高度动态的信息的数据；以及用于将所确定的第二LDM数据提供给所述移动设备的部件。

v>

与权利要求1对应。