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, 6-12, 15-20 are subject to examination. Claim 4, 5, 13, 14 are cancelled.
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 and CHENG, CN 110879876 A, LEPP et al., CA 3092883 A1, and
IEEE Standard for Wireless Access in Vehicular Environments-Security Services for Applications and Management Messages, IEEE Vehicular Technology Society, IEEE Std 1609.2 -2016 (Applicant provided IDS).
Referring to claim(s) 1, Kim substantially 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, 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, 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 do not specifically mention about, which is well-known in the art, which Cheng, discloses,
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 before 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 and Cheng do not disclose, which LEPP discloses,
a Public Service Identifier (PSID) and a Service Specific Permission (SSP), wherein the PSID indicates an application to which the safety assurance indication is applicable, the safety assurance indication providing that at least one of hardware and software at the entity, at least one of functional safety of the entity and a safety of an of the entity
[0059] transmitting a data frame to another device with PSID/ SSP in an application layer message and invoke the lower-level layer of the device 104 to transmit the data frame with features of a specific
rate bucket based on PSID value. The rate bucket used can be set on a per-frame basis.
[0060] Note that a Service Specific Parameter refers to another layer of permissions below PSID. An application can include a PSID and multiple SSPs. For instance, vehicles can be assigned a single PSID for BSMs. The BSMs can be assigned permissions assigned by SSP and PSID values. For example, a first responder vehicle may have been allocated a PSID and SSP for BSMs similar to any other
driver, but a separate set of SSPs for first responder messages.
[0062] The application layer message prepared by the upper layer software 117 can
include an Intelligent Transportation System (ITS) message, such as a Basic Safety
Message (BSM), a Map Data/Signal Phase and Time (MAP/SPAT) message, a
Cooperative Awareness Message (CAM), a Decentralized Environmental
Notification Message (DENM), or other message. In other examples, the upper layer software
117 can send a different type of application layer message.
the SSP indicate indicates information that is applicable,
[0057] To provide backward compatibility, the rate bucket used to transmit a data
frame may be bound to the application. For example, Dedicated Short Range Communication (DSRC) BSM messages are sent at 6 Mb/s (using QPSK, 1/2 coding rate, convolution coding) in order to interoperate with IEEE 802.11p legacy systems. DSRC new applications (possibly termed Next Generation V2X (NGV) – capable applications, e.g. as defined by IEEE 802.11bd) can be defined to only use new rates from a new rate bucket.
[0021] In the next generation of IEEE 802.11 physical layers, there are Multiple different requirements pulling in different directions: long range, higher data rate, larger frame sizes, higher reliability, and so forth. Also, V2X applications or services can have requirements that differ from those of other types of communications. Generally, an application may not have a way to easily request a type of radio
communications with target properties for transmitting data frames.
wherein each of a subset of bits of the SSP are used to indicate information, a transmitter, intended functionality (
[0048] conveying using bits used to indicate multiple independent features.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the 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 what is the PSID and SSP in computer science and networking, 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, para 59.
Kim, LEPP, Cheng do not disclose, which IEEE discloses,
Note: Applicant’s specification mentions and contains portions of IEEE 1609.2 standard teachings. Please see for example, at para 69, 67, 68, 69, 70, 148, 62, 63, and 52, 53, 31, 54 (including assurance level).
an application area to which the safety assurance indication, to an indicated value (
Service Specific Permissions (SSP): A field that indicates the permissions of a particular certificate holder with respect to a particular application area, page 4
Provider Service Identifier (PSID): An identifier of an application area, page 3
Provider Service Identifiers (PSIDs) are used in certificates to specify permitted application areas. The PSID is defined in IEEE Std 1609.12nM. A Service Specific Permission (SSP) is provided (explicitly or implicitly) for each PSID in the Application Permissions, identifying specific sender permissions within that PSID's application area. The syntax and semantics ofthe SSP are specific to each PSID value, page 5
psid indicates the application area with which the sender is claiming the payload should be associated, page 7
This structure represents the permissions that the certificate holder has with respect to data for a single application area, identified by a Psid., page 8
As discussed in 5.2.3.3.3, the IEEE 1609.2 certificate provides two fields that are used to determine that the payload of a signed SPDU is consistent with the permissions of the sender. The PSID field indicates that the sender is entitled to send payloads associated with the application area indicated by the PSID field. The SSP field indicates that the sender has permissions to send specific payload types within that application area. The definition of application behavior within the application area includes the mapping from payload contents to the permissions (PSID and SSP) that determines the validity of the payload: in other words, one of the responsibilities of a PSID owner is to define the syntax and semantics of the SSP and to define which payloads are permitted by specific SSPs. The determination that a payload is consistent with the PSID), last para, page 218.
compliance with a corresponding safety assurance level, certified to a safety assurance level
(assurance Level (field), page 36, safety applications, page 3, using bits/octets (size bits), para 36, psid/ssp, page 82)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the 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 application area and safety assurance level associated with PSID and SSP. One of ordinary skilled in the art would readily know what is the PSID and SSP in computer science and networking, Hence, the associated PSID would enable responders for the application area to track information, and the SSP would enable defining permission regarding safety assurance level for the access control associated with the service, para 59.
Referring to claims 10 and 19, the apparatus/medium claims are similarly analyzed and rejected for the same rationale as the method claim 1.
Claim(s) 2, 11, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of Cheng, LEPP, IEEE and Alrabady et al, 20140075517.
Referring to claim(s) 2, 11, 20, Kim, LEPP, IEEE, Cheng 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 before 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 LEPP, IEEE, CHENG
Referring to claim(s) 3, 12, KIM in view of LEPP, IEEE, CHENG discloses wherein: when the safety assurance indication is regarding the functional safety of the transmitter of the ITS entity (kim, as per the citations in claim 1), the safety assurance indication is an aggregation of a functional safety assurance level indication, and at least one of; a Safety of the Intended Function assurance level indication, and a cybersecurity assurance level indication (IEEE, as per the citations in claim 1); and when the safety assurance indication is regarding the safety of the intended functionality of the second ITS entity (IEEE, as per the citations in claim 1 associated with the responders), 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 (IEEE, as per the citations in claim 1 associated different assurance levels with the responders)
Claim(s) 6, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over KIM in view of LEPP, IEEE, CHENG, and ALDANA et al., WO 2019010049 A1.
Referring to claim(s) 6, 15, the safety assurance indication is cited in claim 1. Kim, LEPP, IEEE, CHENG 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 before 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 LEPP, IEEE, CHENG and WU, WO 2018096449 A1.
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, LEPP, IEEE, CHENG, does not specifically mention about, explicit field, which is WU discloses,
[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 before 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 LEPP, IEEE, CHENG, and Amin etal., US 20120079487 A1.
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, LEPP, IEEE, Cheng does not specifically mention about, the explicit field has enumerated, discrete values, which is well-known in the art.
[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 before 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 Cheng, LEPP, IEEE and D'Ercoli et al., US 20190312928 A1.
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, Cheng, LEPP, IEEE 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.
[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 before 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 5/12/26, have been fully considered but they are not persuasive. Therefore, rejection of claims 1-3, 6-12, 15-20 is maintained.
Regarding the concerned for the claims with amended limitations, the rejections are updated accordingly.
The rejections for the amended limitations are made using LEPP et al., CA 3092883 A1, and
IEEE Standard for Wireless Access in Vehicular Environments-Security Services for Applications and Management Messages, IEEE Vehicular Technology Society, IEEE Std 1609.2 -2016 (Applicant provided IDS).
Regarding the remarks, IEEE also discloses the claimed indicated value (PSID value etc., values, page5)
Conclusion
Use of SSP and PSID is well-known in the art. Please see Applicant cited IEEE reference (IDS and specification portions of the IEEE reference).
Pertinent prior arts:
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
GHOSH
[0017] 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] 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.
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
Prosecution Insights