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
This is in response to the communication filed on 02/27/2026. Claims 1-20 are pending in the application. Claims 1, 10 and 19 are independent. Claims 1-20 are rejected.
Response to Arguments
Applicant’s arguments, see page 7 of remarks, filed on 02/27/2026, with respect to 35 USC 101 type rejections of claims 1, 3-4, 7-8, 10, 12-13, 16-17 and 19 have been fully considered, however found not persuasive.
Regarding previous 35 USC 101 type rejections, applicant primarily argues that “The Office Action provides only a conclusory statement without performing the required two-step analysis under the 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG). Applicant requests that the Examiner either withdraw this rejection or provide a detailed Step 2A and Step 2B analysis consistent with MPEP § 2106 and the 2019 PEG. … Applicant notes that the claims are directed to a specific technological improvement in wireless device authentication protocols that reduces computational requirements while enhancing security. This is analogous to allowable claims in DDR Holdings, LLC V. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014), where claims providing a technological solution to a technological problem were found patent-eligible.”
In response, examiner respectfully disagrees with the applicant’s above arguments. Contrary to applicant’s assertions, claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Claims fail to recite the features that ties the claimed invention to a specific technological improvement in wireless device authentication protocols that reduces computational requirements while enhancing security. Claimed steps of generating acknowledgment code using a selected cryptographic algorithm recited at a high level of generality amounts to apply the exception using generic computer or computer components. As requested, previous 35 USC 101 type rejections are further clarified to provide detail revised 2019 PEG analysis (See office action below for detail explanations) Examiner notes, upon further consideration, previous 35 USC 101 type rejections of claims 8 and 17 are withdrawn. Previous 35 USC 101 type rejections of claims 1, 3-4, 7, 10, 12-13, 16 and 19 have been maintained.
Applicant’s arguments, see page 7 of remarks, filed on 02/27/2026, with respect to 35 USC 112, second paragraph type rejections of claims 5, 6, 9, 14, 15 and 18 have been fully considered, and found persuasive. Previous 35 USC 112, second paragraph type rejections of claims 5, 6, 9, 14, 15 and 18 have been withdrawn.
Applicant’s arguments, see page 8 of remarks, filed on 02/27/2026, with respect to the rejections of claims 1-20 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Lee et al., US 2019/0394640 A1 reference. (See office action below for detail explanations)
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
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 1, 3-4, 7, 10, 12-13, 16 and 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to ineligible subject matter without significantly more.
Independent claim 1 recites steps of obtaining, sending and receiving password, random number, acknowledgement codes etc., and generating acknowledgement code from the received/ obtained data based on a selected cryptographic algorithm. However, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claims as a whole, considering all claim elements both individually and in combination, do not amount to significantly more than an abstract idea.
The claim recites features (such as generating an acknowledgment code based on a password and random number based on a selected cryptographic algorithm) that relates to mathematical relationship or formulas. If a claim limitation, under it’s broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea . (See Revised 2019 PEG, step 2A: prong 1 analysis)
This judicial exception is not integrated into practical application. In particular, the claim recites additional elements of “wherein acknowledgment code is generated based on at least one cryptographic algorithm selected”. However, the steps of selecting a cryptographic algorithm recited at a high level of generality amounts to apply the exception using generic computer or computer components. Hence, the claim is directed to abstract idea. (See Revised 2019 PEG, step 2A: prong 2 analysis)
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because additional elements such as sending acknowledgment code and random number to a second node or computer require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry (e.g. creating/ generating, sending/ receiving, storing, communicating, displaying files/ data etc.) (See Revised 2019 PEG, step 2B in 2019 PEG analysis)
Independent claims 10 and 19 recite steps of obtaining, sending and receiving password, random number, acknowledgement codes etc., and generating acknowledgement code from the received/ obtained data based on a selected cryptographic algorithm. However, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claims as a whole, considering all claim elements both individually and in combination, do not amount to significantly more than an abstract idea.
The claims recite features (such as generating an acknowledgment code based on a password and random number based on a selected cryptographic algorithm) that relates to mathematical relationship or formulas. If a claim limitation, under it’s broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea . (See Revised 2019 PEG, step 2A: prong 1 analysis)
This judicial exception is not integrated into practical application. In particular, the claim recites additional elements of “wherein acknowledgment code is generated based on at least one cryptographic algorithm selected”. However, the steps of selecting a cryptographic algorithm recited at a high level of generality amounts to apply the exception using generic computer or computer components. Hence, the claim is directed to abstract idea. (See Revised 2019 PEG, step 2A: prong 2 analysis)
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because additional elements such as including a memory for storing instructions to be executed by a processor; sending acknowledgment code and random number to a second node or computer require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry (e.g. creating/ generating, sending/ receiving, storing, communicating, displaying files/ data etc.) (See Revised 2019 PEG, step 2B in 2019 PEG analysis)
The dependent claims 3-4, 7, 12-13 and 16 merely recite limitations that address further steps and/or attributes of the abstract idea described in the independent claims without including significantly more to result in a practical application. See MPEP, Federal Register/ Notices, 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) analysis.
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 pre-AIA 35 U.S.C. 103(a) 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over publication “Bluetooth Core Specification v5.0”, XP 055567380, Sig Proprietary Bluetooth, pages 1-2822, December 6, 2016 (hereinafter Bluetooth Core v5.0) in view of US 2010/0042839 A1 (hereinafter Ho) further in view of US 2019/0394640 A1 (hereinafter Lee et al)
Regarding claim 1, Bluetooth Core v5.0 teaches an information processing method, comprising:
obtaining a first [PassKey/ shared key] (note figure 7.6, step 2b: “rb”: PassKey) and a first random number (note figure 7.6, step 3b: “Nbi”: random/ nonce generated in 1st of ith iteration) (also note page 1689: obtaining an identical Passkey rb and selecting a random number Nbi by the non-initiating device B);
generating a first acknowledgment code (note figure 7.6, step 4b: generating a first commitment value "Cbi" in 1st of ith iteration) of a first node (note figure 7.6: non-initiating Device B) based on the first [PassKey/ shared key] and the first random number (note page 1689; figure 7.6, step 4b: generating commitment Cbi from Passkey bits and nonce/ random Nbi)
sending the first acknowledgment code and the first random number to a second node (note page 1689; figure 7.6: steps 6 and 8: sending the first commitment Cbi and first Nbi to initiating device A)
Bluetooth Core v5.0 fails to disclose expressly obtaining a first password and a first random number; generating a first acknowledgment code based on the first password and the first random number, wherein the first acknowledgment code is generated based on at least one cryptographic algorithm selected from: an encryption algorithm, an integrity protection algorithm, a key derivation function, or a key agreement algorithm.
However, Ho teaches obtaining a first password and a first random number (note para. [0033], [0039]: each device obtaining shared password or secret, and obtaining random number of other party); generating a first acknowledgment code based on the first password and the first random number (note figure 4: steps 3b and 4b; para. [0039], [0040]: non-initiating device computing first verification key Va2_0 of series of Va2 values from password and nonce value)
Ho and Bluetooth Core v5.0 are analogous art because they are from the same field of endeavor of mutually authenticating a communication session between the wireless devices. Therefore, before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in art to modify Bluetooth Core v5.0 method to further include the features of generating a first acknowledgment code based on the first password and the first random number since such arrangement would provide users with an alternative and improved mechanism for mutually authenticating the pairing wireless devices utilizing a cryptographic/ hash value based on a shared secret/ password value (note Ho, para, [0011], [0036])
Modified Ho and Bluetooth Core v5.0 method fails to teach expressly wherein the first acknowledgment code is generated based on at least one cryptographic algorithm selected from: an encryption algorithm, an integrity protection algorithm, a key derivation function, or a key agreement algorithm.
However, Lee et al teaches wherein the first acknowledgment code is generated based on at least one cryptographic algorithm selected from: an encryption algorithm, an integrity protection algorithm, a key derivation function, or a key agreement algorithm (note para. [0075] – [0077]: generating acknowledgement token based on a selected/ specific key derivation function)
Lee et al and Bluetooth Core v5.0 are analogous art because they are from the same field of endeavor of mutually authenticating a communication session between the wireless devices. Therefore, before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in art to modify Bluetooth Core v5.0 method to further include the features of wherein the first acknowledgment code is generated based on at least one cryptographic algorithm selected from: an encryption algorithm, an integrity protection algorithm, a key derivation function, or a key agreement algorithm since such arrangement would provide users with a suitable mechanism for mutually authenticating a communication session between the wireless devices utilizing acknowledgment code generated based on a key derivation function (note Lee et al, para, [0011], [0036])
Regarding claim 10, Bluetooth Core v5.0 teaches an apparatus (note page 1683 -1684; sections 7.1 and 7.2: host), wherein the apparatus comprises:
at least one processor (note page 1683 -1684; sections 7.1 and 7.2: controller/ host of the paired/ connected Bluetooth devices); and
one or more memories (note page 1683 -1684; sections 7.1 and 7.2: connected Bluetooth devices would inherently include memory/ storage) coupled to the at least one processor and storing programming instructions for execution by the at least one processor to cause the apparatus to:
obtain a first [PassKey/ shared key] (note figure 7.6, step 2b: “rb”: PassKey) and a first random number (note figure 7.6, step 3b: “Nbi”: random/ nonce generated in 1st of ith iteration) (also note page 1689: obtaining an identical Passkey rb and selecting a random number Nbi by the non-initiating device B);
generate a first acknowledgment code (note figure 7.6, step 4b: generating a first commitment value "Cbi" in 1st of ith iteration) of a first node (note figure 7.6: non-initiating Device B) based on the first [PassKey/ shared key] and the first random number (note page 1689; figure 7.6, step 4b: generating commitment Cbi from Passkey bits and nonce/ random Nbi);
send the first acknowledgment code and the first random number to a second node (note page 1689; figure 7.6: steps 6 and 8: sending the commitment Cbi to initiating device A)
Bluetooth Core v5.0 fails to disclose expressly obtaining a first password and a first random number; generating a first acknowledgment code based on the first password and the first random number.
However, Ho teaches obtaining a first password and a first random number (note para. [0033], [0039]: each device obtaining shared password or secret, and obtaining random number of other party); generating a first acknowledgment code based on the first password and the first random number (note figure 4: steps 3b and 4b; para. [0039], [0040]: non-initiating device computing first verification key Va2_0 of series of Va2 values from password and nonce value)
Ho and Bluetooth Core v5.0 are analogous art because they are from the same field of endeavor of mutual authentication/ pairing of wireless devices. Therefore, before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in art to modify Bluetooth Core v5.0 apparatus to further include the features of generating a first acknowledgment code based on the first password and the first random number since such arrangement would provide users with an alternative and improved mechanism for mutually authenticating the pairing wireless devices utilizing a cryptographic/ hash value based on a shared secret/ password value (note Ho, para, [0011], [0036])
Regarding claim 19, Bluetooth Core v5.0 teaches a terminal device (note page 1683 -1684; sections 7.1 and 7.2: host of the connected/ non-initiating device B), wherein the terminal device comprises:
at least one processor (note page 1683 -1684; sections 7.1 and 7.2: controller/ host of the paired/ connected Bluetooth devices); and
one or more memories (note page 1683 -1684; sections 7.1 and 7.2: connected Bluetooth devices would inherently include memory/ storage) coupled to the at least one processor and storing programming instructions for execution by the at least one processor to cause the terminal device to:
obtain a first [PassKey/ shared key] (note figure 7.6, step 2b: “rb”: PassKey) and a first random number (note figure 7.6, step 3b: “Nbi”: random/ nonce generated in 1st of ith iteration) (also note page 1689: obtaining an identical Passkey rb and selecting a random number Nbi by the non-initiating device B);
generate a first acknowledgment code (note figure 7.6, step 4b: generating a first commitment value "Cbi" in 1st of ith iteration) of the terminal device (note page 1683 -1684; sections 7.1 and 7.2: host of the paired/ connected Bluetooth devices) based on the first [PassKey/ shared key] and the first random number (note page 1689; figure 7.6, step 4b: generating commitment Cbi from Passkey bits and nonce/ random Nbi); and
send the first acknowledgment code and the first random number to a second node (note page 1689; figure 7.6: steps 6 and 8: sending the commitment Cbi to initiating device A)
Bluetooth Core v5.0 fails to disclose expressly obtaining a first password and a first random number; generating a first acknowledgment code based on the first password and the first random number.
However, Ho teaches obtaining a first password and a first random number (note para. [0033], [0039]: each device obtaining shared password or secret, and obtaining random number of other party); generating a first acknowledgment code based on the first password and the first random number (note figure 4: steps 3b and 4b; para. [0039], [0040]: non-initiating device computing first verification key Va2_0 of series of Va2 values from password and nonce value)
Ho and Bluetooth Core v5.0 are analogous art because they are from the same field of endeavor of mutual authentication/ pairing of wireless devices. Therefore, before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in art to modify Bluetooth Core v5.0 terminal device to further include the features of generating a first acknowledgment code based on the first password and the first random number since such arrangement would provide users with an alternative and improved mechanism for mutually authenticating the pairing wireless devices utilizing a cryptographic/ hash value based on a shared secret/ password value (note Ho, para, [0011], [0036])
Regarding claim 2, it is rejected applying as same motivation and rationale applied above rejecting claim 1, furthermore, Bluetooth Core v5.0 teaches the method further comprising:
receiving a second acknowledgment code (note figure 7.6: step 5: “Cai”) and a second random number (note figure 7.6: step 7: receiving random Nai) from the second node (note page 1689; figure 7.6: step 5: receiving commitment Cai from initiating device A);
generating a third acknowledgment code corresponding to the second node based on the second random number (note page 1689; figure 7.6: step 7: parties taking turns revealing their commitments until the entire Passkey has been mutually disclosed); and
in response to determining that the second acknowledgment code is same as the third acknowledgment code, determining that the second acknowledgment code is correct (note page 1689; figure 7.6: step 7a: checking if Cai equals to f1(PKax, PKbx, Nai, rbi))
Regarding claim 3, it is rejected applying as same motivation and rationale applied above rejecting claim 1, furthermore, Bluetooth Core v5.0 teaches the method wherein the generating a first acknowledgment code of the first node based on the first password and the first random number comprises:
generating the first acknowledgment code based on the first password and the first random number based on a cryptographic algorithm (note page 1689; figure 7.6: step 4b: computing cryptographic function, f1(PKax, PKbx, Nai, rbi))
Regarding claim 4, it is rejected applying as same motivation and rationale applied above rejecting claim 1, furthermore, Bluetooth Core v5.0 teaches the method wherein the generating a first acknowledgment code of the first node based on the first password and the first random number comprises:
generating the first acknowledgment code based on the first random number, the first password, a public key of the first node, and a public key of the second node (note page 1689; figure 7.6: step 4b: computing cryptographic function, f1(PKax, PKbx, Nai, rbi) based on public keys PKax and PKbx of the corresponding nodes)
Regarding claim 5, Bluetooth Core v5.0 teaches the method according to claim 3, further comprising:
in response to determining that the second acknowledgment code is correct (note pages 1689-1690, Section 7.3; figure 7.7: authentication stage 2 is begins once iterated commitment values Cbi from non-initiating device B equal to series of commitment values Cai from the initiating device)
generating a first verification code based on a first key (note page 1690; figure 7.7: step 9b of authentication stage 2: computing/ generating cryptographic function f3 based on shared DHkey; examiner notes, confirmation value f3 can be interpreted as verification value); and
in response to determining that the first verification code is same as the second verification code, determining that the second verification code is correct (note page 1690; figure 7.7: step 10b: computing/ generating cryptographic function, f3(DHKey, Nb, Na, ra, IOCapB, B, A; checking whether the confirmation value “Ea” received from initiating device A equals to confirmation value “Eb” computed using function f3)
Regarding claim 6, Bluetooth Core v5.0 teaches the method according to claim 5, wherein the generating a first verification code based on a first key comprises:
generating the first verification code based on the cryptographic algorithm (note page 1689; figure 7.6: step 4b: computing cryptographic function, f1(PKax, PKbx, Nai, rbi)) and one or more of the first key, a plurality of random numbers, an address of the first node, an address of the second node, an input/output capability of the first node, an input/output capability of the second node, a first authentication scheme, or a cryptographic algorithm type (note page 1690; figure 7.7: authentication stage 2; computation of authentication value f3 from DHkey, nonce, capability of devices and address of the devices)
Regarding claim 7, it is rejected applying as same motivation and rationale applied above rejecting claim 3, furthermore, Bluetooth Core v5.0 teaches the method further comprising: sending, to the second node, first information indicating the cryptographic algorithm (note page 1687: setting Out of Band (OOB) authentication; page 1688: setting authentication data parameters; also note page 1690, figure 7.7: steps 9a and 9b: setting up authentication parameter/ previously exchanged information for authentication stage 2)
Regarding claim 8, it is rejected applying as same motivation and rationale applied above rejecting claim 7, furthermore, Bluetooth Core v5.0 teaches the method wherein the cryptographic algorithm is comprised in a cryptographic algorithm set, and the method further comprises: sending, to the second node, second information indicating the cryptographic algorithm set (note pages 1687 – 1688; figure 7.5: steps 5a and 5b: setting up authentication parameter set in OOB communication in stage 1 of authentication/ pairing protocol; section 7.2.3: capability exchange sequence indicating Passkey Entry protocol); and receiving, from the second node, third information indicating the cryptographic algorithm set (note pages 1687 – 1688; figure 7.5: steps 5a and 5b; section 7.2.3: capability exchange sequence indicating Passkey Entry protocol; also note page 1690, figure 7.7: steps 9a and 9b: setting up authentication parameter/ previously exchanged information for authentication stage 2)
Regarding claim 9, Bluetooth Core v5.0 teaches the method according to claim 6, further comprising: sending, to the second node, fourth information indicating that the first authentication scheme is password authentication (note page 1688, section 7.2.3: The Passkey Entry protocol is used when LMP IO capability exchange sequence indicates that Passkey entry shall be used)
Regarding claim 11, it is rejected applying as same motivation and rationale applied above rejecting claim 10, furthermore, Bluetooth Core v5.0 teaches the apparatus wherein the programming instructions are for execution by the at least one processor to cause the apparatus to:
receive a second acknowledgment code (note figure 7.6: step 5: “Cai”) and a second random number (note figure 7.6: step 7: receiving random Nai) from the second node (note page 1689; figure 7.6: step 5: receiving commitment Cai from initiating device A);
generate a third acknowledgment code corresponding to the second node based on the second random number (note page 1689; figure 7.6: step 7: parties taking turns revealing their commitments until the entire Passkey has been mutually disclosed); and
in response to determining that the second acknowledgment code is same as the third acknowledgment code, determine that the second acknowledgment code is correct (note page 1689; figure 7.6: step 7a: checking if Cai equals to f1(PKax, PKbx, Nai, rbi))
Regarding claim 12, it is rejected applying as same motivation and rationale applied above rejecting claim 10, furthermore, Bluetooth Core v5.0 teaches the apparatus wherein the programming instructions are for execution by the at least one processor to cause the apparatus to:
generate the first acknowledgment code based on the first password and the first random number based on a cryptographic algorithm (note page 1689; figure 7.6: step 4b: computing cryptographic function, f1(PKax, PKbx, Nai, rbi))
Regarding claim 13, it is rejected applying as same motivation and rationale applied above rejecting claim 10, furthermore, Bluetooth Core v5.0 teaches the apparatus wherein the programming instructions are for execution by the at least one processor to cause the apparatus to:
generate the first acknowledgment code based on the first random number, the first password, a public key of the first node, and a public key of the second node (note page 1689; figure 7.6: step 4b: computing cryptographic function, f1(PKax, PKbx, Nai, rbi) based on public keys PKax and PKbx of the corresponding nodes)
Regarding claim 14, Bluetooth Core v5.0 teaches the apparatus according to claim 12, wherein the programming instructions are for execution by the at least one processor to cause the apparatus to:
in response to determining that the second acknowledgment code is correct (note figure 7.6: steps 5 and 6: Cai; page 1689: revealing corresponding commitment to show the same bit value of Passkey is used):
generate a first verification code based on a first key (note page 1690; figure 7.7: step 9b: computing/ generating cryptographic function, f3(DHKey, Nb, Na, ra, IOCapB, B, A; examiner notes, confirmation value interpreted as verification value); and
in response to determining that the first verification code is same as the second verification code from the second node, determine that the second verification code is correct (note page 1690; figure 7.7: step 9b: computing/ generating cryptographic function, f3(DHKey, Nb, Na, ra, IOCapB, B, A; checking whether the confirmation Value received from initiating device A equals to value created using function f3)
Regarding claim 15, Bluetooth Core v5.0 teaches the apparatus according to claim 14, wherein the programming instructions are for execution by the at least one processor to cause the apparatus to:
generate the first verification code based on the cryptographic algorithm (note page 1689; figure 7.6: step 4b: computing cryptographic function, f1(PKax, PKbx, Nai, rbi)) and one or more of the first key, a plurality of random numbers, an address of the first node, an address of the second node, an input/output capability of the first node, an input/output capability of the second node, a first authentication scheme, or a cryptographic algorithm type (note page 1690; figure 7.7: authentication stage 2; computation of authentication value f3 from DHkey, nonce, capability of devices and address of the devices)
Regarding claim 16, it is rejected applying as same motivation and rationale applied above rejecting claim 12, furthermore, Bluetooth Core v5.0 teaches the apparatus wherein the programming instructions are for execution by the at least one processor to cause the apparatus to: send, to the second node, first information indicating the cryptographic algorithm (note page 1687: setting Out of Band (OOB) authentication; page 1688: setting authentication data parameters; also note page 1690, figure 7.7: steps 9a and 9b: setting up authentication parameter/ previously exchanged information for authentication stage 2)
Regarding claim 17, it is rejected applying as same motivation and rationale applied above rejecting claim 16, furthermore, Bluetooth Core v5.0 teaches the apparatus wherein the cryptographic algorithm belongs to a cryptographic algorithm set, and wherein the programming instructions are for execution by the at least one processor to cause the apparatus to:
send, to the second node, second information indicating the cryptographic algorithm set (note pages 1687 – 1688; figure 7.5: steps 5a and 5b: setting up authentication parameter set in OOB communication in stage 1 of authentication/ pairing protocol; section 7.2.3: capability exchange sequence indicating Passkey Entry protocol); and
receive, from the second node, third information indicating the cryptographic algorithm set (note pages 1687 – 1688; figure 7.5: steps 5a and 5b; section 7.2.3: capability exchange sequence indicating Passkey Entry protocol; also note page 1690, figure 7.7: steps 9a and 9b: setting up authentication parameter/ previously exchanged information for authentication stage 2)
Regarding claim 18, Bluetooth Core v5.0 teaches the apparatus according to claim 15, wherein the programming instructions are for execution by the at least one processor to cause the apparatus to:
send, to the second node, fourth information indicating that the first authentication scheme is password authentication (note page 1688, section 7.2.3: The Passkey Entry protocol is used when LMP IO capability exchange sequence indicates that “Passkey entry” shall be used)
Regarding claim 20, it is rejected applying as same motivation and rationale applied above rejecting claim 19, furthermore, Bluetooth Core v5.0 teaches the terminal device wherein the programming instructions are for execution by the at least one processor to cause the terminal device to:
receive a second acknowledgment code and a second random number from the second node (note figure 7.6: step 7: receiving random Nai) from the second node (note page 1689; figure 7.6: step 5: receiving commitment Cai from initiating device A);
generate a third acknowledgment code corresponding to the second node based on the second random number (note page 1689; figure 7.6: step 7: parties taking turns revealing their commitments until the entire Passkey has been mutually disclosed); and
in response to determining that the second acknowledgment code is same as the third acknowledgment code, determine that the second acknowledgment code is correct (note page 1689; figure 7.6: step 7a: checking if Cai equals to f1(PKax, PKbx, Nai, rbi))
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHANTO ABEDIN whose telephone number is 571-272-3551. The examiner can normally be reached on M-F from 8:30 AM to 6:30 PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Jung (Jay) Kim, can be reached on 571-272-3804. The RightFax number for faxing directly to the examiner is 571-273-3551. 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. 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. 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).
/SHANTO ABEDIN/ Primary Examiner, Art Unit 2494
Prosecution Insights