DETAILED ACTION
1. Applicant’s election of Group I (claims 1-10) in the reply filed on 05/08/2026 is acknowledged. Thus claims 1-10 are pending and claim 1 is amended.
Notice of Pre-AIA or AIA Status
2. 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
3. The information disclosure statements (IDS) submitted on 07/18/2024 and 08/06/2024 have been considered. The submission is in-compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto.
Drawings
4. The drawings filed on July 18, 2024 are accepted.
Specification
5. The specification filed on July 18, 2024 is also accepted.
Claim Rejections - 35 USC § 102
6. 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
7. Claim 1-3 and 7, 9-10 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by NPL document, “RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2”, August 2008, T. Dierks (herein after referred as RFC 5246)
The following is referring to independent claim 1:
As per independent claim 1 RFC 5246 discloses a resonant crypto network [6.1, “Connection States”, Page 17, “master secret A 48-byte secret shared between the two peers in the connection. client random A 32-byte value provided by the client. server random A 32-byte value provided by the server” TLS is a cryptographic protocol between a client and server. The RFC 5246’S client/server TLS system which is crypto network corresponds the claim limitation, “a resonant crypto network”] comprising:
a first resonator [“TLS server endpoint or its random/key-generation cryptographic module” corresponds to the claim limitation “a first resonator”] configured to: transmit a first random number stream [“ServerHello.random/server_random” corresponds to the limitation, “a first random number stream”] to a second resonator [“TLS client endpoint or user device” corresponds to the claim limitation, “second resonator”, See 7.4.1.3, page 42, “The server will send this message in response to a ClientHello message” and the ServerHello structure includes Random random and page 43, “random This structure is generated by the server and MUST be independently generated from the ClientHello.random”. Note The TLS server is the first resonator. The ServerHello.random/server_random is the first random stream; and the server transmits it to the client in the ServerHello]
receive a second random number stream [ClientHello.random/client_random corresponds to the limitation “second random number stream”] from the second resonator [TLS client endpoint or user device corresponds to the limitation “the second resonator” 7.4.1.2, “When a client first connects to a server, it is required to send the ClientHello as its first message”..” The ClientHello message includes a random structure, which is used later in the protocol, Random-a client generated random structure. Note: The TLS server receives the client’s ClientHello.random/client_random, which corresponds to the claim limitation, “second random number stream”] and generate a first daughter stream [server-side write key material, such as server_write_key or server MAC key corresponds to the claim limitation, “a first daughter stream”] based in part on a combination of the first random number stream and the second random number stream [6.3, page, 26, “To generate the key material, compute key_block = PRF (SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random)” Note: The server’s write key material is a “daughter stream” generated from a combination of server_random and client_random, plus the master secret]; and
the second resonator configured to: transmit the second random number stream to the first resonator [7.4.1.2, page 39, “When a client first connects to a server, it is required to send the ClientHello as its first message” and The ClientHello message includes a client-generated random structure” The client is the second resonator. It transmits ClientHello.random to the server]
receive the first random number stream from the first resonator [7.4.1.2”-7.4.1.3, page 42, “After sending the ClientHello message, the client waits for a ServerHello message, the server sends the ServerHello with “Random random”], and
generate a second daughter stream [client-side write key material, such as client_write_key or client write MAC key corresponds to the limitation, “second daughter stream”] based in part on a combination of the first random number stream and the second random number stream, the second daughter stream being distinct from the first daughter stream [6.3, page 26, “The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. Each of these is generated from the byte sequence in that order” it then lists separate partitions including “client_write_key” and a “server_write_key”. Client_write_key and server_write key are distinct daughter streams because they are different partitions of the TLS key block. They are generated from the same combined client/server random values but occupy different key-material fields].
The following is referring to 2-3, 7 and 9-10:
As per dependent claim 2, RFC 5246, discloses a method/system/a resonant network as applied to claim 1 above. Furthermore, RFC 5346 discloses the method/system/a resonant network wherein the first random number stream is a public random number stream [7.4.1, “When a new session begins, the record layer’s connection state encryption, hash, and compression algorithms are initialized to null” it also states that the ServerHello contains “Random random. Note, The server random is transmitted in the TLS hello phase before connection encryption is established. Thus, the ServerHello.random is public].
As per dependent claim 3, RFC 5246, discloses a method/system/a resonant network as applied to claim 1 above. Furthermore, RFC 5346 discloses the method/system/a resonant network wherein the second number stream is associated with a user device [6.1. page 17, “client random A 32-byte value provided by the client and 7.4.1.2, also states; random-A client-generated random structure. Note: The client is the user device and the ClientHello.random is generated/provided by that client device].
As per dependent claim 7, RFC 5246, discloses a method/system/a resonant network as applied to claim 1 above. Furthermore, RFC 5346 discloses the method/system/a resonant network, wherein the first resonator is further configured to apply a first combination formula to the first random number stream and the second random number stream to generate the first daughter stream, and the second resonator is further configured to apply a second combination formula to the first random number stream and the second random number stream to generate the second daughter stream [6.3, page 26, the key generation formula:
key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random)” it also states the key block is partitioned into separate client/server write keys. Note: Both TLS endpoints compute TLS key block from the combination of server random and client random. The first resonator applies the formula to obtain the server write key material; the second resonator applies the formula to obtain the client write key material. The extraction/partitioning of different key portions corresponds to the claimed first and second combination formulas.]
As per dependent claim 9, RFC 5246, discloses a method/system/a resonant network as applied to claim 1 above. Furthermore, RFC 5346 discloses the method/system/a resonant network, further comprising: a third resonator [The TLS client key-exchange/premaster-secret generator is a third cryptographic random source/module ]configured to: transmit a third random number stream [the preMasterScerect random value including the 46 securely generated random bytes corresponds to a third random number stream”] to at least one of the first resonator or the second resonator, wherein the first resonator is configured to modify the first daughter stream based on the third random number and the second resonator is configured to modify the second daughter stream based on the third random number stream [7.4.7.1, teaches a third random input in the TLS key exchange. It defines the RSA preMasterSecret structure as including “opaque random[45] and states: “random 46 securelty-generated random bytes. It further states “pre_master_secret-this radom value is generated by the client and it used to generate the master secret. , “ a 46-byte pre_master_secret is generated by the client, encrypted user the server’s public key, and sent to the server. Note: the premaster-secret generator corresponds to the third-cryptographic random source/module and the premaster secret is the third random stream separate from client_random and server_random. It is transmitted to the server].
As per dependent claim 10, RFC 5246, discloses a method/system/a resonant network as applied to claim 1 above. Furthermore, RFC 5346 discloses the method/system/a resonant network, wherein one of the first resonator or the second resonator uses a third combination formula, distinct from the first combination formula and the second combination formula, to modify the first daughter stream or the second daughter stream [8.1, page 64, uses a distinct PRF formula for the master secret. “master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];” and uses a different PRF formula for key expanstion: ‘key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random)” Note; the master-secret formula uses the label “master secret” and the premaster secret; the key-expansion formula uses the label “key expansion” and the master secret. These are distinct combination formulas. The master-secret formula modifies the eventual daughter streams because the derived master_secret feeds the key_block]
8. Claims 4-6 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over NPL document, “RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2”, August 2008, T. Dierks (herein after referred as RFC 5246) in view NPL document “MICHAEL RASH, "single packet authorization with fwknop" Feb, 2016 (herein after referred as Rash)
As per dependent claim 4, RFC 5246, discloses a method/system/a resonant network as applied to claim 3 above.
RFC 5426 does not explicitly disclose the following underlined limitation:
wherein the second resonator is further configured to insert a user sequence into the second random number stream, the user sequence configured to initiate a secure communications process upon detection thereof.
However Rash teaches: wherein the second resonator is further configured to insert a user sequence into the second random number stream, [ Page 66, “Fwknop Single Packet Authorization Message Format”….Rash teaches that an fwknop client transmits a structured authorization sequence. It states “An fwknop client transmits the following within each SPA message: 16 bytes of random data; Local username; Local time stamp; fwknop version; mode (access or command); desired access (or command string) MD5 sum”. It further states that “all the above values are concatenated with “:” characters.. and the entire message is then encrypted with the RIJNDAEL symmetric block cipher”,Thus Rash teaches a client-originated user sequence containing random data, user name, time stamp, access request, and hash. Note RFC 5246 itself permits client-side extension data: “Clients may request extended functionality form server by sending data in the extension field.] the user sequence configured to initiate a secure communications process upon detection thereof [Page 66, “Fwknop in Action” Fwknop is used “to protect and gain access to the OpenSSH daemon” and page 67, that the server is configured to “allow access to TCP port 22 by the “mbr” username once a valid SPA message is monitored” Rash then shows that after the SPA message is sent, “we are now able to establish a TCP connection with port 22 followed by “192.168.10.1 22 (ssh) open” it also states “Fwknop running on the server has reconfigured Netfilter to allow the client IP address to talk to sshd.” Thus, the valid SPA/USER sequence is monitored/detected by the server, and detection initiates access to a secure OpenSSH communication process.]
RFC 5426 and Rash are an analogous/in the same field of endeavor as they both pertain to security and a method of authorization. RFC 5246 expressly permits clients to request extended functionality by sending data in the extensions fields and Rash expressly teaches the content and purpose of the user sequence.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of RFC 5246 by a mechanism such as “insert a user sequence into the second random number stream, the user sequence configured to initiate a secure communications process upon detection thereof” as per teaching of Rash because this would enhance the security of the system by allowing the server detect and initiate or permit the secure communication process. [See Rash at least abstract, Fwknop provide an additional layer of security for OpenSSH and provide a method authorization]
As per dependent claim 5 RFC 5246, discloses a method/system/a resonant network as applied to claim 4 above.
RFC 5426 does not explicitly disclose the following underlined limitation: wherein the user sequence is a random sequence of numbers.
However, Rash discloses: “wherein the user sequence is a random sequence of numbers” [Fwknop Single Packet Authorization Message Format: page 66, “The 16 bytes of random data ensures that each SPA message has an extremely high probability of being unique” Thus, the user sequence includes a random numeric component, satisfying the limitation, “random sequence of numbers”]
RFC 5426 and Rash are an analogous/in the same field of endeavor as they both pertain to security and a method of authorization. RFC 5246 expressly permits clients to request extended functionality by sending data in the extensions fields and Rash expressly teaches the content and purpose of the user sequence.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of RFC 5246 by a mechanism such as “wherein the user sequence is a random sequence of numbers” as per teaching of Rash because this would enhance the security of the system by providing high probability unique random data that is used for authorization to protect and gain access and in order to thwart replay attack [See Rash at least page 66, The 16 bytes of random data ensures that each SPA message has an extremely high probability of being unique and hence allows the fwknop server to maintain a cache of previously seen messages in order to thwart replay attacks]
As per dependent claim 6 RFC 5246, discloses a method/system/a resonant network as applied to claim 5 above.
RFC 5426 does not explicitly disclose the following underlined limitation:
wherein the user sequence comprises a user’s hash and a time signature
However, Rash discloses: “wherein the user sequence comprises a user’s hash and a time signature”[Page 66, SPA message includes “local username, local timestamp and MD5 sum and Rash further stated that “The MD5 sum is calculated over the entire message and is then used by the server to verify message integrity after a successful message decrypt” Thus, Because the MD5 sum is calculated over the entire message, and the entire message includes the local username and local timestamp, this teaches a hash associated with the user plus a time signature]
RFC 5426 and Rash are an analogous/in the same field of endeavor as they both pertain to security and a method of authorization. RFC 5246 expressly permits clients to request extended functionality by sending data in the extensions fields and Rash expressly teaches the content and purpose of the user sequence.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of RFC 5246 by a mechanism such as “wherein the user sequence comprises a user’s hash and a time signature” as per teaching of Rash because this would enhance the security of the system by verifying message integrity [See Rash at least page 66, The MD5 sum is calculated over the entire message and is then used by the server to verify message integrity after a successful message decrypt]
As per dependent claim 8, the combination of RFC 5246 and Rash, discloses a method/system/a resonant network as applied to claim 4 above. Furthermore, RFC 5346 discloses the method/system/a resonant network, wherein the second combination formula is distinct from the first combination formula [6.3, “The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key” This states that the expanded key material is split into different items “in that order” including “client_write_key” and “server_write_key”. Note: the formula for the client daughter stream is different extraction/partition from the formula for the server daughter stream. The two daughter streams are not the same bytes; they are distinct portions of the key block]
Conclusion
9. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
A. US Patent No. 8051181 B2 Larson et al discloses “A technique is disclosed for establishing a secure communication link between a first computer and a second computer over a computer network…, a secure communication link is established between the first computer and a second computer over a computer network based on the enabled secure communication mode of communication. The secure communication link is a virtual private network communication link over the computer network in which one or more data values that vary according to a pseudo-random sequence are inserted into each data packet.
B. US Publication No. 20040161106A1 to Matsuda discloses a key generator, which assures the security of a key by preventing a circuit designer and other persons from readily knowing the value of the key. Random number generator circuits (51, 52, 53 and so on) generate random numbers respectively in accordance with different clocks (CLK1, CLK2, CLK3, and so on). An arithmetic circuit (59) operates on the random numbers generated from the random number generator circuits (51, 52, 53 and so on) to generate an N-bit random number RA as the output from a random number generator (50). This N-bit random number is RA acquired via a key selector (43), and latched into a key register (45) in accordance with an acquisition enable signal EN from a timing monitoring counter (47), which is driven by a clock CLKA other than clocks CLK1, CLK2, CLK3, and so on, to obtain a hardware key, which is a unique secret key.
C. US Patent No. 6052786 A to Tsuchida discloses an encryption unit uses part of a pseudo random number generated by a random number generator to encrypt data to be transferred which are stored in the payload of a cell. A counter information assigning section inserts counter information indicating the order in which the cell was sent into that payload. A random number generator on a receiving side generates the same pseudo random number as the random number generator on a sending side. A counter information analysis section identifies the position of the part of the pseudo random number to be used in the encryption unit based on the counter information extracted from the received cell, and has the random number generator on the receiving side output that part of the pseudo random number. The encrypted transferred data are extracted from the received cell, and these transferred data are decrypted using the part of the pseudo random number output from the random number generator on the receiving side.
D. US Publication No. US20140133654 A1 to Reznik discloses a secret stream of bits begins by receiving a public random stream contained in a wireless communication signal at a transmit/receive unit. The public random stream is sampled and specific bits are extracted according to a shared common secret. These extracted bits are used to create a longer secret stream. The shared common secret may be generated using JRNSO techniques, or provided to the transmit/receive units prior to the communication session. Alternatively, one of the transmit/receive unit is assumed to be more powerful than any potential eavesdropper. In this situation, the powerful transmit/receive unit may broadcast and store a public random stream. The weaker transmit/receive unit selects select random bits of the broadcast for creating a key. The weaker transmit/receive unit sends the powerful transmit/receive unit the selected bit numbers, and powerful transmit/receive unit uses the random numbers to produce the key created by the weaker transmit/receive unit.
E. See the other cited prior arts.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMSON B LEMMA whose telephone number is 571-272-3806. The examiner can normally be reached on M-F 8am-10pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shaw Yin Chen can be reached on to 571-272-8878. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAMSON B LEMMA/Primary Examiner, Art Unit 2498
Prosecution Insights