Prosecution Insights
Last updated: October 01, 2026
Application No. 19/192,882

Access Control for a Motor Vehicle

Non-Final OA §101§102§103§112
Filed
Apr 29, 2025
Priority
May 06, 2024 — DE 10 2024 112 709.0
Examiner
HABASHI, DANIEL MONIS S
Art Unit
2431
Tech Center
2400 — Computer Networks
Assignee
Bayerische Motoren Werke Aktiengesellschaft
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-58.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
8 currently pending
Career history
11
Total Applications
across all art units
This examiner has no resolved cases yet (career too new); statute-level performance unavailable. The Grant Probability card shows Tech Center averages instead.

Office Action

§101 §102 §103 §112
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Information Disclosure Statement The information disclosure statements (IDS) submitted on April 29, 2026 (hereinafter “IDS1”) and May 27, 2026 (hereinafter “IDS2”) are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner. Claim Objections Claims 18-20 are objected to because of the following minor informalities: Claims 18, 19, and 20 are objected to as being unclear in their construction and format. The claims do not identify a clear statutory category under 35 U.S.C. §101 (“process, machine, manufacture, or composition of matter”) and do not use a known transitional phrase (MPEP §2111.03: “comprising”, “consisting essentially of”, “consisting of”), leading to uncertainty to the nature and scope of the claimed invention. Appropriate correction is required. Claim Interpretation Regarding claim 1, the claim recites “determining, by an owner device, a key request…”. It is unclear what operations are included in “determining… a [] request”. For purposes of examination of the instant application, “determining… a key request” shall be construed as “generating, receiving, or being notified of… a key request.” Examiner notes that different processes and actions should be distinctly and clearly claimed, and that “determining” may lead to confusion as to the metes and bounds of the claims. Further regarding claim 1, the claim recites “transmitting, by the owner device, the key request and the nonce to a friend device”. Examiner interprets the claim as “transmitting, by the owner device, the key request to a friend device, and transmitting, by the owner device, the nonce to the friend device” in order to clarify that the values need not be sent together, as made clear by claims 13-14. Further regarding claim 1, the claim recites “determining… a[n] identification… by using a predetermined cryptographic hash function to the key request and the nonce…”. Examiner first notes that “using a… hash function to the [inputs]” is more correctly drafted as “applying a… hash function to the inputs…”. For purposes of examination of the instant application, the claim shall be interpreted as such. Secondly, as presently written, there is no requirement to combine the key request and the nonce prior to applying the hash function. In other words, the claim language encompasses hashing a nonce and hashing a key request separately, which the language of the specification clarifies is not the case (see Specification ¶0011). Further regarding claim 1, the claim recites steps including essentially “determining [an] identification by [applying] a predetermined cryptographic hash function to [a value] and [a] nonce”. Examiner understands these steps as including the process of “salting” as would be understood by a person having ordinary skill in the art and as described in the specification (see Specification ¶0010: “In other words, it is proposed that the hash should include a random value ("salt"), so that a "salted hash" is created.”). However, Examiner notes that this is not a limitation which may be imported from the specification into the claims. Further regarding claim 1, the claim recites “providing, by the key management, the new digital vehicle key.” Examiner notes that there is no requirement that the “determining… that the first and the second identification match…” must succeed (i.e., that the identifications do match) before “providing… the new digital vehicle key”. Examiner recommends clarifying that the key is provided when the identifications match, and is not provided when they do not match. 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 4-12 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. Each of the claims recites a “PIN”. There is insufficient antecedent basis for this limitation in the claim. While “PIN” may be understood in common parlance, acronyms in the claims should be defined upon first use. For purposes of examination of the instant application, “PIN” shall be interpreted as “personal identification number”. Claim Rejections - 35 USC § 101 The following is a quotation of 35 U.S.C. 101: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 18, 19, and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to nonstatutory subject matter. Claims 1-20 are further rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract ideas without significantly more. The Alice/Mayo two-part test is the only test that should be used to evaluate the eligibility of claims under examination. MPEP §2016 (I). Examiner’s analysis under this test is set forth below. Step 1 Claims 1-17 are directed to a process (a “method”) which is a statutory category. Claims 18 and 19 are directed to a manufacture or machine (a “first mobile device” and “second mobile device” respectively). However, when the broadest reasonable interpretation (BRI) of the claim language is considered, this includes transitory signals or a computer program comprising purely software, often called signals or software per se respectively, which do not have tangible structure. The claims each recite a “device” which merely determines or transmits data, which are functions performable merely by software. MPEP §2106.03: “As the courts' definitions of machines, manufactures and compositions of matter indicate, a product must have a physical or tangible form in order to fall within one of these statutory categories.” Therefore claims 18 and 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to nonstatutory subject matter. Claim 20 is directed to a “key management”, which may be a manufacture or machine, but may include other non-statutory material when the broadest reasonable interpretation (BRI) of the claim language is considered. This includes transitory signals or a computer program comprising purely software, often called signals or software per se respectively, which do not have tangible structure. The claim recites that the “management” merely receives identifications, compares them, and issues a digital vehicle key, which are functions performable by software, hardware, or a human. Therefore claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to nonstatutory subject matter. Examiner notes that claims 18-20 may be easily amended to claim statutory matter, and are therefore further considered for patentability. Step 2A, prong 1 Claims 1, 18, 19, and 20 describe: Determining a key request Determining a nonce Transmitting data Applying a hash function Determining whether identifications match which are all mathematical calculations or mental processes performable with the aid of a generic computer. Therefore, claims 1 and 18-20 recite an abstract idea. Claims 2-4 further describe: Depositing a key request to a deposit service in a mailbox Transmitting an address of the mailbox Downloading the key request from the mailbox Transmitting a digital vehicle key Transmitting an attestation of the digital vehicle key which are also mental processes performable with the aid of a generic computer. Claims 5-7 further describe: Creating a PIN Transmitting a PIN Comparing PIN values which are also mathematical calculations or mental processes performable with the aid of a generic computer. Claims 8-17 provide additional details on the abstract ideas of claims 1-7. Therefore, claims 2-17 also recite abstract ideas. Step 2A, prong 2 Claims 1-20 describe additional elements (a motor vehicle, a PIN, transmission channels). These elements are not integrated into a practical exception or improve the performance of a computer because it merely invokes generic computer components (MPEP §2106.05(b)). Step 2B Claims 1-20 do not describe anything beyond what is well understood, routine, and conventional activity. Therefore, claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract ideas without significantly more. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claim 20 is rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 20220014353 by Lim et al. as submitted in IDS1 (hereinafter “Lim”). Regarding claim 20, Lim describes: A key management (Fig. 3, 210) configured to: receive first identification (Fig. 14A: eID; see also [0342]: “eID may perform a function of transaction ID during the whole digital key sharing process.” and Fig. 8A: eID-A) of a key request ([0383]: “In operation S1810, the owner device 100 according to an embodiment may transmit digital key configuration data to the target device 300.”) for a new digital vehicle key ([0046]: “The owner device 100 may control various operations of the vehicle by using the stored digital key.”) for a motor vehicle (Fig. 3, 10) from an owner device (Fig. 3, 100); receive a second identification (Fig. 8B: S850-S860) of the key request for the new digital vehicle key for the motor vehicle from a friend device (Fig. 3, 300); determine that the first identification and the second identification match ([0201]: “The second backend server 230 stores eIDB and eIDA by connecting (or matching) eIDB and eIDA.”); and provide the new digital vehicle key (Fig. 14C, S1490 provides the key to Owner Device 100. Fig. 14D, S14100 provides the key back to the Target Device 300). 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1-4, 13-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 20220014353 by Lim et al. as submitted in IDS1 (hereinafter “Lim”) in view of US 20180213405 by Jung et al. as submitted in IDS1 (hereinafter “Jung”). Regarding claim 1, Lim discloses: A method for creating a new digital vehicle key for a motor vehicle, the method comprising: determining, by an owner device (Lim Fig. 18, S1810: “Transmit Digital Key Configuration Data”; [0383]: “In operation S1810, the owner device 100 according to an embodiment may transmit digital key configuration data to the target device 300.”), a key request (Lim [0383]: “In operation S1810, the owner device 100 according to an embodiment may transmit digital key configuration data to the target device 300.”) for the digital vehicle key (Lim [0046]: “The owner device 100 may control various operations of the vehicle by using the stored digital key.”); [] transmitting, by the owner device, the key request [] to a friend device (Lim Fig. 18, S1810: “Transmit Digital Key Configuration Data”); determining, by the owner device, a first identification of the key request [] (Lim Fig. 14A: eID; see also [0342]: “eID may perform a function of transaction ID during the whole digital key sharing process.” and Fig. 8A: eID-A); transmitting, by the owner device, the first identification (Lim Fig. 8C, S8100) to a key management (Lim Fig. 8C: 210, where S8100 passes through 210. See also Fig. 14A: S1410 and 210); determining, by the friend device, a second identification of the key request [] (Lim Fig.8A: eIDB); transmitting, by the friend device, the second identification (Lim Fig. 8B: S850-S860) to the key management (Lim Fig. 8B, S860 and 210. See also Fig. 14A: 210); determining, by the key management, that the first and the second identification match (Lim [0201]: “The second backend server 230 stores eIDB and eIDA by connecting (or matching) eIDB and eIDA.”); and providing, by the key management, the new digital vehicle key (Lim Fig. 14C, S1490 provides the key to Owner Device 100. Fig. 14D, S14100 provides the key back to the Target Device 300.). Lim does not disclose the use or transfer of a nonce. Lim also does not disclose using a cryptographic hash function on the key request or the nonce, together or separately, to generate either the first or second identification. However, Jung discloses: determining, by the owner device, a nonce (Jung Fig. 3: “3. Transfer Nonce”); and determining, by the owner device, the first identification of the key request by using a predetermined cryptographic hash function (Jung Fig. 8, 819: ShrToken = Hash(Input Data, DK.Sharing)) to the key request and the nonce (Jung [0208]: “For example, the sharing token may be generated based on the DK, or the key which has the authority equivalent to the DK and the nonce provided from the service provider 807”; see Fig. 8, 813). Lim and Jung are both art analogous to the claimed invention because all are directed towards digital key technology. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to hash the key request (or data derived from it) along with a random nonce (i.e., to salt the key request hash) to generate an identifier, as taught by Jung, to ensure the identifier cannot be re-used, as salting data is often used to prevent reuse of a token (Jung [0143]: “…the nonce is used for preventing reuse of the sharing token.”) Lim does not disclose determining, by the friend device, the second identification of the key request by applying the predetermined cryptographic hash function to the key request and the nonce. Jung, however, does disclose the owner transmitting an encrypted version of the first identifier (Jung Fig. 9A: 927-929) which the friend decrypts (Jung Fig. 9A: 931) and uses to perform further verification with the key management (Jung Fig. 9B). This motivates one of ordinary skill in the art to provide another way for the friend device to compute the identifier in order to perform further verification. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to transmit the nonce to the friend device in order to generate a second identification which can be transmitted to and authenticated by the key management server while simultaneously preventing reuse of tokens (Jung [0143]: “…the nonce is used for preventing reuse of the sharing token.”) Regarding claim 2, Lim in view of Jung discloses: The method according to claim 1, wherein the owner device deposits the key request (Lim Fig. 14A: S1410) to a deposit service in a mailbox (Lim Fig. 14A: 210, where the server acts as a mailbox deposit service) and transmits an address of the mailbox (Lim Fig. 14A: eID. See also [0342]: “eID may include information of the service provider server 210 (for example, a name, an address, or an identifier of a service provider or service provider server 210)”) to the friend device (Lim Fig. 14A: S1430), and the friend device downloads the key request from the mailbox (Fig. 14B: S1440-S1450). Regarding claim 3, Lim in view of Jung discloses: The method according to claim 1, wherein the key management transmits the new digital vehicle key to the friend device (Lim [0376]: “…the owner device 100 may transmit the digital key to the target device 300 via the first and second backend servers 220 and 230, and the service provider server 210.”) and transmits a new attestation of the new digital vehicle key (Lim Fig. 14D: S14110 shows Service Provider 210 transmits the key sharing attestation through Backend Server 230 to the Target Device 300) to the motor vehicle (Lim [0365]: “The target device 300 may control the electronic device 10 by using the digital key sharing attestation.”). Claim 4 recites essentially the same material as claim 3, and is rejected on similar grounds. Regarding claim 13, Lim in view of Jung discloses: The method according to claim 1, wherein the nonce is transmitted from the owner device to the friend device (Lim in view of Jung, as described above, motivates direct transmission of the nonce from the owner device to the user device; see also Jung Fig. 9A, 923) on a different transmission channel than the key request (Lim Fig. 14A, S1410-Fig. 14B, S1420: the key request arrives at the target device through the backend server, not through direct communication as the nonce may be). It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to transmit the nonce and key request through different channels in order to prevent an eavesdropper from exploiting a single insecure channel as a point of failure. One of ordinary skill in the art would appreciate that a replay or other man-in-the-middle (MITM) attack becomes more difficult when there are fewer channels that need to be monitored. Claim 14 recites essentially the same material as claim 13, and is rejected on similar grounds. Regarding claim 15, Lim in view of Jung discloses: The method according to claim 1, wherein the nonce comprises a random or pseudo-random character string (Jung [0508]: “…the service provider generates a nonce as a random variable…”). Claim 16 recites essentially the same material as claim 15, and is rejected on similar grounds. Claim 18 discloses: A first mobile device configured to perform the actions performed by the owner device in claim 1. Therefore, the content of claim 17 can be found entirely within claim 1, and is rejected for the grounds set forth therein. Claim 19 discloses: A second mobile device configured to perform the actions performed by the friend device in claim 1. Therefore, the content of claim 18 can be found entirely within claim 1, and is rejected for the grounds set forth therein. Claims 5-12 are rejected under 35 U.S.C. 103 as being unpatentable over Lim and Jung as applied to claims 1-4 above, and further in view of US 20210250355 by Galdo et al. as submitted in IDS1 (hereinafter “Galdo”). Regarding claim 5, Lim in view of Jung discloses: The method according to claim 1 wherein the friend device uses a one-time passcode (OTP) for verification which is generated by the server (Lim [0262]: “In operation S1040, the service provider server 210 transmits a onetime passcode (OTP) to the target device 300 via a second communication channel…”; see also Fig. 10C); wherein the friend device transmits the OTP together with the second identification to the key management (Lim Fig. 10B: S1050); and wherein the key management determines that the OTP of the owner device matches the OTP received from the friend device (Lim Fig. 10C: S1060). Lim in view of Jung does not disclose the remainder of the claim, including the owner device selecting or using a predetermined personal identification number (PIN). However, Galdo discloses that: the owner device creates a PIN (Galdo [0039]: “In still another embodiment, the owner may choose any PIN and give it to the friend and may also encrypt the PIN with the public key of the property 18.”), transmits the PIN to [] the friend device (Galdo [0039]: “…give it to the friend…”). Galdo is art analogous to the claimed invention because both are directed towards digital key technology used to secure vehicles (Galdo Fig. 1, 18). It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to use a PIN as taught by Galdo instead of an OTP as taught by Lim in view of Jung in order to allow an owner to set one number that is shared as a form of verification between the parties, reducing friction at time of use while ensuring both that the owner of the vehicle and the recipient are not being impersonated. One of ordinary skill in the art would appreciate that an impersonator would not know the predetermined PIN of the owner (to provide fraudulent access), and an impersonator similarly also have a harder time convincing a legitimate owner to provide the PIN (to receive fraudulent access). Neither Lim in view of Jung nor Galdo explicitly recites that the owner device transmits the PIN to the key management. Rather, Lim’s OTP is provided by the server itself (Lim Fig. 10B: S1040). Galdo relies on the property and the owner generating the PIN separately from the same data, or in another embodiment relying on asymmetric encryption principles, to receive and verify the PIN (Galdo [0039]). However, it would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, for the owner device to directly transmit the PIN to the server in order to allow for comparison between the owner’s PIN and the PIN supplied by the user, rather than rely on server- or vehicle-side generation of the correct PIN as in Lim or Galdo. Claim 6 recites essentially the same material as claim 5, and is rejected on similar grounds. Claim 7 recites essentially the same material as claim 5, and is rejected on similar grounds. Regarding claim 8, Lim in view of Jung and Galdo discloses: The method according to claim 5, wherein the PIN is transmitted (Galdo Fig. 12: 40, 42, 44) on a different transmission channel than the key request (Galdo Fig. 12: Galdo performs the functions of the “Digital Key Configuration Data” of Lim through the Key Tracking Server 110, Relay Server(s) 142, and associated actions) from the owner device to the friend device (Galdo Fig. 12: 40, 42, 44). Claim 9 recites essentially the same material as claim 8, and is rejected on similar grounds. Claim 10 recites essentially the same material as claim 8, and is rejected on similar grounds. Regarding claim 11, Lim in view of Jung and Galdo discloses: The method according to claim 5, wherein the URL and session key are transmitted from the owner device to the friend device on a different transmission channel than the PIN (Galdo Fig. 2: 40, 42, 44; see also [0038]: “The second form of security [the PIN] may be transmitted via a separate channel from the URL and session key. For example, arrow 32 [in Fig. 2] may represent a transmission as a text message, iMessage, or any other messaging app. The arrow 44 may be transmitted orally, via phone call, or transmitted using a different messaging app or text system.” In other words, Galdo transmits the PIN via a dedicated channel not used for other operations.). Lim in view of Jung and Galdo does not explicitly include the nonce alongside the URL and session key in Fig. 2, or in the equivalent values in other embodiments described by Galdo (e.g., 72 and 74 in Fig. 4, 102 and 103 in Fig. 7, 140 in Fig. 12, etc.). It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to transmit the PIN and nonce through different channels in order to prevent an eavesdropper from exploiting a single insecure channel as a point of failure. One of ordinary skill in the art would appreciate that a replay or other man-in-the-middle (MITM) attack becomes more difficult when there are fewer channels that need to be monitored. Regarding claim 12, Lim in view of Jung and Galdo discloses: The method according to claim 8, wherein the URL and session key are transmitted from the owner device to the friend device on a different transmission channel than the PIN (Galdo Fig. 2; see also [0038]: “The second form of security [the PIN] may be transmitted via a separate channel from the URL and session key. For example, arrow 32 may represent a transmission as a text message, iMessage, or any other messaging app. The arrow 44 may be transmitted orally, via phone call, or transmitted using a different messaging app or text system.”). Lim in view of Jung and Galdo does not explicitly include the nonce alongside the URL and session key in Fig. 2, or in the equivalent values in other embodiments described by Galdo (e.g., 72 and 74 in Fig. 4, 102 and 103 in Fig. 7, 140 in Fig. 12, etc.). It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to transmit the PIN and nonce through different channels in order to prevent an eavesdropper from exploiting a single insecure channel as a point of failure. One of ordinary skill in the art would appreciate that a replay or other man-in-the-middle (MITM) attack becomes more difficult when there are fewer channels that need to be monitored. Examiner notes that claim 12 is not found to recite essentially the material of claim 11 because the requirement of claim 8 that the PIN and key request be sent via distinct communication channels (alongside the further requirement that the PIN and nonce be sent via distinct channels) meaningfully differentiates claim 11’s scope from claim 12’s. Furthermore, Examiner notes that claim 12 does not require that the nonce and PIN be sent on distinct channels- an embodiment wherein the PIN is sent through channel A (e.g., orally, as described by Galdo) while the nonce and key request are sent through the channel B (e.g., through an intermediate server, as described by Lim). Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Lim in view of Jung as applied to claim 1 above, and further in view of “Salt (Cryptography)” on Wikipedia, as stored on April 10, 2023 on the Internet Archive (hereinafter “Wiki”). Regarding claim 17, Lim in view of Jung discloses the method of claim 1. Lim in view of Jung does not explicitly say that the predetermined cryptographic hash function is comprised by an SHA-2 group. However, Wiki provides an example of salting (Wiki p. 1: “The salt value is generated at random and can be any length; in this case the salt value is 16 bytes long. The salt value is appended to the plaintext password and then the result is hashed, which is referred to as the hashed value. Both the salt value and hashed value are stored.”). This example uses a seemingly random set of characters (Wiki p. 1, “Example usage”: “Salt value”) and SHA256 (Id.: “Hash value = SHA256(Password + Salt value)”) to motivate salting (Wiki p. 2: “Benefits”). Wiki is art analogous to the claimed invention because its discussion of salting would have been reasonably pertinent to the inventor (Specification ¶0011). It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to use a SHA-2 family hash function, such as SHA-256 as taught by Wiki, when salting the key request of Lim in view of Jung in order to comply (and maintain compliance in the future) with hash security guidelines set out by the National Institute of Standards and Technology (NIST) in FIPS 180-4 and “NIST Transitioning Away from SHA-1 for All Applications”, published December 15, 2022, which reads on p. 1: “NIST will transition away from the use of SHA-1 for applying cryptographic protection to all applications by December 31, 2030.” One of ordinary skill in the art would appreciate that SHA-1’s collision vulnerability may allow an adversary to eavesdrop and collect hashes until a duplicate hash (a collision) is found, leading to a security breach. Using a member of the SHA-2 family would solve this vulnerability. Conclusion The following prior art made of record and not relied upon is considered pertinent to applicant’s disclosure: US 20230322185 by Lerch et al. further describes a method for sharing a digital car key in accordance with the technical guidance put forth by the Car Connectivity Consortium (CCC). Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL HABASHI whose telephone number is (571)272-2245. The examiner can normally be reached M-F: 9 AM-6 PM. 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, Catherine Thiaw can be reached at (571)270-1138. 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. DH Examiner Art Unit 2407 /Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 9/17/2026
Read full office action

Prosecution Timeline

Apr 29, 2025
Application Filed
Sep 21, 2026
Non-Final Rejection mailed — §101, §102, §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month