DETAILED ACTION
This non-final office action is in response to claims 1-12 and 26 filed on 06/03/2026 for examination. Claims 1-12 and 26 are being examined and are pending.
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 .
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.
Restriction Election/Amendments
Applicant’s election without traverse of claims 1-12 and 16 in the reply filed 06/03/2026 is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/16/2024 has been considered by the examiner.
Claim Objections
Claim 1 is objected to because of the following informalities:
Claim 1 recites “by the TC node , and the identifier” in line 9. Examiner suggests amending to, e.g., “by the TC node[[ ]], and the identifier”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 8 and 10 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Particularly:
Claim 8 recites “wherein the heartbeat message is expected to be received from the RA node in response thereto” in line 5. “Thereto” is unclear/has unclear bounds as to what specifically is being referenced. Referenced elements should be explicitly referenced. Further, “expected” (line 5) appears to refer to an intent of Applicant, and is unclear what specifically is intended to be claimed.
Claim 10 recites the limitation "the request message" in line 3. There is insufficient antecedent basis for this limitation in the claim.
Consideration Under 35 USC § 101
Note: the claims have been considered and analyzed by the Examiner under 35 USC § 101 with respect to statutory category and judicial exceptions, and appear to recite a form of subject matter statutorily compliant with § 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-6, 9, 11-12, and 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Larsen et al. (NPL: “Direct Anonymous Attestation on the Road: Efficient and Privacy-Preserving Revocation in C-ITS”; June 28, 2021; Hereinafter “Larsen”) in view of Brickell et al. (US20080307223; Hereinafter “Brickell).
Regarding claim 1, Larsen teaches a method for self-revocation, the method being performed by a trusted component, TC, node, wherein the TC node is provided with an identifier and Direct Anonymous Attestation, DAA, credentials (§ 3.1 and 2.1 – a vehicle comprises a trusted computing component <i.e., TC node> that performs TC-enforced revocation. An issuer provides Direct Anonymous Attestation “DAA” credentials to the trusted computing component, and the trusted computing component creates/controls a public pseudonym “pkps” <i.e., identifier>), wherein the TC node is to receive a heartbeat message from a revocation authority, RA, node (§ 4.6 – the trusted component <i.e., TC node> periodically expects either a revocation message or a heartbeat from a Revocation Authority “RA” <i.e., RA node>. A revocation message intended for another trusted component may itself serve as a heartbeat <i.e., heartbeat message>), wherein the heartbeat message comprises a freshness parameter (§ 4.6 – the revocation message/heartbeat <i.e., heartbeat message> may include information identifying the period for which it is intended <i.e., freshness parameter>, such that a heartbeat for one period cannot be used at a different time) and a revocation request with a [[list of identifiers]] for which revocation is pending (§ 4.6 and 2.1 – the RA sends a revocation message comprising the pkps <i.e., identifier> that needs to be revoked. The revocation message may act as a heartbeat message <i.e., heartbeat comprises a revocation request> and identify the pkps/revoked system. The RA re-broadcasts the revocation message/heartbeat until revocation confirmation is received <i.e., the pkps identifier is pending until revocation is confirmed>), and wherein the method comprises:
revoking the DAA credentials when either: the heartbeat message is received from the RA node whilst a counter condition is satisfied (§ 4.6 – a revocation message/heartbeat is generated for each time period by the Revocation Authority. The trusted computing component <i.e., TC node> may tolerate a series of missed heartbeat messages <i.e., counter condition>. The RA message may be received before the tolerated missed heartbeat series is exceeded <i.e., heartbeat message is received whilst the counter condition is satisfied>), correctness of the freshness parameter is verified by the TC node, and the identifier is present [[in the list of identifiers]] (§ 4.6 – heartbeat/revocation message is checked by the trusted computing component <i.e., TC node>. The heartbeat/revocation message comprises intended-period information <i.e., freshness parameter>. The TC verifies the intended-period information to ensure a heartbeat is not used outside its intended-period <i.e., freshness verified>. Further, the revocation message/heartbeat can comprise the pkps <i.e., identifier>); or failing to receive the heartbeat message from the RA node whilst the counter condition is satisfied (§ 4.6 and 3.1 – The Revocation Authority periodically sends our revocation messages/heartbeats. Failing to receive a heartbeat again after a tolerated number of heartbeats <i.e., a counter condition> causes revocation <i.e., counter is satisfied based on the current count or missed heartbeats>; Note: while both have been mapped, the “either […] or” language means only one is required to satisfy the claim as written).
While Larsen teaches the revocation request comprising a single pkps identifier (see, e.g., § 4.6 and 2.1), Larsen appears to fail to specifically disclose that the revocation request is comprising a list of identifiers.
However, Brickell teaches a similar system for revoking credentials in a DAA environment (see, e.g., [0076-077] and [0092-094]), wherein the revocation message comprises a list of identifiers for which the revocation is pending ([0076-077], [0092-094], and [0098-100] – a verifier issues a revocation request and transmits revoked pseudonyms K1, … Kn <i.e., list of identifiers>. The revocation server may sign the list and transmit a revocation message to the trusted member devices. The trusted member devices may then check if their pseudonym is listed in the revoked pseudonyms <i.e., list of identifiers>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsen’s RA messages with the teachings of Brickell, comprising the list of identifiers for which revocation is pending, as well as correctness of the freshness parameter is verified by the TC node, and the identifier is present in the list of identifiers, to permit multiple DAA pseudonym targets to be communicated and processed together in a single message (see, e.g., Brickell at [0076-077], [0092], and [0098]).
Regarding claim 2, the combination of Larsen and Brickell teach the method according to claim 1, wherein the DAA credentials enable the TC node to send authenticated messages towards other TC nodes (Larsen at § 2.1 and 1 – the issuer provides DAA credentials to the trusted computing component <i.e., TC node>. The TC uses DAA to create pseudonym credentials, and DAA signatures are used to self-certify such credentials so they are verifiable by other vehicles. E.g., Fig. 1 shows “Signed Message + PoR” transmitted to another vehicle using DAA sign <i.e., DAA credentials enable the TC node to send authenticated messages towards other TC nodes>).
Regarding claim 3, the combination of Larsen and Brickell teach the method according to claim 1, wherein the identifier is a pseudonym (Larsen at § 2.1 – the TC creates and controls pseudonyms, including the public pseudonym key pkps <i.e., identifier>).
Regarding claim 4, the combination of Larsen and Brickell teach the method according to claim 1, wherein the counter condition is specified by a fixed amount of time, and wherein the counter condition is satisfied as long as the fixed amount of time since receiving a most recent heartbeat message from the RA node has not elapsed (Larsen at § 4.6 – the trusted computing component <TC node> periodically expects a revocation message/heartbeat. Only one revocation message/heartbeat is generated for each time period. Failure to receive a revocation message/heartbeat can trigger revocation. <i.e., each heartbeat time period defines a fixed amount of time after the most recently received heartbeat, with the counter condition remaining satisfied before that time period elapses>).
Regarding claim 5, the combination of Larsen and Brickell teach the method according to claim 1, wherein the heartbeat message is a periodically broadcast heartbeat message (Larsen at § 4.6 – the Revocation Authority periodically broadcasts its signed revocation message/heartbeat. The trusted computing component <i.e., TC node> periodically receives the revocation message/heartbeat.
Regarding claim 6, the combination of Larsen and Brickell teach the method according to claim 1, wherein the freshness parameter is a timestamp (Larsen at § 4.6 – the heartbeat includes information identifying the time period for which it is intended, such that a heatbeat associated with one period cannot be used at a different time <i.e., time-identifying information/timestamp>).
Regarding claim 9, the combination of Larsen and Brickell teach the method according to claim 1, wherein the freshness parameter is a nonce (Brickell at [0045-046] – a nonce may be included in the message to help verify the message was signed at a current time). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Larsen and Brickell with the teachings of Brickell, wherein the freshness parameter is a nonce, to provide a known replay-resistant check for signed messages (see, e.g., Brickell at [0045-046]).
Regarding claim 11, the combination of Larsen and Brickell teach the method according to claim 1, wherein the counter condition is specified by a fixed number of operations, and wherein the counter condition is satisfied as long as the TC node has performed less number of operations than the fixed number of operations since receiving a most recent heartbeat message from the RA node (Larsen at § 4.6 – the TC periodically expects an RA revocation message/heartbeat for each time period. Failure to receives a series of such messages is tolerated to allow for limited connectivity, but once a number have been missed revocation is triggered <i.e., the counter condition permits less than a fixed number of period heartbeat-monitoring operations/misses since the most recent before the tolerated series is exhausted).
Regarding claim 12, the combination of Larsen and Brickell teach the method according to claim 1, wherein the heartbeat message comprises an epoch marker (Larsen at § 4.6 each heartbeat includes information identifying the time period for which it is intended <i.e., an epoch marker>, and only one revocation message/heartbeat is generated for each time period <i.e., each epoch>), wherein the counter condition is specified in terms of epochs, and wherein the counter condition is satisfied as long as a difference between the epoch markers in two adjacently received heartbeat messages is less than a predetermined amount of epochs (Larsen at § 4.6 – because only one RA message is generated for each time period and each message identifies its corresponding time period <i.e., epoch marker>, the time difference between the time-period identifiers of two adjacently received heartbeat messages identifies the intervening missing periods <i.e., difference between the epoch markers>. A specific number of missed messages may be tolerated before revocation is forced <i.e., less than a predetermined amount of epochs>).
Regarding claim 26, Larsen teaches a trusted component, TC, node for self-revocation, wherein the TC node is provided with an identifier and Direct Anonymous Attestation, DAA, credentials (§ 3.1 and 2.1 – a vehicle comprises a trusted computing component <i.e., TC node> that performs TC-enforced revocation. An issuer provides Direct Anonymous Attestation “DAA” credentials to the trusted computing component, and the trusted computing component creates/controls a public pseudonym “pkps” <i.e., identifier>), wherein the TC node is configured to receive a heartbeat message from a revocation authority, RA, node (§ 4.6 – the trusted component <i.e., TC node> periodically expects either a revocation message or a heartbeat from a Revocation Authority “RA” <i.e., RA node>. A revocation message intended for another trusted component may itself serve as a heartbeat <i.e., heartbeat message>), wherein the heartbeat message comprises a freshness parameter (§ 4.6 – the revocation message/heartbeat <i.e., heartbeat message> may include information identifying the period for which it is intended <i.e., freshness parameter>, such that a heartbeat for one period cannot be used at a different time) and a revocation request with a [[list of identifiers]] for which revocation is pending (§ 4.6 and 2.1 – the RA sends a revocation message comprising the pkps <i.e., identifier> that needs to be revoked. The revocation message may act as a heartbeat message <i.e., heartbeat comprises a revocation request> and identify the pkps/revoked system. The RA re-broadcasts the revocation message/heartbeat until revocation confirmation is received <i.e., the pkps identifier is pending until revocation is confirmed>), the TC node comprising processing circuitry, the processing circuitry being configured (§ 1 and 4.6 – system implemented on a computing system processing software) to cause the TC node to:
revoke the DAA credentials when either: the heartbeat message is received from the RA node whilst a counter condition is satisfied (§ 4.6 – a revocation message/heartbeat is generated for each time period by the Revocation Authority. The trusted computing component <i.e., TC node> may tolerate a series of missed heartbeat messages <i.e., counter condition>. The RA message may be received before the tolerated missed heartbeat series is exceeded <i.e., heartbeat message is received whilst the counter condition is satisfied>), when correctness of the freshness parameter is verified by the TC node, and the identifier is present [[in the list of identifiers]] (§ 4.6 – heartbeat/revocation message is checked by the trusted computing component <i.e., TC node>. The heartbeat/revocation message comprises intended-period information <i.e., freshness parameter>. The TC verifies the intended-period information to ensure a heartbeat is not used outside its intended-period <i.e., freshness verified>. Further, the revocation message/heartbeat can comprise the pkps <i.e., identifier>); or failing to receive the heartbeat message from the RA node whilst the counter condition is satisfied (§ 4.6 and 3.1 – The Revocation Authority periodically sends our revocation messages/heartbeats. Failing to receive a heartbeat again after a tolerated number of heartbeats <i.e., a counter condition> causes revocation <i.e., counter is satisfied based on the current count or missed heartbeats>; Note: while both have been mapped, the “either […] or” language means only one is required to satisfy the claim as written).
While Larsen teaches the revocation request comprising a single pkps identifier (see, e.g., § 4.6 and 2.1), Larsen appears to fail to specifically disclose that the revocation request is comprising a list of identifiers.
However, Brickell teaches a similar system for revoking credentials in a DAA environment (see, e.g., [0076-077] and [0092-094]), wherein the revocation message comprises a list of identifiers for which the revocation is pending ([0076-077], [0092-094], and [0098-100] – a verifier issues a revocation request and transmits revoked pseudonyms K1, … Kn <i.e., list of identifiers>. The revocation server may sign the list and transmit a revocation message to the trusted member devices. The trusted member devices may then check if their pseudonym is listed in the revoked pseudonyms <i.e., list of identifiers>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Larsen’s RA messages with the teachings of Brickell, comprising the list of identifiers for which revocation is pending, as well as correctness of the freshness parameter is verified by the TC node, and the identifier is present in the list of identifiers, to permit multiple DAA pseudonym targets to be communicated and processed together in a single message (see, e.g., Brickell at [0076-077], [0092], and [0098]).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Larsen in view of Brickell, further in view of Yavuz et al. (US20130326224; Hereinafter “Yavuz”).
Regarding claim 7, the combination of Larsen and Brickell teach the method according to claim 6, and verifying that the timestamp is not older than a threshold time duration value (Larsen at § 4.6 – the heartbeat includes information identifying the time period for which it is intended, such that a heatbeat associated with one period cannot be used at a subsequent time <i.e., time-identifying information/timestamp. Ensures it is not too old>).
Yet, the combination of Larsen and Brickell appear to fail to specifically disclose wherein the correctness of the freshness parameter is verified by the TC node comparing the timestamp to an internal clock source in the TC node.
However, Yavuz teaches a system for verifying freshness parameters (see, e.g., [0056-058]), wherein the correctness of the freshness parameter is verified by the |node| comparing the timestamp to an internal clock source in the |node| ([0056-058] – the receiving device identifies the timestamp and compares it with the current time maintained in the internal clock. The message is rejected when the timestamp differs by more than a predetermined amount, and after the predetermined timeout period the timestamp is rejected as out of date <i.e., verifying that the timestamp is not older than a threshold time duration value>).
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 combination of Larsen and Brickell with the teachings of Yavuz, wherein the correctness of the freshness parameter is verified by the TC node comparing the timestamp to an internal clock source in the TC node, to prevent replay of stale broadcast messages to the trusted computing component (see, e.g., Larsen at § 4.6; with Yavuz at [0057-058]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Larsen in view of Brickell, further in view of Medvinsky et al. (US20070294526; Hereinafter “Medvinsky”).
Regarding claim 8, the combination of Larsen and Brickell teach the method according to claim 1, as well as wherein the heartbeat message is expected to the received from the RA node (see, e.g., Larsen at § 4.6 – the TC periodically expects a revocation message/heartbeat from the RA). Yet, the combination of Larsen and Brickell appear to fail to specifically disclose wherein the method further comprises: sending a request message towards the RA node for the list of identifiers for which revocation is pending, wherein the request message comprises the freshness parameter, and wherein the heartbeat message is expected to be received from the RA node in response thereto.
However, Medvinsky teaches a similar system for delivering certificate revocations (see, e.g., abstract), wherein the method further comprises: sending a request message |for a revocation list for which| revocation is pending ([0025] – client sends an AS Request requesting that a CRL be included in a corresponding AS Reply <i.e., a request is issued for current revocation information), wherein the request message comprises the freshness parameter ([0025] – the client checks the timestamp of its stored CRL and, when the CRL is expired, sets a flag in the request message indicating a fresh CRL is needed <i.e., freshness indicating parameter>), and wherein the heartbeat message is expected to be received [[from the RA node]] in response thereto ([0025] – the Home-KDC includes the latest non-expired CRL in the corresponding AS reply, which is then received by the client <i.e., revocation information returned in response to the request>).
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 combination of Larsen and Brickell with the teachings of Medvinsky, wherein the method further comprises: sending a request message towards the RA node for the list of identifiers for which revocation is pending, wherein the request message comprises the freshness parameter, and wherein the heartbeat message is expected to be received from the RA node in response thereto, to ensure the trusted component always has updated revocation information if a period has lapsed (see, e.g., Larsen at § 4.6 with Medvinsky at [0025]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Larsen in view of Brickell, further in view of Kim et al. (US20080301793; Hereinafter “Kim”).
Regarding claim 10, the combination of Larsen and Brickell teach the method according to claim 9. Yet, the combination of Larsen and Brickell appear to fail to specifically disclose wherein the correctness of the freshness parameter is verified by the TC node comparing the nonce received in the heartbeat message to the nonce sent in the request message and verifying that the nonce received in the heartbeat message corresponds to the nonce sent in the request message.
However, Kim teaches a similar system for verifying and managing certificates for devices (see abstract), wherein the correctness of the freshness parameter is verified by the TC node comparing the nonce received in the heartbeat message to the nonce sent in the request message and verifying that the nonce received in the heartbeat message corresponds to the nonce sent in the request message ([0010-011], [0040], and [0043-045] – a requesting device generates a nonce and sends a request message containing the nonce. The response message includes the nonce obtained from the request message. The requesting device extracts the nonce from the received response and compares it with the generated/sent nonce. The response is determined reliable when the nonces correspond <i.e., verifying freshness by comparing the received none to the nonce sent in the request message>).
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 combination of Larsen and Brickell with the teachings of Kim, wherein the correctness of the freshness parameter is verified by the TC node comparing the nonce received in the heartbeat message to the nonce sent in the request message and verifying that the nonce received in the heartbeat message corresponds to the nonce sent in the request message, to prevent replace attacks and verify that a response is fresh/reliable (see, e.g., Kim at [0008-011] and [0043-045]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Whitefield et al. (NPL: “Privacy-Enhanced Capabilities for VANETs using Direct Anonymous Attestation”; November 28, 2017) teaches DAA-based V2X revocation in which an RA sends revocation/heartbeat messages to a trusted component, and missed heartbeats can trigger renovation by the TC (see, e.g., Whitefield at § V.D and VI.B). Zilbershtein et al. (US20220417028) teaches a periodic security heartbeat carrying server time and a revoke command, with the client removing stored cryptographic keys upon a revoke command or heartbeat-process failure (see, e.g., [0053], [0105-108]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA RAYMOND WHITE whose telephone number is (571)272-4365. The examiner can normally be reached Monday-Thursday, & Alternate Fridays.
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, Taghi Arani can be reached at 5712723787. 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.
/J.R.W./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights