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
Abstract
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details. The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The present disclosure relates to,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided. Applicant’s abstract is objected to because it includes the language of “The invention discloses…”. Appropriate correction is required.
Specification Objections
The specification contains at least the following deficiencies: (a) Over 25 symbols and variables are used throughout the specification including Av, Hv, ri`, ri2, ri3, BV, CV, Kj, Ma-M5, MSF1-MSG4, N1, N2, mi, nj, Ski, SKj, n, E(.), D(.), resi, X,X*,R1,R2) but are never formally defined in the symbol table (Table 1, para 0067);
(b) The symbol "ski"/"skj" is overloaded to refer to both the vehicle's chameleon hash private key and the RSU's derived private key, rendering the protocol description ambiguous;
(c) The symbol "n" is overloaded to refer to both a modulus parameter n E (24, 28) para 0011) and a random number nj para 0019);
(d) The symbol "m"/"mi" is overloaded to refer to both a message to other vehicles (para 0023) and a random number for authentication (para 0016);
(e) The expression at para 0019/0056," (skj\\lli"'\\-t3) = Dskj(skj\\JV{':'1\-ts)/' does not appear to have a reasonable interpretation. The plaintext and encryption appear to be the same
Drawing Objections
The drawings are objected to because they are not legible.
Claim Objections
Claims 1 – 5 and 7 are objected to for failing to have proper sentence structure. The claims are not properly constructed complete sentences.
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.
Claims 1 – 7 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 pre-AIA the applicant regards as the invention.
Claim 1 recites “…all trusted authorities jointly maintain an editable blockchain..."; however, the specification exclusively uses the term “redactable blockchain” throughout (see Title, para 0001 – 0005, 0041 – 0045 and 0068 – 0069). The term “redactable blockchain” has an accepted meaning in the art referring to a blockchain using a chameleon hash function to permit authorized content modification while preserving chain integrity, which is the precise mechanism described in the specification. The term “editable blockchain” is broader and could encompass any blockchain modification mechanism (e.g., hard forks, governance-based rewrites, or simple database edits). Because the claim uses different terminology than the specification without clear redefinition, a person of ordinary skill in the art cannot reasonably determine whether "editable blockchain" is intended to be coextensive with the specification's “redactable blockchain” or broader. The metes and bounds of this limitation are therefore unclear. See MPEP §2173.0S(a) (“[t]he meaning of every term used in a claim should be apparent from the prior art or from the specification and drawings”).
Claim 1 line 3 further recites “…trusted authority of choice,”; however, it is unclear to The Examiner who is making the choice and under what criteria the choice made. Claim 1 line 8 recites “…which feedback the registration information…”; however, The Examiner does not understand what this phrase means in any manner that allows the search for prior art. Claim 1 line 13 recites “…the information…”; however, it is unclear what information is being referenced. It is unclear if it is the previous claimed registration information or to some other information. In addition, claim 1 further recites that the trusted authority “feedback[s] the registration information to the vehicle and the roadside unit, and stores the registration information ... in the on-board unit OBU of the vehicle and the storage unit of the roadside unit, respectively.” However, neither the claims nor the specification define what constitutes "”registration information” with any precision. The specification's S2 sub-steps para 0010 – 0013 and 0047 – 0050 describe that different information is sent to the vehicle ( {M, ri2 ,pki, ski}) then is sent to the RSU ({ RI D1, sk_7}), and different information is stored on the blockchain ({ Hv, M, pki, Av, ril, I Di}). It is therefore unclear whether “registration information” in Claim 1 refers to all of these collectively, only the subset fed back to the entity, or some other combination. One of ordinary skill in the art would have at least two reasonable interpretations of the scope of this term.
Claim 1 further recites “…the RSU authenticates the vehicle's identity based on the blockchain." The specification describes a multi-step protocol (S3.1-S3.6, para 0015 – 0020 and 0052 – 0057) involving biometric verification, PUF challenge response, ECDH key exchange, chameleon hash verification, smart contract invocation, and session key negotiation. However, the claim does not specify which of these steps constitute “authenticate” and which are separate steps (e.g., key negotiation, parameter updating). Because the specification describes a continuous protocol where authentication, key exchange, and parameter updating are interleaved, a POSITA cannot determine the boundary of the “authenticates” step versus the “negotiates the session key” and “update the locally stored authentication parameters” steps that follow it in the same claim. The metes and bounds of when “authentication” ends and “key negotiation” begins are not clearly delineated.
Claim 1 further recites “…a method…” with steps performed by at least four distinct actors: (a) “all trusted authorities” (who choose keys, maintain blockchain, deploy smart contracts); (b) “the vehicle and roadside unit RSU” (who submit registration); (c) “the RSU” (who authenticates); and (d) “the trusted authority” (who updates the blockchain). It is unclear who practices “the method.” Under BRI, a method claim should identify the entity performing the recited steps with sufficient clarity for one of ordinary skill in the art to understand how infringement would occur. Here, because the method requires coordinated action by vehicles, RSUs, smart contracts, and trusted authorities - none of which are under common control - the claim fails to clearly delineate its infringement boundary. See MPEP §2173.02
Claim 1 lines 11 – 12 recites “…the vehicle validity period…”; however, it is unclear what this is referring to. Claim 1 line 14 recites “…the vehicle’s authentication information…”; however, it is unclear if this refers to the RSU authenticated vehicle identity or to something else. Claim 1 lines 14 – 15 recite “…a certain period of validity…”; however, it is unclear what time period qualifies. Claim 1 line 17 recites “…receiving the message…”; however, it is unclear what the message refers to.
Claim 2 line 1 recites “According to a method for identity…”; however, it is unclear if this is referring to the method of claim 1 or to some other method. Claim 2 line 2 recites “…based on a redactable blockchain in claim 1, S2 specifically comprises…”; however, it is unclear if this references the only recitation of redactable in claim 1 line 2 and should be worded “the redactable blockchain”, or if it is a missing limitation from claim 1 or if this is a typo or something else. In addition, it is not clear if S2 refers to claim 2 or something else. Claim 2 line 3 recites “S2.1…it to TA…”; however, both S2.1 and TA are undefined. Claim 2 line 4 recites “EskTA” but this variable is undefined. Claim 2 line 6 recites “r12…ch_cldski…”; however, these variables are undefined. Claim 2 page 2 line 3 recites “S2.2…”;however, S2.2 is undefined. Claim 2 page 2 line 4 recites “…αi, βi…Gen…chai…”; however, these variables are undefined. Claim 2 page 2 line 5 recites “…BV…h…Eresi”; however, BV and h are not defined. Claim 2 page 2 line 5 recites a range for the variable “n”; however, this expression is ambiguous because: (a) it is unclear whether the parentheses denote an open interval (excluding endpoints 16 and 256) or merely indicate a range; (b) modular reduction by a number between 16 and 256 produces a hash output of only 4-8 bits, which is cryptographically meaningless for security purposes in the art; and (c) the symbol “n” is used nowhere else in the claims or specification as a variable name, yet it collides with common notation for an RSA modulus or a group order in elliptic curve cryptography – as a result of multiple reasonable interpretations being present, one of ordinary skill in the art cannot reasonably determine the metes and bounds of the claim. Claim 2 page 2 lines 7 – 11 recites various variables with a j subscript; however all are not defined because amongst other things, j is not defined. The claim also recites variables including "Av," "Hv," "ril, Cv, Ev, and the biometric parameters (corresponding to ai and /3i).None of these variables are introduced with antecedent basis in claim 1 and several are not defined in Table 1 of the specification (see para 0066). The Examiner asserts the sheer volume of undefined variables and terms in a cryptographic protocol claim – where each variable’s precise identity is critical to understanding what the claim covers - renders the scope indeterminate.
Claims 1 – 7 are also rejected for being replete with undefined variables and acronyms. As a result, the metes and bounds of the claim are not clear and the claims cannot be searched for appropriate prior art. Appropriate correction is required for all undefined variables and terms.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
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.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights