DETAILED ACTION
894Notice 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 .
This office correspondence is in response to the application number 19/005894 filed on December 30, 2024.
Claims 1 – 20 are pending.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Priority
This application claims priority as a continuation of U.S. patent application Ser. No. 18/336,811, filed Jun. 16, 2023, which is a Continuation of U.S. patent application Ser. No. 17/548,007, filed Dec. 10, 2021, now U.S. Pat. No. 11,683,404, which is a Continuation of U.S. patent application Ser. No. 16/967,428, filed Aug. 5, 2020, now U.S. Pat. No. 11,218,577, which is a National Stage Application of PCT/JP2018/033887, filed Sep. 12, 2018, which claims benefit of Japanese Patent Application No. 2018-018928, filed Feb. 6, 2018. The priority documents were provided in parent application 16/967428, therein the applicant is entitled to a priority date of February 6, 2018.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on (12/30/2024, 06/20/2025, and 07/03/2025) were filed on or after the mailing date of the application on December 30, 2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based e-Terminal Disclaimer may be filled out completely online using web-screens. An e-Terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about e-Terminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1 and 9 are rejected on the ground of non-provisional non-statutory anticipatory-type double patenting as being unpatentable over Claims 1 and 11 of U.S. Patent 12,219,040. Although the conflicting claims are not identical, they are not patently distinct from each other because both sets of claims are directed to the same invention. This is a non-provisional non-statutory obviousness-type double patenting rejection since the claims directed to the same invention have in fact been patented.
In regard to claim 1:
Application 19/005894
U.S. Patent 12,219,040
A network system comprising:
1. A network system comprising:
a first device, with a processor, having a first network address; and a second device, with a processor, having a second network address;
a first device with a processor; and
a second device with a processor; wherein the first device, in response to a request, starts an address authentication process with the second device;
wherein: the first device performs authentication processing onto the second device in a network layer of the first device, instead of an application layer of the first device, and
wherein in the address authentication process:
the second device authenticates, at a network layer of the second device, a first network address of the first device to determine a first authenticated network address, and
the first device comprises a first interface that allows a layer higher than the network layer of the first device to communicate data based on an authenticated network address of the second device, and
the first device authenticates, at a network layer of the first device, a second network address of the second device to determine a second authenticated network address; and
the second device performs authentication processing onto the first device in a network layer of the second device, instead of an application layer of the second device, and
wherein after the address authentication process, the first device and the second device communicate with each other,
the second device comprises a second interface that allows a layer higher than the network layer of the second device to communicate data based on an authenticated network address of the first device.
at layers above the network layer, based on the first and second authenticated network addresses.
It is clear that all of the elements of the instant application 19/005894 (herein ‘894) claim 1 are to be found in U.S. Patent 12,219,040 (herein ‘040) claim 1 (as the instant application ‘894 claim 1 fully encompasses Patent ‘040 claim 1). The difference between ‘894 claim 1 and ‘040 claim 1 lies in the fact that the ‘040 claim includes many more elements and is thus much more specific. Thus the invention of claim 1 of the 040 patent is in effect a “species” of the “generic” invention of ‘894 claim 1. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since the ‘894 claim 1 is anticipated by claim 1 of ‘040, it is not patently distinct from ‘040 claim 1.
In regard to claim 9:
Application 19/005894
U.S. Patent 12/219040
9. A communication method in a network comprising a first device having a first network address and a second device having a second network address, the communication method comprising:
11. A method for network communication in a network system with a first device and a second device, comprising
performing, at the first device, authentication processing onto the second device in a network layer of the first device, instead of an application layer of the first device;
in response to a request, starting, at the first device, an address authentication process with the second device; in the address authentication process:
communicating data, in a layer higher than the network layer of the first device, through an interface in the first device and based on an authenticated network address of the second device;
authenticating, at a network layer of the second device, a first network address of the first device to determine a first authenticated network address, and
performing, at the second device, authentication processing onto the first device in a network layer of the second device, instead of an application layer of the second device; and
authenticating, at a network layer of the first device, a second network address of the second device to determine a second authenticated network address; and
communicating data, in a layer higher than the network layer of the second device, through an interface in the second device and based on an authenticated network address of the first device
after the address authentication process, performing communication, at a layer above the network layer of the first device and a layer above the network layer of the second device, between the first device and the second device based on the first and second authenticated network addresses
It is clear that all of the elements of the instant application 19/005894 (herein ‘894) claim 9 are to be found in U.S. Patent 12,219,040 (herein ‘040) claim 11 (as the instant application ‘894 claim 9 fully encompasses Patent ‘040 claim 11). The difference between ‘894 claim 9 and ‘040 claim 11 lies in the fact that the ‘040 claim includes many more elements and is thus much more specific. Thus the invention of claim 11 of the 040 patent is in effect a “species” of the “generic” invention of ‘894 claim 9. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since the ‘894 claim 9 is anticipated by claim 11 of ‘040, it is not patently distinct from ‘040 claim 11.
Claims 1 and 9 are rejected on the ground of non-provisional non-statutory anticipatory-type double patenting as being unpatentable over Claims 1 and 10 of U.S. Patent 11,683,404. Although the conflicting claims are not identical, they are not patently distinct from each other because both sets of claims are directed to the same invention. This is a non-provisional non-statutory obviousness-type double patenting rejection since the claims directed to the same invention have in fact been patented.
In regard to claim 1:
Application 19/005894
U.S. Patent 11,683,404
A network system comprising:
1. A network system comprising:
a first device, with a processor, having a first network address; and a second device, with a processor, having a second network address;
a server device with a processor and a memory; and
at least one terminal device with a processor and a memory, wherein the server device is configured to execute:
wherein: the first device performs authentication processing onto the second device in a network layer of the first device, instead of an application layer of the first device, and
a first application process, at an application layer, for providing a service, and a first address authentication process, at a network layer, for authenticating a network address of a device accessing the server device;
the first device comprises a first interface that allows a layer higher than the network layer of the first device to communicate data based on an authenticated network address of the second device, and
wherein the terminal device is configured to execute: a second application process, at the application layer, for accessing the service provided by the server device, and a second address authentication process, at the network layer, for authenticating a network address of a device accessing the terminal device;
the second device performs authentication processing onto the first device in a network layer of the second device, instead of an application layer of the second device, and
wherein in response to a request from the terminal device to the server device, the first address authentication process and the second address authentication process start authenticating the network addresses mutually, and the first address authentication process and the second address authentication process allow data communication therebetween based on the authenticated network addresses in response to success of the authentication of the network addresses;
the second device comprises a second interface that allows a layer higher than the network layer of the second device to communicate data based on an authenticated network address of the first device.
wherein in response to success of the authentication of the network addresses, the first application process determines a service to be provided to the terminal device based on the authenticated network address of the terminal device.
It is clear that all of the elements of the instant application 19/005894 (herein ‘894) claim 1 are to be found in U.S. Patent 11,683,404 (herein ‘404) claim 1 (as the instant application ‘894 claim 1 fully encompasses Patent ‘404 claim 1). The difference between ‘894 claim 1 and ‘404 claim 1 lies in the fact that the ‘404 claim includes many more elements and is thus much more specific. Thus the invention of claim 1 of the 404 patent is in effect a “species” of the “generic” invention of ‘894 claim 1. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since the ‘894 claim 1 is anticipated by claim 1 of ‘404, it is not patently distinct from ‘404 claim 1.
In regard to claim 9:
Application 19/005894
U.S. Patent 11,683,404
9. A communication method in a network comprising a first device having a first network address and a second device having a second network address, the communication method comprising:
10. A method for network communication in a network system with a server device and at least one terminal device comprising:
performing, at the first device, authentication processing onto the second device in a network layer of the first device, instead of an application layer of the first device;
providing a first application process for providing a service at an application layer of the server device; providing a first address authentication process for authenticating a network address of a device accessing the server device at a network layer of the server device;
communicating data, in a layer higher than the network layer of the first device, through an interface in the first device and based on an authenticated network address of the second device;
providing a second application process for accessing the service provided by the server device at the application layer of the terminal device; providing a second address authentication process for authenticating a network address of a device accessing the terminal device at the network layer of the terminal device;
performing, at the second device, authentication processing onto the first device in a network layer of the second device, instead of an application layer of the second device; and
in response to a request from the terminal device to the server device, authenticating the network addresses at the first address authentication process and the second address authentication process mutually;
communicating data, in a layer higher than the network layer of the second device, through an interface in the second device and based on an authenticated network address of the first device
allowing data communication between the first address authentication process and the second address authentication process based on the authenticated network addresses in response to success of the authentication of the network addresses;
in response to success of the authentication of the network addresses, determining, at the first application process, a service to be provided to the terminal device based on the authenticated network address of the terminal device.
It is clear that all of the elements of the instant application 19/005894 (herein ‘894) claim 9 are to be found in U.S. Patent 11,683,404 (herein ‘404) claim 10 (as the instant application ‘894 claim 9 fully encompasses Patent ‘404 claim 10). The difference between ‘894 claim 9 and ‘404 claim 10 lies in the fact that the ‘404 claim includes many more elements and is thus much more specific. Thus the invention of claim 10 of the 404 patent is in effect a “species” of the “generic” invention of ‘894 claim 9. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since the ‘894 claim 9 is anticipated by claim 10 of ‘404, it is not patently distinct from ‘404 claim 10.
Claims 1 and 9 are rejected on the ground of non-provisional non-statutory anticipatory-type double patenting as being unpatentable over Claims 1 and 7 of U.S. Patent 11,218,577. Although the conflicting claims are not identical, they are not patently distinct from each other because both sets of claims are directed to the same invention. This is a non-provisional non-statutory obviousness-type double patenting rejection since the claims directed to the same invention have in fact been patented.
In regard to claim 1:
Application 19/005894
U.S. Patent 11,218,577
A network system comprising:
1. A network system comprising:
a first device, with a processor, having a first network address; and a second device, with a processor, having a second network address;
at least one server device; and
at least one terminal device configured to access any of the at least one server device;
wherein: the first device performs authentication processing onto the second device in a network layer of the first device, instead of an application layer of the first device, and
wherein: the terminal device is configured to authenticate a network address between the terminal device and any of the at least one server device and communicate data with the any of the at least one server device;
the first device comprises a first interface that allows a layer higher than the network layer of the first device to communicate data based on an authenticated network address of the second device, and
when the server device receives a request from the terminal device, the server device provides a service in accordance with the authenticated network address held by the terminal device that has issued the request; the terminal device comprises a first communication program directed to a data link layer,
the second device performs authentication processing onto the first device in a network layer of the second device, instead of an application layer of the second device, and
a second communication program directed to a transport layer and a network layer, and an address authentication program connected between the first communication program and the second communication program; and
the second device comprises a second interface that allows a layer higher than the network layer of the second device to communicate data based on an authenticated network address of the first device.
the address authentication program is adapted to authenticate, between the address authentication program and a destination device, a network address for data transmission requested by the second communication program.
It is clear that all of the elements of the instant application 19/005894 (herein ‘894) claim 1 are to be found in U.S. Patent 11,218,577 (herein ‘577) claim 1 (as the instant application ‘894 claim 1 fully encompasses Patent ‘577 claim 1). The difference between ‘894 claim 1 and ‘577 claim 1 lies in the fact that the ‘577 claim includes many more elements and is thus much more specific. Thus the invention of claim 1 of the 577 patent is in effect a “species” of the “generic” invention of ‘894 claim 1. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since the ‘894 claim 1 is anticipated by claim 1 of ‘577, it is not patently distinct from ‘577 claim 1.
In regard to claim 9:
Application 19/005894
U.S. Patent 11,218,577
9. A communication method in a network comprising a first device having a first network address and a second device having a second network address, the communication method comprising:
7. A method for network communication in a network system with at least one server device and at least one terminal device that can access any of the at least one server device, comprising:
performing, at the first device, authentication processing onto the second device in a network layer of the first device, instead of an application layer of the first device;
authenticating, at the terminal device, a network address between the terminal device and any of the at least one server device;
communicating data, in a layer higher than the network layer of the first device, through an interface in the first device and based on an authenticated network address of the second device;
communicating, at the terminal device, data with the any of the at least one server device; and
performing, at the second device, authentication processing onto the first device in a network layer of the second device, instead of an application layer of the second device; and
providing, at the server device, a service in accordance with the authenticated network address held by the terminal device that has issued a request, when the server device receives the request from the terminal device;
communicating data, in a layer higher than the network layer of the second device, through an interface in the second device and based on an authenticated network address of the first device
wherein the terminal device comprises a first communication program directed to a data link layer, a second communication program directed to a transport layer and a network layer, and an address authentication program connected between the first communication program and the second communication program; and the address authentication program is adapted to authenticate, between the address authentication program and a destination device, a network address to be used for data transmission requested by the second communication program.
It is clear that all of the elements of the instant application 19/005894 (herein ‘894) claim 9 are to be found in U.S. Patent 11,218,577 (herein ‘577) claim 7 (as the instant application ‘894 claim 9 fully encompasses Patent ‘577 claim 7). The difference between ‘894 claim 9 and ‘577 claim 7 lies in the fact that the ‘577 claim includes many more elements and is thus much more specific. Thus the invention of claim 7 of the 577 patent is in effect a “species” of the “generic” invention of ‘894 claim 9. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since the ‘894 claim 9 is anticipated by claim 7 of ‘577, it is not patently distinct from ‘577 claim 7.
Claim Analysis - 35 USC § 101 (Judicial Exception)
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 21 - 38 are directed to statutory subject matter and no 35 USC 101 rejection is applied for the judicial exception. The claims are directed to non-abstract improvements in computer related technology. The claimed subject matter is integrated into a practical application under Prong 2 of the Step 2A analysis described in MPEP 2016.04(d). A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for device authentication in a network in which devices authenticate each other using the network address itself, and once authenticated, the address is treated as a valid basis for communication and service delivery. Once the address is authenticated at the network layer, higher layers can use that verified address to communicate and to determine service behavior. The devices include terminal devices and server devices that can mutually authenticate one another’s address. A terminal device can request a service, and the server can decide what service to provide based on the authenticated address of that terminal. The ordered combination of the elements and limitations bound the claimed invention to a specific and useful improvement for authentication as connection establishment doubles as the authentication step, reducing the need for separate application layer login logic, therein enabling the provisioning of services to be more efficient because no special application is needed just to perform authentication. Therein the claims are statutory under 35 USC 101.
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 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 of this title, 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.
Claims 1 – 3, 5 – 8, 10 – 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Larson et al. (U.S. 2014/0380039 A1; herein referred to as Larson) in view of Chang (U.S. 2015/0256538 A1; herein referred to as Chang).
In regard to claim 1, Larson teaches A network system (see abstract “ . . . A system for connecting a first network device and a second network device includes one or more servers. The servers are configured to: (a) receive, from the first network device, a request to look up a network address of the second network device based on an identifier associated with the second network device; (b) determine, in response to the request, whether the second network device is available for a secure communications service; and (c) initiate a virtual private network communication link between the first network device and the second network device based on a determination that the second network device is available for the secure communications service, wherein the secure communications service uses the virtual private network communication link . . .:) comprising:
a first device (see Fig. 2 TARP Terminal 100) , with a processor, having a first network address (see Fig. 2 ¶ [0072] “ . . . Referring to FIG. 2, a secure mechanism for communicating over the internet employs a number of special routers or servers, called TARP routers 122-127 that are similar to regular IP routers 128-132 in that each has one or more IP addresses and uses normal IP protocol to send normal-looking IP packet messages, called TARP packets 140. TARP packets 140 are identical to normal IP packet messages that are routed by regular IP routers 128-132 because each TARP packet 140 contains a destination address as in a normal IP packet”); and
a second device (see Fig. 2 Tarp terminal 110 ) , with a processor, having a second network address (see Fig. 2 ¶ [0072] “ . . . the TARP packet's 140 IP header always points to a next-hop in a series of TARP router hops, or the final destination, TARP terminal 110. Because the header of the TARP packet contains only the next-hop destination, there is no overt indication from an intercepted TARP packet of the true destination of the TARP packet 140 since the destination could always be the next-hop TARP router as well as the final destination, TARP terminal 110 . . “). ;
wherein:
the first device performs authentication processing onto the second device in a network layer of the first device, (see ¶ [0073] “ . . . Each TARP packet's true destination is concealed behind an outer layer of encryption generated using a link key 146. The link key 146 is the encryption key used for encrypted communication between the end points (TARP terminals or TARP routers) of a single link in the chain of hops connecting the originating TARP terminal 100 and the destination TARP terminal 110. Each TARP router 122-127, using the link key 146 it uses to communicate with the previous hop in a chain, can use the link key to reveal the true destination of a TARP packet. To identify the link key needed to decrypt the outer layer of encryption of a TARP packet, a receiving TARP or routing terminal may identify the transmitting terminal (which may indicate the link key used) by the sender field of the clear IP header. Alternatively, this identity may be hidden behind another layer of encryption in available bits in the clear IP header. Each TARP router, upon receiving a TARP message, determines if the message is a TARP message by using authentication data in the TARP packet. This could be recorded in available bytes in the TARP packet's IP header. Alternatively, TARP packets could be authenticated by attempting to decrypt using the link key 146 and determining if the results are as expected. The former may have computational advantages because it does not involve a decryption process. . . “) , instead of an application layer of the first device (see ¶ [0019] “ . . . The above scheme may be implemented entirely by processes operating between the data link layer and the network layer of each server or terminal participating in the TARP system. Because the encryption system described above is insertable between the data link and network layers, the processes involved in supporting the encrypted communication may be completely transparent to processes at the IP (network) layer and above. The TARP processes may also be completely transparent to the data link layer processes as well. Thus, no operations at or above the Network layer, or at or below the data link layer, are affected by the insertion of the TARP stack. This provides additional security to all processes at or above the network layer, since the difficulty of unauthorized penetration of the network layer (by, for example, a hacker) is increased substantially. Even newly developed servers running at the session layer leave all processes below the session layer vulnerable to attack. Note that in this architecture, security is distributed. That is, notebook computers used by executives on the road, for example, can communicate over the Internet without any compromise in security. . . .”) and
the second device performs authentication processing onto the first device in a network layer of the second device, (see ¶ [0076] “ . . . A TARP router receives a TARP packet when an IP address used by the TARP router coincides with the IP address in the TARP packet's IP header IPc. The IP address of a TARP router, however, may not remain constant. To avoid and manage attacks, each TARP router, independently or under direction from another TARP terminal or router, may change its IP address. A separate, unchangeable identifier or address is also defined. This address, called the TARP address, is known only to TARP routers and terminals and may be correlated at any time by a TARP router or a TARP terminal using a Lookup Table (LUT). When a TARP router or terminal changes its IP address, it updates the other TARP routers and terminals which in turn update their respective LUTs. In reality, whenever a TARP router looks up the address of a destination in the encrypted header, it must convert a TARP address to a real IP address using its LUT . . .”) instead of an application layer of the second device (see ¶ [0093] “ . . . The above scheme may be implemented entirely by processes operating between the data link layer and the network layer of each server or terminal participating in the TARP system. Referring to FIG. 4, a TARP transceiver 405 can be an originating terminal 100, a destination terminal 110, or a TARP router 122-127. In each TARP Transceiver 405, a transmitting process is generated to receive normal packets from the Network (IP) layer and generate TARP packets for communication over the network. A receiving process is generated to receive normal IP packets containing TARP packets and generate from these normal IP packets which are "passed up" to the Network (IP) layer. Note that where the TARP Transceiver 405 is a router, the received TARP packets 140 are not processed into a stream of IP packets 415 because they need only be authenticated as proper TARP packets and then passed to another TARP router or a TARP destination terminal 110. The intervening process, a "TARP Layer" 420, could be combined with either the data link layer 430 or the Network layer 410. In either case, it would intervene between the data link layer 430 so that the process would receive regular IP packets containing embedded TARP packets and "hand up" a series of reassembled IP packets to the Network layer 410. As an example of combining the TARP layer 420 with the data link layer 430, a program may augment the normal processes running a communications card, for example, an Ethernet card. Alternatively, the TARP layer processes may form part of a dynamically loadable module that is loaded and executed to support communications between the network and data link layers. . . “) ,
Larson fails to explicitly teach,
However Chang teaches
the first device comprises a first interface that allows a layer higher than the network layer of the first device to communicate data based on an authenticated network address of the second device (see ¶ [0011] “ . . . the node list includes sets of legal node information. The application layer compares the first network address information of the new node with the sets of legal node information, and, if the first network address information matches with anyone of the sets of legal node information, the new node passes the authentication. . . .” see ¶ [0019] “ . . . a communication device arranged in a network system. The network system has nodes each of which is connected to the communication device respectively. The communication device includes a network layer and an application layer. When a new node is joining the nodes, the network layer sends an update signal which includes first network address information of the new node. The application layer is configured to be connected to a database and perform authentication on the first network address information of the new node based on a node list in the database. When the new node passes the authentication, the application layer stores the update signal in the database. . . “) ,
and the second device comprises a second interface that allows a layer higher than the network layer of the second device to communicate data based on an authenticated network address of the first device (see ¶ [0040] “ . . . When a new device is joining the network system through a parent node, the network layer stores the MAC address and the network address of the new device, and sends the above addresses to the application layer for authentication, and if the new device passes the authentication, a key is sent to the parent node through the network layer, and then the parent node forwards the key to the new device. . ..”see ¶¶ [0047-0048] “ . . . FIG. 2 illustrates a block diagram of a communication device (for example, the node N0 in FIG. 1) according to the invention. As shown in FIG. 2, the node N0 adopting an IEEE 802.15.4 protocol stack includes a physical layer 210, a MAC layer 220, a network layer 230 and an application layer 240. The physical layer and the MAC layer are lower layers adopting the IEEE 802.15.4 standard, and are configured to provide channels required for transmitting information and generate beacons. In one embodiment, the transmission between the node N0 and another node are conducted through the transmission channel between their physical layers. The network layer 230 is a layer above the MAC layer 220 for receiving the join request JR of the new node and transmitting the key packet TK to the network node of the network system. The application layer 240 is a layer above the network layer 230, and includes an authentication unit 242 and a database 244. The authentication unit 242 determines whether the new node is a legal node based on the database 244. The determination mechanism of the authentication unit 242 is explained in the below. . . “).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a system and method for enabling an application layer program on a first device to perform an authentication and communications on a second device using network address information provided by the network layer, as taught by Chang, into a system and method for connecting a first network device and a second network device that authenticates at the network layer using the network addresses of each device, as taught by Larson. Such incorporation enables advanced communication’s to occur between the devices after authentication at the network level.
In regard to claim 2, the combination of Larson and Chang teaches wherein:
the first device comprises a first authentication program for performing the authentication processing onto the second device (see Larson Fig. 12 A, ¶ [0149] “ . . . As shown in FIG. 12A, two computer nodes 1201 and 1202 communicate over a communication channel such as an Ethernet. Each node executes one or more application programs 1203 and 1218 that communicate by transmitting packets through communication software 1204 and 1217, respectively. Examples of application programs include video conferencing, e-mail, word processing programs, telephony, and the like. Communication software 1204 and 1217 can comprise, for example, an OSI layered architecture or "stack" that standardizes various services provided at different levels of functionality . . .”) , and
the second device comprises a second authentication program for performing the authentication processing onto the first device (see Larson ¶¶ [0338-0339] “ . . . The present invention also provides a technique for implementing the field hopping schemes described above in an application program on the client side of a firewall between two computer networks, and in the network stack on the server side of the firewall. The present invention uses a new secure connectionless protocol that provides good denial of service rejection capabilities by layering the new protocol on top of an existing IP protocol, such as the ICMP, UDP or TCP protocols. Thus, this aspect of the present invention does not require changes in the Internet infrastructure. According to the invention, communications are protected by a client-side proxy application program that accepts unencrypted, unprotected communication packets from a local browser application. The client-side proxy application program tunnels the unencrypted, unprotected communication packets through a new protocol, thereby protecting the communications from a denial of service at the server side. Of course, the unencrypted, unprotected communication packets can be encrypted prior to tunneling. . . “)
In regard to claim 3, the combination of Larson and Chang teaches wherein:
the first authentication program is coded to exchange data with a first data link driver responsible for a data link layer which is a lower layer (see Larson ¶ [0093] “ . . . The above scheme may be implemented entirely by processes operating between the data link layer and the network layer of each server or terminal participating in the TARP system. Referring to FIG. 4, a TARP transceiver 405 can be an originating terminal 100, a destination terminal 110, or a TARP router 122-127. In each TARP Transceiver 405, a transmitting process is generated to receive normal packets from the Network (IP) layer and generate TARP packets for communication over the network. A receiving process is generated to receive normal IP packets containing TARP packets and generate from these normal IP packets which are "passed up" to the Network (IP) layer. Note that where the TARP Transceiver 405 is a router, the received TARP packets 140 are not processed into a stream of IP packets 415 because they need only be authenticated as proper TARP packets and then passed to another TARP router or a TARP destination terminal 110. The intervening process, a "TARP Layer" 420, could be combined with either the data link layer 430 or the Network layer 410. In either case, it would intervene between the data link layer 430 so that the process would receive regular IP packets containing embedded TARP packets and "hand up" a series of reassembled IP packets to the Network layer 410. As an example of combining the TARP layer 420 with the data link layer 430, a program may augment the normal processes running a communications card, for example, an Ethernet card. Alternatively, the TARP layer processes may form part of a dynamically loadable module that is loaded and executed to support communications between the network and data link layers. . . .”) , and
the second authentication program is coded to exchange data with a second data link driver responsible for a data link layer which is a lower layer (see Larson ¶ [0094] “ . . . Because the encryption system described above can be inserted between the data link and network layers, the processes involved in supporting the encrypted communication may be completely transparent to processes at the IP (network) layer and above. The TARP processes may also be completely transparent to the data link layer processes as well. Thus, no operations at or above the network layer, or at or below the data link layer, are affected by the insertion of the TARP stack. This provides additional security to all processes at or above the network layer, since the difficulty of unauthorized penetration of the network layer (by, for example, a hacker) is increased substantially. Even newly developed servers running at the session layer leave all processes below the session layer vulnerable to attack. Note that in this architecture, security is distributed. That is, notebook computers used by executives on the road, for example, can communicate over the Internet without any compromise in security. . . .”).
In regard to claim 5, the combination of Larson and Chang teaches wherein a web browser is running in the application layer of the first device (see Larson ¶ [0257] “ . . . This conventional scheme is shown in FIG. 25. A user's computer 2501 includes a client application 2504 (for example, a web browser) and an IP protocol stack 2505. When the user enters the name of a destination host, a request DNS REQ is made (through IP protocol stack 2505) to a DNS 2502 to look up the IP address associated with the name. The DNS returns the IP address DNS RESP to client application 2504, which is then able to use the IP address to communicate with the host 2503 through separate transactions such as PAGE REQ and PAGE RESP. . . .”).
In regard to claim 6, the combination of Larson and Chang teaches wherein an application that determines a service to be provided to the first device in accordance with the first network address of the first device is running in the application layer of the second device (see Larson ¶ [0328] “ . . . SDNS 3313 contains a cross-reference database of secure domain names and corresponding secure network addresses. That is, for each secure domain name, SDNS 3313 stores a computer network address corresponding to the secure domain name. An entity can register a secure domain name in SDNS 3313 so that a user who desires a secure communication link to the website of the entity can automatically obtain the secure computer network address for the secure website. Moreover, an entity can register several secure domain names, with each respective secure domain name representing a different priority level of access in a hierarchy of access levels to a secure website. For example, a securities trading website can provide users secure access so that a denial of service attack on the website will be ineffectual with respect to users subscribing to the secure website service. Different levels of subscription can be arranged based on, for example, an escalating fee, so that a user can select a desired level of guarantee for connecting to the secure securities trading website. When a user queries SDNS 3313 for the secure computer network address for the securities trading website, SDNS 3313 determines the particular secure computer network address based on the user's identity and the user's subscription level. . . .”)
In regard to claim 7, the combination of Larson and Chang teaches wherein the second device comprises a management table (e.g. transmit table) in which a network address and information regarding the provided service are associated with each other (see Larson ¶¶ [0136-0138] “ . . . FIG. 8 shows how a client computer 801 and a TARP router 811 can establish a secure session. When client 801 seeks to establish an IHOP session with TARP router 811, the client 801 sends "secure synchronization" request ("SSYN") packet 821 to the TARP router 811. This SYN packet 821 contains the client's 801 authentication token, and may be sent to the router 811 in an encrypted format. The source and destination IP numbers on the packet 821 are the client's 801 current fixed IP address, and a "known" fixed IP address for the router 811. (For security purposes, it may be desirable to reject any packets from outside of the local network that are destined for the router's known fixed IP address.) Upon receipt and validation of the client's 801 SSYN packet 821, the router 811 responds by sending an encrypted "secure synchronization acknowledgment" ("SSYN ACK") 822 to the client 801. This SSYN ACK 822 will contain the transmit and receive hopblocks that the client 801 will use when communicating with the TARP router 811. The client 801 will acknowledge the TARP router's 811 response packet 822 by generating an encrypted SSYN ACK ACK packet 823 which will be sent from the client's 801 fixed IP address and to the TARP router's 811 known fixed IP address. The client 801 will simultaneously generate a SSYN ACK ACK packet; this SSYN ACK packet, referred to as the Secure Session Initiation (SSI) packet 824, will be sent with the first {sender, receiver} IP pair in the client's transmit table 921 (FIG. 9), as specified in the transmit hopblock provided by the TARP router 811 in the SSYN ACK packet 822. The TARP router 811 will respond to the SSI packet 824 with an SSI ACK packet 825, which will be sent with the first {sender, receiver} IP pair in the TARP router's transmit table 923. Once these packets have been successfully exchanged, the secure communications session is established, and all further secure communications between the client 801 and the TARP router 811 will be conducted via this secure session, as long as synchronization is maintained. If synchronization is lost, then the client 801 and TARP router 802 may re-establish the secure session by the procedure outlined in FIG. 8 and described above. While the secure session is active, both the client 901 and TARP router 911 (FIG. 9) will maintain their respective transmit tables 921, 923 and receive tables 922, 924, as provided by the TARP router during session synchronization 822. It is important that the sequence of IP pairs in the client's transmit table 921 be identical to those in the TARP router's receive table 924; similarly, the sequence of IP pairs in the client's receive table 922 must be identical to those in the router's transmit table 923. This is required for the session synchronization to be maintained. The client 901 need maintain only one transmit table 921 and one receive table 922 during the course of the secure session. Each sequential packet sent by the client 901 will employ the next {send, receive} IP address pair in the transmit table, regardless of TCP or UDP session. The TARP router 911 will expect each packet arriving from the client 901 to bear the next IP address pair shown in its receive table. Since packets can arrive out of order, however, the router 911 can maintain a "look ahead" buffer in its receive table, and will mark previously-received IP pairs as invalid for future packets; any future packet containing an IP pair that is in the look-ahead buffer but is marked as previously received will be discarded. Communications from the TARP router 911 to the client 901 are maintained in an identical manner; in particular, the router 911 will select the next IP address pair from its transmit table 923 when constructing a packet to send to the client 901, and the client 901 will maintain a look-ahead buffer of expected IP pairs on packets that it is receiving. Each TARP router will maintain separate pairs of transmit and receive tables for each client that is currently engaged in a secure session with or through that TARP router. . . “).
In regard to claim 8, the combination of Larson and Chang teaches wherein the second device performs operations (see Chang ¶ [0049] “ . . . the authentication unit 242 receives an update message US from the network layer 230, and then, the authentication unit 242 compares the update message US based on the node list stored in the database 244. . .”) comprising at least one of:
determining, in the network layer of the second device, whether to allow communication based on a list that defines a network address from which access should be permitted (see Chang ¶ [0049] “ . . . In one embodiment, the node list includes sets of legal node information. If the update message US matches with anyone of the sets of legal node information, the new node passes the authentication successfully . . .”) ; or
determining, in the network layer of the second device, whether to allow communication based on a list that defines a network address from which access should be blocked (see Chang ¶ [0049] “ . . . On the contrary, if the update message US does not match with anyone of the sets of legal node information, the new node fails to pass the authentication. . . .”).
The motivation to combine Chang with Larson is described for the rejection of claim 1 and is incorporated herein. Additionally, Chang has a process for authentication failure.
In regard to claim 9, Larson teaches A communication method in a network (see¶ [0002] “ . . . A tremendous variety of methods have been proposed and implemented to provide security and anonymity for communications over the Internet. The variety stems, in part, from the different needs of different Internet users. A basic heuristic framework to aid in discussing these different security techniques is illustrated in FIG. 1. Two terminals, an originating terminal 100 and a destination terminal 110 are in communication over the Internet. It is desired for the communications to be secure, that is, immune to eavesdropping. For example, terminal 100 may transmit secret information to terminal 110 over the Internet 107. Also, it may be desired to prevent an eavesdropper from discovering that terminal 100 is in communication with terminal 110. For example, if terminal 100 is a user and terminal 110 hosts a web site, terminal 100's user may not want anyone in the intervening networks to know what web sites he is "visiting." Anonymity would thus be an issue, for example, for companies that want to keep their market research interests private and thus would prefer to prevent outsiders from knowing which websites or other Internet resources they are "visiting." These two security issues may be called data security and anonymity, respectively. . . .”) comprising a first device (see Fig. 2 TARP Terminal 100) having a first network address (see Fig. 2 ¶ [0072] as described for the rejection of claim 1 and is incorporated herein) and a second device(see Fig. 2 Tarp terminal 110 ) having a second network address(see Fig. 2¶ [0072] as described for the rejection of claim 1 and is incorporated herein) , the communication method comprising:
performing, at the first device, authentication processing onto the second device in a network layer of the first device (see ¶ [0073] as described for the rejection of claim 1 and is incorporated herein), instead of an application layer of the first device(see ¶ [0019] as described for the rejection of claim 1 and is incorporated herein) ;
performing, at the second device, authentication processing onto the first device in a network layer of the second device (see ¶ [0076] as described for the rejection of claim 1 and is incorporated herein) , instead of an application layer of the second device (see ¶ [0093] as described for the rejection of claim 1 and is incorporated herein) ;
Larson fails to explicitly teach,
However Chang teaches
communicating data, in a layer higher than the network layer of the first device, through an interface in the first device and based on an authenticated network address of the second device(see ¶ [0011], ¶ [0019] as described for the rejection of claim 1 and is incorporated herein) ; and
communicating data, in a layer higher than the network layer of the second device, through an interface in the second device and based on an authenticated network address of the first device (see ¶ [0040], ¶¶ [0047-0048] as described for the rejection of claim 1 and is incorporated herein) .
The motivation to combine Chang with Larson is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 10, the combination of Larson and Chang teaches further comprising:
preparing a first authentication program at the first device for performing the authentication processing onto the second device(see Larson Fig. 12 A, ¶ [0149] as described for the rejection of claim 2 and is incorporated herein) ; and
preparing a second authentication program at the second device for performing the authentication processing onto the first device (see Larson ¶¶ [0338-0339] as described for the rejection of claim 2 and is incorporated herein)
In regard to claim 11, the combination of Larson and Chang teaches wherein:
the first authentication program is coded to exchange data with a first data link driver responsible for a data link layer which is a lower layer (see Larson ¶ [0093] as described for the rejection of claim 3 and is incorporated herein) , and
the second authentication program is coded to exchange data with a second data link driver responsible for a data link layer which is a lower layer (see Larson ¶ [0094] as described for the rejection of claim 3 and is incorporated herein).
In regard to claim 13, the combination of Larson and Chang teaches wherein a web browser is running in the application layer of the first device (see Larson ¶ [0257] as described for the rejection of claim 5 and is incorporated herein)
In regard to claim 14, the combination of Larson and Chang teaches wherein an application that determines a service to be provided to the first device in accordance with the first network address of the first device is running in the application layer of the second device (see Larson ¶ [0328] as described for the rejection of claim 6 and is incorporated herein)
In regard to claim 15, the combination of Larson and Chang teaches further comprising:
preparing a management table (e.g. transmit table) at the second device in which a network address and information regarding the provided service are associated with each other (see Larson ¶¶ [0136-0138] as described for the rejection of claim 7 and is incorporated herein)
In regard to claim 16, Larson teaches A device (see Fig. 2 TARP Terminal 100) having a network address (see Fig. 2 ¶ [0072] as described for the rejection of claim 1 and is incorporated herein) , the device being configured to communicate with another device (see abstract as described for the rejection of claim 1 and is incorporated herein) , the device comprising:
a processor (see ¶ [0229] “ . . . It is assumed that software executing in one or more computer nodes executes the steps shown in FIG. 22A. It is also assumed that the software can be stored on a computer-readable medium such as a magnetic or optical disk for execution by a computer . . .”) ;
a network layer in which authentication processing onto the another device is performed (see ¶ [0073], ¶ [0076] as described for the rejection of claim 1 and is incorporated herein) while the authentication processing is not performed in an application layer of the device (see ¶ [0019], ¶ [0093] as described for the rejection of claim 1 and is incorporated herein);
Larson fails to explicitly teach,
However Chang teaches and
an interface that allows a layer higher than the network layer to communicate data based on an authenticated network address of the another device (see ¶ [0011], ¶ [0019], ¶ [0040] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Chang with Larson is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 17, the combination of Larson and Chang teaches wherein the device comprises an authentication program for performing the authentication processing onto the another device (see Larson Fig. 12 A, ¶ [0149], ¶¶ [0338-0339] as described for the rejection of claim 2 and is incorporated herein).
In regard to claim 18, the combination of Larson and Chang teaches wherein the authentication program is coded to exchange data with a first data link driver responsible for a data link layer which is a lower layer (see Larson ¶ ¶ [0093-0094] as described for the rejection of claim 3 and is incorporated herein)
In regard to claim 20, the combination of Larson and Chang teaches wherein a web browser is running in the application layer of the device (see Larson ¶ [0257] as described for the rejection of claim 5. and is incorporated herein)
Claims 4, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Larson et al. (U.S. 2014/0380039 A1; herein referred to as Larson) in view of Chang (U.S. 2015/0256538 A1; herein referred to as Chang) as applied to claims XX in further view of Doviak et al. (U.S.7602782 B2; herein referred to as Doviak)
In regard to claim 4, the combination of Larson, Chang, and Doviak teaches wherein the first interface and the second interface are each a TCP/IP socket (see Doviak Col 20: Lines 44 – 54 “ . . . The wired communication network interface module 100 may be designed for networks utilizing different implementations, such as transparent asynchronous communication, Hayes compatible communication, TCP/IP stream socket, Bidirectional Messaging Facilities, File Transfer Facilities, SNA Protocol Enveloping, Vehicle Location Reporting Facilities, Credit Card Verification Facilities, and Harris DNP 3.0 Frame Relay. As noted above, a unique set of procedures may be provided by the wired communication network interface module 100 for each type of wired communication network 10. . . .”)
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a system and method directed to the transportation of data through dissimilar communications media. More particularly, the present invention relates to an apparatus and method for transporting data between a remote mobile or fixed terminal device and a host system over multiple, dissimilar communications media, as taught by Doviak, into a system and method for connecting a first network device and a second network device that authenticates at the network layer using the network addresses of each device, and enabling an application layer program on a first device to perform an authentication and communications on a second device using network address information provided by the network layer, as taught by the combination of Larson and Chang. Such incorporation enables TCP/IP sockets to be used to initiate communications between the two devices once authenticated.
In regard to claim 12, the combination of Larson, Chang, and Doviak teaches wherein the interface in the first device and the interface in the second device are each a TCP/IP socket (see Doviak Col 20: Lines 44 – 54 as described for the rejection of claim 4 and is incorporated herein.
The motivation to combine Doviak with the combination of Larson and Chang is described for the rejection of claim 4 and is incorporated herein.
In regard to claim 19, the combination of Larson, Chang, and Doviak teaches wherein the interface is a TCP/IP socket (see Doviak Col 20: Lines 44 – 54 as described for the rejection of claim 4 and is incorporated herein.
The motivation to combine Doviak with the combination of Larson and Chang is described for the rejection of claim 4 and is incorporated herein.
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. 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
/JAMES N FIORILLO/Primary Examiner, Art Unit 2444
Prosecution Insights