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 .
Response to Amendment
Applicant’s amendment filed 06 October 2026 amends claims 14, 18, and 21. Applicant’s amendment has been fully considered and entered.
Response to Arguments
Applicant argues on page pages 5-7 of the response, “Applicant submits that the Application does provide support for the limitation of ‘determining, based on a value of a predetermined prefix of the destination network address and based on a certificate indicating that the destination network address is authenticated, whether exchanging an encrypted packet with the destination device by peer to peer (P2P) is possible.’…the Application discloses that ‘the ‘authenticated IP address’ means an IP address that is generated by an irreversible cryptographic hash function and is directly or indirectly authenticated by the certificate authority…[0085] The entirety or part of the hash value 178 calculated by the hash function 180 is used as the IP address 190...[0089] It may be possible to identify that the IP address 190 determined by the device 100 has been determined according to the processing procedure…the IP address 190 may include a predetermined eigenvalue…[0090] As an example, the first two digits…of the IP address 190 in hexadecimal notation may be fixed to a predetermined unique character string…” This argument has been fully considered and is persuasive. Therefore, the previous §112 rejection has been withdrawn.
Applicant argues on page 9 of the response, “First, the combination of the cited references fails to teach determining whether exchanging an encrypted packet with destination device by peer to peer (P2P) is possible ‘based on a certificate indicating that the destination network address is authenticated,’ nor is the combination of cited references alleged to teach this limitation.” This argument has been fully considered and is persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Takenaka, U.S. Publication No. 2015/0172064.
Applicant argues on pages 9-10 of the response, “Second, the combination of the cited references fails to teach determining whether exchanging an encrypted packet with the destination device by peer to peer (P2P) is possible ‘based on a value of a predetermined prefix of the destination network address.’…Lyon does not mention use of ‘a value of a predetermined prefix’ of a network address, instead simply disclosing a list of IP addresses.” In response, the initial octet of an IP address can be considered the claimed predetermined prefix and the value contained within that initial octet would be considered the claimed value. Comparing an IP address to a list of IP addresses would involve the utilization of all octets of that IP address including the initial octet and its’ corresponding value.
Applicant argues on page 11 of the response, “For example, paragraph [0126] of Le, which was cited by the Office Action, describes verifying address ownership by proving knowledge of the private key corresponding to a public key whose hash appears in the IP address. It does not disclose determining the public key such that the resulting address includes a predetermined prefix.” This argument is not persuasive because as stated above, the initial octet of an IP address can be considered the claimed predetermined prefix.
Examiner Notes
All claims have been reviewed for compliance with 35 U.S.C. §112 and 35 U.S.C. §101 (as set forth in MPEP 2106).
Claim Rejections - 35 USC § 103
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 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 14, 16, 17, 21, 23, 24, 27 are rejected under 35 U.S.C. 103 as being unpatentable over Stuntebeck, U.S. Publication No. 2015/0372994, in view of Simionescu, U.S. Publication No. 2006/0193265, in view of Lyon, U.S. Publication No. 2013/0103848, and further in view of Takenaka, U.S. Publication No. 2015/0172064.
Referring to claims 14, 21, Stuntebeck discloses a cryptographic proxy service wherein a client device 120 prepares data for submission to a website server ([0009] & [0045]: user of the client device attempting to submit the data reads on the claimed packet transmission request), which meets the limitation of a packet transmission request. The client device 120 can encrypt data to be transmitted to devices that are not able to establish secure communications ([0009] & [0055]) such that the encrypted data is sent to a remote server ([0053]), which meets the limitation of determining, [based on the acquired network address], whether exchanging an encrypted packet with the destination device by peer to peer (P2P) is possible. The client device 120 encrypts data that is destined for a destination device such as another client device ([0045] & [0052]-[0053]: destination device reads on the claimed destination device) using the public key of the destination device from a security certificate received during the same session ([0052]-[0054]: public key from the security certificate is used to encrypt data for transmission to the destination device and client device retains the security certificate for use “in addition communications with the same data destination” shows that the client device 120 uses the public key from the security certificate to encrypt packets for transmission to the destination device), which meets the limitation generating, when exchanging an encrypted packet with the destination device [by P2P] is possible, a first encrypted packet by encrypting the packet that meets the packet transmission request, in accordance with the an encryption method based on a session established between the device and the destination device, transmitting the first encrypted packet to the destination device [by P2P].
Stuntebeck does not specify the use of a P2P network. Simionescu discloses the utilization of a P2P network ([0006]), which meets the limitation of by peer to peer (P2P), transmitting by P2P. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the cryptographic proxy service of Stuntebeck to have been implemented in a P2P environment in order to enable users to communicate with one another free from the constraints of server-based Internet communications as suggested by Simionescu ([0003]).
Stuntebeck discloses a cryptographic proxy service wherein a client device 120 can encrypt data to be transmitted to devices that are not able to establish secure communications ([0009] & [0055]). Stuntebeck does not specify how it is determined that a device is not able to establish secure communications. Lyon discloses the utilization of a list of IP addresses in order to determine communication capabilities of a device ([0026]: as applied to Stuntebeck, the list would be the destination address since the determination in Stuntebeck is specific to destination devices; utilization of an IP address would include the IP address prefix), which meets the limitation of acquiring, in response to a packet transmission request, a destination network address of a destination device to which the packet transmission request is directed, determining, based on a value of a predetermined prefix of the destination network address. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the cryptographic proxy service of Stuntebeck to have utilized a list of device IP addresses to determine which devices are able to establish secure communications in order to provide better communication performance by providing communication formats that the device is capable of utilizing as suggested by Lyon ([0026]).
Stuntebeck discloses that the remote server receives the public key of the destination device from the destination device or from a certificate authority associated with the destination device and allowing the remote server to establish an SSL channel with the destination device ([0054]).
Stuntebeck does not specify that the remote server receives the public key of the destination device in a certificate. Takenaka discloses a server certificate that includes the server public key and the domain name of the server ([0028]: certificate includes the public key of the server and therefore provides the determination that the exchange of encrypted packets with that server is possible) and that a proxy server receives this server certificate from the server ([0031]) and verifies the reliability of the server certificate ([0044]: verification of the certificate that includes the server domain name shows the “indication” of an authenticated destination network address), which meets the limitation of determining based on a certificate indicating that the destination network address is authenticated.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the remote server of Stuntebeck to have received the destination device public key in a destination device certificate in order to allow for the creation of SSL channels between the remote server and the destination device that can be interrupted while maintaining communication security and convenience as suggested by Takenaka ([0008] & [0011]-[0012] & [0066]).
Referring to claim 16, Stuntebeck discloses that the client device 120 retains the security certificate for use in addition communications with the same data destination such as when large/extended communication sessions require data to be sent in multiple packets ([0053]: shows that the client device 120 encrypts and sends multiple packets to the destination device), which meets the limitation of transmitting, when exchanging an encrypted packet with the destination device by P2P is possible, a second packet that meets the packet transmission request and differs from the first encrypted packet.
Referring to claim 17, Stuntebeck discloses that the client device 120 transmits communications to the destination device by way of a remote server ([0053]: remote server reads on the claimed device different from the destination device), which meets the limitation of wherein the second packet is transmitted by P2P to a device different from the destination device.
Referring to claims 20, 27, Stuntebeck discloses that the client device 120 retains the security certificate for use in addition communications with the same data destination such as when large/extended communication sessions require data to be sent in multiple packets ([0053]) and the security certificate includes the public key of the destination device ([0052]), which meets the limitation of wherein the acquiring the destination network address of the destination device comprises acquiring a public key of the destination device.
Referring to claim 23, Stuntebeck discloses that the client device 120 retains the security certificate for use in addition communications with the same data destination such as when large/extended communication sessions require data to be sent in multiple packets ([0053]: shows that the client device 120 encrypts and sends multiple packets to the destination device), which meets the limitation of transmitting, when exchanging an encrypted packet with the destination device by P2P is possible, a packet that meets the packet transmission request and differs from the first encrypted packet.
Referring to claim 24, Stuntebeck discloses that the client device 120 transmits communications to the destination device by way of a remote server ([0053]: remote server reads on the claimed device different from the destination device), which meets the limitation of wherein the packet that differs from the first encrypted packet is transmitted by P2P to a device different from the destination device.
Claims 19, 26 are rejected under 35 U.S.C. 103 as being unpatentable over Stuntebeck, U.S. Publication No. 2015/0372994, in view of Simionescu, U.S. Publication No. 2006/0193265, in view of Lyon, U.S. Publication No. 2013/0103848, in view of Takenaka, U.S. Publication No. 2015/0172064, and further in view of Shelest, U.S. Publication No. 2007/0061574. Referring to claims 19, 26, Stuntebeck discloses that public/private key pairs are generated and provided to the client devices ([0047] & [0052]). The public key can be transmitted along with a digital certificate issued by a certificate authority ([0058]). Stuntebeck does not disclose that the devices transmit their public key in a manner that allows for the authentication of an IP address.
Shelest discloses devices transmitting messages to other devices that include their device public key and their PDK address ([0035]). The receiving device hashes the received public key and utilizes the generated hash to verify the sender’s address by comparing the hash to the address in the message ([0037]: PKD address is formatted as an IPv6 address [0032]. Therefore, the PDK address can be considered an IP address.), which meets the limitation of authenticating the destination network address of the destination device by exchanging a public key with the destination device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the device network addresses of Stuntebeck to have been determined using public key hashes in order to provide an low overhead authentication mechanism to verify a sender’s network address as suggested by Shelest ([0004] & [0006]).
Claims 18, 25 are rejected under 35 U.S.C. 103 as being unpatentable over Stuntebeck, U.S. Publication No. 2015/0372994, in view of Simionescu, U.S. Publication No. 2006/0193265, in view of Lyon, U.S. Publication No. 2013/0103848, in view of Takenaka, U.S. Publication No. 2015/0172064, and further in view of Perdomo, U.S. Publication No. 2015/0264627. Referring to claims 18, 25, Stuntebeck does not disclose holding and updating a table associating a network address with connection to a device. Perdomo discloses each network node storing and updating routing tables ([0054]) that include network addresses ([0018]), which meets the limitation of holding and updating a table associating a network address with connection to a device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the network nodes of Stuntebeck to have included routing tables as described in Perdomo in order to facilitate use of a geographic routing protocol as discussed in Perdomo ([0025]).
Claims 28, 29 are rejected under 35 U.S.C. 103 as being unpatentable over Stuntebeck, U.S. Publication No. 2015/0372994, in view of Simionescu, U.S. Publication No. 2006/0193265, in view of Lyon, U.S. Publication No. 2013/0103848, in view of Takenaka, U.S. Publication No. 2015/0172064, and further in view of Le, U.S. Publication No. 2004/0008845. Referring to claims 28, 29, Stuntebeck does not specify that the device network addresses are determined based upon hash values calculated from public keys. Le discloses IP addresses that are determined using the hash of public keys ([0126]), which meets the limitation of wherein the destination network address is determined from a hash value calculated from a public key, wherein the public key is determined such that the destination network address includes the predetermined prefix. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the device network addresses to have been determined using public key hashes in order to enable an entity to prove that it owns the IP address as suggested by Le ([0128]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN E LANIER whose telephone number is (571)272-3805. The examiner can normally be reached M-Th: 5:30-4:00.
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, Alexander Lagor can be reached at 5712705143. 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.
/BENJAMIN E LANIER/Primary Examiner, Art Unit 2437
