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 .
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.
DETAILED ACTION
Remarks
This action is in response to communications filed on 06/23/2026, claims 7 and 12 are amended, claims 15-20 are cancelled and claims 21-40 are added per Applicant's request. Therefore, claims 1-14 and 21-40 are presently pending in the application and have been considered as follows.
The 35 USC 112(b) rejection has been withdrawn in light of applicants amendments.
The double patenting rejection has been maintained as the claims remain directed to the same subject matter related to US Patents and a terminal disclaimer has not been filed.
Response to Arguments
Applicant’s arguments, see pages 12-14, filed 06/23/2026, with respect to the rejection(s) of claim(s) 1--, 5-10 and 12-14 under 35 U.S.C 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of US 20180343236 A1 to Pillay-Esnault et al. (hereinafter “Pillay-Esnault) in view of US 20040122964 A1 to Teh.
Double Patenting
The nonstatutory 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 nonstatutory 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 nonstatutory 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 eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-14 and 21-40 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-23 of U.S. Patent No. 12,052,220 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application is a broader variation of the patent application as indicated in the table below.
Instant Application 18743481
U.S. Patent No. 12,052,220 B2
1.A method comprising: receiving, by a firewall device from a first computing device, a packet comprising: a source application identifier of a first application being executed on the first computing device, and a destination application identifier of a second application; and sending, by the firewall device based on a firewall rule, the packet to a second computing device, wherein the firewall rule is associated with the source application identifier and the destination application identifier.
1. A non-transitory computer-readable medium storing instructions that, when executed, configure a computing device to:
receive, from a first firewall service, a data packet comprising a source application identifier and a destination application identifier;
verify that the data packet originates from a source application indicated by the source application identifier;
after verifying that the data packet originates from the source application, determine a firewall rule for processing the data packet;
configure the first firewall service to execute the firewall rule to process, based on the source application identifier, the data packet; and
send the firewall rule to a second firewall service that is associated with a destination application identified by the destination application identifier.
Claims 1-14 and 21-40 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-19 of U.S. Patent No. 11,546,300 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application is a broader variation of the patent application as indicated in the table below.
Instant Application 18743481
U.S. Patent No. 11,546,300 B2
1.A method comprising: receiving, by a firewall device from a first computing device, a packet comprising: a source application identifier of a first application being executed on the first computing device, and a destination application identifier of a second application; and sending, by the firewall device based on a firewall rule, the packet to a second computing device, wherein the firewall rule is associated with the source application identifier and the destination application identifier.
1.A method comprising:
receiving, by a computing device and from a first firewall service, a data packet comprising a source application identifier and a destination application identifier;
verifying that the data packet originates from a source application indicated by the source application identifier;
after verifying that the data packet originates from the source application, determining a firewall rule for processing the data packet;
configuring the first firewall service to execute the firewall rule to process the data packet from the source application based on the source application identifier; and
sending, by the computing device, the firewall rule to a second firewall service that is associated with a destination application identified by the destination application identifier.
Claim Objections
Claims 34-36 are objected to because of the following informalities: Claims 34-36 each recites “The non-transitory computer-readable medium claim 33” rather than “The non-transitory computer-readable medium of claim 33.” Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 12 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claim 12, the limitation directed to “wherein the packet further comprises a first destination address associated with second computing device” lacks antecedent basis. Specifically, this element, second computing device, has been previously introduced in base claim 8.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6,10-12,16-18 and 22-24are rejected under 35 U.S.C. 103 as being unpatentable over US 20180343236 A1 to Pillay-Esnault et al. (hereinafter “Pillay-Esnault) in view of US 20040122964 A1 to Teh
Claim 1
Pillay-Esnault teaches a method comprising:
receiving, by a firewall device from a first computing device, a packet comprising: [e.g. Pillay-Esnault; Abstract, Para. 0043 - A host entity 160 may be a device (e.g. first computing device) used for IP-based or Layer-2 based data communication; Para. 0090-0091 - host entity 160 transmits a data packet through the local network 506 to the firewall device 123A and firewall device 123A receives the data packet. ]
a source application identifier of a first application being executed on the first computing device, [e.g. Pillay-Esnault; Abstract, Para. 0043 - A host entity 160 may be a device (e.g. first computing device; Para. 0048 - different applications executing on a host entity simultaneously may use different anonymized identifiers; Para. 0114 - source identifier field 783 of the data packet 785 includes an identifier of the sending host entity 160] and
Pillay-Esnalut further discloses that the packets contains separate identifiers and network address information in paragraphs 0114 in which the data packet 785 includes a source/destination IP address fields and source/destination identifier fields.
While Pillay-Esnault teaches the method of claim 1 Pillay-Esnault fails to explicitly teach that the source identifier contained in the packet is an identifier of the application that originated the packet or that the destination identifier contained in the packet is an identifier of the application to receive the packet.
However, Teh teaches:
a source application identifier of a first application being executed on the first computing device [e.g. Teh; Abstract, Para. 0014 - The unified record format comprises a Transport Header 210. The Transport Header 210, which starts a message, is further comprising the following fields: a Source Application ID field 210 f, a Destination Application ID field 210 g; 0015 - The Source Application ID field 210 f contains the ID of the application that originated the message (e.g. a source application identifier of a first application). ]
a destination application identifier of a second application; [e.g. Teh; Abstract, Para. 0014 - The unified record format comprises a Transport Header 210. The Transport Header 210, which starts a message, is further comprising the following fields: a Source Application ID field 210 f, a Destination Application ID field 210 g; 0015 - The Destination Application ID field 210 g contains the ID of the application to receive the message (e.g. a destination application identifier of a second application).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to explicitly include Teh’s source application ID and destination application ID in Pillay-Esnault’s identifier based packet and firewall policy in order to distinguish between the applications participating the in communication when determining whether the communication is permitted.
Thus, the resulting combination would provide Teh’s Source and Destination Application identifiers would be used in place of the Source and Destination identifiers in Pillay-Esnault while preserving the network address information associated with the sending and receiving device. Furthermore the combination enables:
sending, by the firewall device based on a firewall rule, the packet to a second computing device, wherein the firewall rule is associated with the source application identifier and the destination application identifier. [e.g. Pillay-Esnault; Abstract, Para. 0043 - A receiving host entity, such as host entity 150 (e.g. second computing device), is a host entity that receives data plane traffic from a sending host entity.; Para. 0068 the identity based firewall policies 290 (e.g. firewall rule) indicate one or more identifiers (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier) associated with sending host entities 160 that are permitted/prohibited from sending data packets to a receiving host entity 150; Para. 0115 - the firewall device 123A receives the data packet 785 from the sending host entity 160, the firewall device 123A determines whether to drop the data packet 785 or continue transmission of the data packet 785 to the receiving host entity 150]
Claim 2
Pillay-Esnault teaches the method of claim 1, wherein the firewall device and the first computing device belong to a network, and wherein the method further comprises: determining whether packets are permitted into or out of the network. [e.g. Pillay-Esnault; Abstract, Para. 0039 - IEN 100 (e.g. network); Para. 0043 - A host entity 150 or 160 may be a device; Para. 0051 - Firewalling refers to the process of filtering data packets such that a data packet is dropped before being received by, for example, a receiving host entity 150. Para. 0053 - one or more associated firewalls 123 positioned throughout IEN 100]
Claim 3
Pillay-Esnault as modified by Teh teaches the method of claim 1, wherein the firewall rule indicates that packets comprising the source application identifier and the destination application identifier are allowed, and wherein the sending the packet comprises: determining, based on the firewall rule, to allow the packet to be sent to the second computing device. [e.g. Pillay-Esnault; Abstract, Para. 0043 - A receiving host entity, such as host entity 150, is a host entity that receives data plane traffic from a sending host entity.; Para. 0068 the identity based firewall policies 290 indicate one or more identifiers (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier) associated with sending host entities 160 that are permitted/prohibited from sending data packets to a receiving host entity 150; Para. 0115 - the firewall device 123A receives the data packet 785 from the sending host entity 160, the firewall device 123A determines whether to drop the data packet 785 or continue transmission of the data packet 785 to the receiving host entity 150]
Claim 6
Pillay-Esnault teaches the method of claim 1, wherein the second application is being executed on the second computing device. [e.g. Pillay-Esnault; Abstract, Para. 0043 - A host entity 150 may be a device or software process; Para. 0048 - different applications executing on a host entity simultaneously may use different anonymized identifiers;]
Claim 8
Pillay-Esnault teaches a method comprising:
receiving, by a firewall device from a first computing device, a packet comprising: [e.g. Pillay-Esnault; Abstract, Para. 0043 - A host entity 160 may be a device (e.g. first computing device) used for IP-based or Layer-2 based data communication; Para. 0090-0091 - host entity 160 transmits a data packet through the local network 506 to the firewall device 123A and firewall device 123A receives the data packet. ]
a source application identifier of a first application, [e.g. Pillay-Esnault; Abstract, Para. 0048 - different applications executing on a host entity simultaneously may use different anonymized identifiers; Para. 0114 - source identifier field 783 of the data packet 785 includes an identifier of the sending host entity 160] and
a destination application identifier of a second application being executed on a second computing device; [e.g. Pillay-Esnault; Abstract, Para. 0043 - A host entity 150 may be a device (e.g. second computing device); Para. 0048 - different applications executing on a host entity simultaneously may use different anonymized identifiers; Para. 0114 - destination identifier field 780 of the data packet 785 includes an identifier of the receiving host entity 150]
Pillay-Esnalut further discloses that the packets contains separate identifiers and network address information in paragraphs 0114 in which the data packet 785 includes a source/destination IP address fields and source/destination identifier fields.
While Pillay-Esnault teaches the method of claim 1 Pillay-Esnault fails to explicitly teach that the source identifier contained in the packet is an identifier of the application that originated the packet or that the destination identifier contained in the packet is an identifier of the application to receive the packet.
However, Teh teaches:
a source application identifier of a first application being executed on the first computing device [e.g. Teh; Abstract, Para. 0014 - The unified record format comprises a Transport Header 210. The Transport Header 210, which starts a message, is further comprising the following fields: a Source Application ID field 210 f, a Destination Application ID field 210 g; 0015 - The Source Application ID field 210 f contains the ID of the application that originated the message (e.g. a source application identifier of a first application). ]
a destination application identifier of a second application; [e.g. Teh; Abstract, Para. 0014 - The unified record format comprises a Transport Header 210. The Transport Header 210, which starts a message, is further comprising the following fields: a Source Application ID field 210 f, a Destination Application ID field 210 g; 0015 - The Destination Application ID field 210 g contains the ID of the application to receive the message (e.g. a destination application identifier of a second application).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to explicitly include Teh’s source application ID and destination application ID in Pillay-Esnault’s identifier based packet and firewall policy in order to distinguish between the applications participating the in communication when determining whether the communication is permitted.
Thus, the resulting combination would provide Teh’s Source and Destination Application identifiers would be used in place of the Source and Destination identifiers in Pillay-Esnault while preserving the network address information associated with the sending and receiving device. Furthermore the combination enables:
sending, by the firewall device based on a firewall rule, the packet to a second computing device, wherein the firewall rule is associated with the source application identifier and the destination application identifier. [e.g. Pillay-Esnault; Abstract, Para. 0043 - A receiving host entity, such as host entity 150 (e.g. second computing device), is a host entity that receives data plane traffic from a sending host entity.; Para. 0068 the identity based firewall policies 290 (e.g. firewall rule) indicate one or more identifiers (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier) associated with sending host entities 160 that are permitted/prohibited from sending data packets to a receiving host entity 150; Para. 0115 - the firewall device 123A receives the data packet 785 from the sending host entity 160, the firewall device 123A determines whether to drop the data packet 785 or continue transmission of the data packet 785 to the receiving host entity 150]
Claim 9
Pillay-Esnault teaches the method of claim 8, wherein the firewall device and the second computing device belong to a network, and wherein the method further comprises: determining whether packets are permitted into or out of the network. [e.g. Pillay-Esnault; Abstract, Para. 0039 - IEN 100 (e.g. network); Para. 0043 - A host entity 150 or 160 may be a device; Para. 0051 - Firewalling refers to the process of filtering data packets such that a data packet is dropped before being received by, for example, a receiving host entity 150. Para. 0053 - one or more associated firewalls 123 positioned throughout IEN 100]
Claim 10
Pillay-Esnault teaches the method of claim 8, wherein the firewall rule indicates that packets comprising the source application identifier and the destination application identifier are allowed, and wherein the sending the packet comprises: determining, based on the firewall rule, to allow the packet to be sent to the second computing device. [e.g. Pillay-Esnault; Abstract, Para. 0043 - A receiving host entity, such as host entity 150, is a host entity that receives data plane traffic from a sending host entity.; Para. 0068 the identity based firewall policies 290 indicate one or more identifiers (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier) associated with sending host entities 160 that are permitted/prohibited from sending data packets to a receiving host entity 150; Para. 0115 - the firewall device 123A receives the data packet 785 from the sending host entity 160, the firewall device 123A determines whether to drop the data packet 785 or continue transmission of the data packet 785 to the receiving host entity 150]
Claim 13
Pillay-Esnault teaches the method of claim 8, wherein the first application is being executed on the first computing device. [e.g. Pillay-Esnault; Abstract, Para. 0043 - A host entity 160 may be a device or software process; Para. 0048 - different applications executing on a host entity simultaneously may use different anonymized identifiers;]
Claim 37
Pillay-Esnault teaches a system comprising:
a first computing device; [e.g. Para. 0043 – sending host entity 160]
a first firewall device; [e.g. Para. 0088– firewall device 123A]
and
a second firewall device, [e.g. Para. 0088– firewall device 123B]
wherein the first computing device is configured to:
send, to the first firewall device, a packet comprising:
a source application identifier of a first application being executed on the first computing device, [e.g. Pillay-Esnault; Abstract, Para. 0043 - A host entity 160 may be a device (e.g. first computing device) used for IP-based or Layer-2 based data communication; Para. 0090-0091 - host entity 160 transmits a data packet through the local network 506 to the firewall device 123A and firewall device 123A receives the data packet. ]and
a destination application identifier of a second application being executed on a second computing device, [e.g. Pillay-Esnault; Abstract, Para. 0043 - A host entity 150 may be a device (e.g. second computing device); Para. 0048 - different applications executing on a host entity simultaneously may use different anonymized identifiers; Para. 0114 - destination identifier field 780 of the data packet 785 includes an identifier of the receiving host entity 150]
Pillay-Esnalut further discloses that the packets contains separate identifiers and network address information in paragraphs 0114 in which the data packet 785 includes a source/destination IP address fields and source/destination identifier fields.
While Pillay-Esnault teaches the system of claim 37 Pillay-Esnault fails to explicitly teach that the source identifier contained in the packet is an identifier of a first application or that the destination identifier contained in the packet is an identifier of a second application to receive the packet.
However, Teh teaches:
a source application identifier of a first application being executed on the first computing device [e.g. Teh; Abstract, Para. 0014 - The unified record format comprises a Transport Header 210. The Transport Header 210, which starts a message, is further comprising the following fields: a Source Application ID field 210 f, a Destination Application ID field 210 g; 0015 - The Source Application ID field 210 f contains the ID of the application that originated the message (e.g. a source application identifier of a first application). ]
a destination application identifier of a second application being executed on a second computing device; [e.g. Teh; Abstract, Para. 0014 - The unified record format comprises a Transport Header 210. The Transport Header 210, which starts a message, is further comprising the following fields: a Source Application ID field 210 f, a Destination Application ID field 210 g; 0015 - The Destination Application ID field 210 g contains the ID of the application to receive the message (e.g. a destination application identifier of a second application).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to explicitly include Teh’s source application ID and destination application ID in Pillay-Esnault’s identifier based packet and firewall policy in order to distinguish between the applications participating the in communication when determining whether the communication is permitted.
Thus, the resulting combination would provide Teh’s Source and Destination Application identifiers would be used in place of the Source and Destination identifiers in Pillay-Esnault while preserving the network address information associated with the sending and receiving device. Furthermore the combination enables:
sending, by the firewall device based on a firewall rule, the packet to a second computing device, wherein the firewall rule is associated with the source application identifier and the destination application identifier. [e.g. Pillay-Esnault; Abstract, Para. 0043 - A receiving host entity, such as host entity 150 (e.g. second computing device), is a host entity that receives data plane traffic from a sending host entity.; Para. 0068 the identity based firewall policies 290 (e.g. firewall rule) indicate one or more identifiers (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier) associated with sending host entities 160 that are permitted/prohibited from sending data packets to a receiving host entity 150; Para. 0115 - the firewall device 123A receives the data packet 785 from the sending host entity 160, the firewall device 123A determines whether to drop the data packet 785 or continue transmission of the data packet 785 to the receiving host entity 150]
wherein the first firewall device is configured to:
send, to the second firewall device and based on a firewall rule associated with the source application identifier and the destination application identifier, the packet, [e.g. Pillay-Esnault; Abstract, Para. 0089 – firewall device 123A and firewall device 123B both locally store the identity based firewall policy 290 (e.g. firewall rule) 0091 – firewall device 123A passes the data packet to firewall device 123B; Para. 0068 the identity based firewall policies 290 (e.g. firewall rule) indicate one or more identifiers (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier) associated with sending host entities 160 that are permitted/prohibited from sending data packets to a receiving host entity 150; 0107 - The firewalls 123A and 123B may be configured to implement firewall policies 290 when a data packet is received that is destined for the receiving host entity 150.] and
wherein the second firewall device is configured to:
send, based on the firewall rule associated with the source application identifier and the destination application identifier, the packet to the second computing device. [e.g. Pillay-Esnault; Abstract, Para. 0089 – firewall device 123A and firewall device 123B both locally store the identity based firewall policy 290 (e.g. firewall rule) 0091 – firewall device 123A passes the data packet to firewall device 123B; Para. 0068 the identity based firewall policies 290 (e.g. firewall rule) indicate one or more identifiers (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier) associated with sending host entities 160 that are permitted/prohibited from sending data packets to a receiving host entity 150; Para – 0107 - The firewalls 123A and 123B may be configured to implement firewall policies 290 when a data packet is received that is destined for the receiving host entity 150.]
Claim 38
Pillay-Esnault as modified by Teh teaches the system of claim 37, wherein the firewall rule indicates that packets comprising the source application identifier and the destination application identifier are allowed, wherein the first firewall device is configured to send the packet by: determining, based on the firewall rule, to allow the packet to be sent to the second computing device, and wherein the second firewall device is configured to send the packet by: determining, based on the firewall rule, to allow the packet to be sent to the second computing device. [e.g. Pillay-Esnault; Abstract, Para. 0089 – firewall device 123A and firewall device 123B both locally store the identity based firewall policy 290 (e.g. firewall rule) 0091 – firewall device 123A passes the data packet to firewall device 123B; Para. 0068 the identity based firewall policies 290 (e.g. firewall rule) indicate one or more identifiers (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier) associated with sending host entities 160 that are permitted/prohibited from sending data packets to a receiving host entity 150; Para – 0107 - The firewalls 123A and 123B may be configured to implement firewall policies 290 when a data packet is received that is destined for the receiving host entity 150.]
Regarding claims 21, 22, 25, 26, 29, 30, 33,34 they are device and manufacture claims essentially corresponding to the above recitations, and they are rejected, at least, for the same reasons.
Claims 4, 11, 23, 27, 31, 35 and 39 are rejected under 35 U.S.C. 103 as being unpatentable over US 20180343236 A1 to Pillay-Esnault et al. (hereinafter “Pillay-Esnault) in view of US 20040122964 A1 to Teh and further in view of US 20190005229 A1 to Hilang et al. (hereinafter “Hilang”)
Claim 4
While Pillay-Esnault and Teh teaches the method of claim 1 and teaches source application identifiers the combination fails to explicitly the source application identifiers is generated based on a universally unique identifier of the first application, and assigned to the first application.
However, Hliang teaches:
the source application identifiers is generated based on a universally unique identifier of the first application, and assigned to the first application [e.g. Hliang; Abstract, Para. 0109 - mobile application 215 (e.g. first application) determines a unique identifier (TEE ID) (e.g. source application identifier), the TEE ID is calculated to depend on a Universally Unique Identifier (UUID) assigned to the application (e.g. generated based on a UUID of the first application) ]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to generate the application identifier of the combined system based on a UUID assigned to the application as taught by Hliang for the purpose of providing a unique identifier for the application that is dependent on the application as disclosed by Hliang in paragraph 0109.
Claim 11
While Pillay-Esnault and Teh teaches the method of claim 8 and teaches destination application identifiers the combination fails to explicitly the destination application identifiers is generated based on a universally unique identifier of the second application, and assigned to the first application.
However, Hliang teaches:
the destination application identifiers is generated based on a universally unique identifier of the second application, and assigned to the second application [e.g. Hliang; Abstract, Para. 0109 - mobile application 215 (e.g. second application) determines a unique identifier (TEE ID) (e.g. destination application identifier), the TEE ID is calculated to depend on a Universally Unique Identifier (UUID) assigned to the application (e.g. generated based on a UUID of the second application) ]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to generate the application identifier of the combined system based on a UUID assigned to the application as taught by Hliang for the purpose of providing a unique identifier for the application that is dependent on the application as disclosed by Hliang in paragraph 0109.
Claim 39
While Pillay-Esnault and Teh teaches the system of claim 37 and teaches source destination application identifiers the combination fails to explicitly the application identifiers are generated based on a universally unique identifier of the application, and assigned to the first application.
However, Hliang teaches:
the application identifiers are generated based on a universally unique identifier of the application, and assigned to the first application [e.g. Hliang; Abstract, Para. 0109 - mobile application 215 (e.g. first/second application) determines a unique identifier (TEE ID) (e.g. source/destination application identifier), the TEE ID is calculated to depend on a Universally Unique Identifier (UUID) assigned to the application (e.g. generated based on a UUID of the first/second application) ]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to generate the application identifier of the combined system based on a UUID assigned to the application as taught by Hliang for the purpose of providing a unique identifier for the application that is dependent on the application as disclosed by Hliang in paragraph 0109.
Regarding claims 23, 27, 31, 35 they are device and manufacture claims essentially corresponding to the above recitations, and they are rejected, at least, for the same reasons.
Claims 5, 12, 24, 28, 32, 36 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over US 20180343236 A1 to Pillay-Esnault et al. (hereinafter “Pillay-Esnault) in view of US 20040122964 A1 to Teh and further in view of US 20180287938 A1 to Han
Claim 5
Pillay-Esnault as modified by Teh teaches the method of claim 1, wherein the packet further comprises a first source address associated with the first computing device, and wherein the method further [e.g. Pillay-Esnault; Para. 0114 – In an embodiment in which IEN 700 implements IP version 4 (IPv4) or IP version 6 (IPv6), the data packets 785 may include an outer IP header. The outer IP header may include a source IP address field and a destination IP address field. For the data packets 785 that are sent at step 750, the source IP address field may include the IP address of the sending host entity 160 and the destination IP address field may include the locator of the receiving host entity 150.] comprises:
While Pillay-Esnault and Teh teaches the method of claim 1 and teaches separating the application identifiers from the network identifiers, the combination fails to teach receiving a second packet from a device that has a different network address than the first packet but the same application identifiers.
However, Han teaches:
receiving a second packet from a device that has a different network address than the first packet but the same application identifiers. [e.g. Han; Abstract, Para. 0022 - virtual machine is moved from one host machine to a new host machine (e.g. third computing device) and virtual port information including the mappings between arbitrarily assigned addresses and unique identifiers is moved with the virtual machine, meaning packets are still routed correctly based on the mapping. The mappings may be applied to the port that the migrated virtual machine uses to connect to the virtual switch on the new host machine; Para. 0027 – static unique identifier associated with a virtual machine may not change while IP address and MAC address information changes (e.g. second source address is different from first source address while identifier remains unchanged)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to configure the application identifier based firewall policy of the combined system to remain applicable when network address associated with endpoints change as taught by Han with the advantage that the firewall need not continually update its configurable as IP or MAC address information changes as disclosed by Han at paragraph 0027.
Thus, the combination would enable
receiving, by the firewall device from a third computing device, a second packet, wherein the second packet comprises: [e.g. Pillay-Esnault; Para. 0099 – host entities 160 (e.g. first, third, etc.) that are the only host entities permitted to transmit data packets (e.g. first, second, etc.) to the receiving host entity 150.]
the source application identifier, [e.g. Pillay-Esnault; Para. 0114 – source identifier field 783 of the data packet 785 includes an identifier of the sending host entity 160. (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier)]
the destination application identifier, [e.g. Pillay-Esnault; Para. 0114 – destination identifier field 780 of the data packet 785 includes an identifier of the receiving host entity 150. (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier)] and
a second source address associated with the third computing device, [e.g. Pillay-Esnault; Para. 0114 – the data packets 785 may include an outer IP header. The outer IP header may include a source IP address field and a destination IP address field.] wherein the second source address is different from the first source address; [e.g. Han; Abstract, Para. 0022 - virtual machine is moved from one host machine to a new host machine (e.g. third computing device) and virtual port information including the mappings between arbitrarily assigned addresses and unique identifiers is moved with the virtual machine, meaning packets are still routed correctly based on the mapping. The mappings may be applied to the port that the migrated virtual machine uses to connect to the virtual switch on the new host machine; Para. 0027 – static unique identifier associated with a virtual machine may not change while IP address and MAC address information changes (e.g. second source address)] and
sending, by the firewall device based on the firewall rule, the second packet to the second computing device.[ Para. 0115 - the firewall device 123A receives the data packet 785 from the sending host entity 160, the firewall device 123A determines whether to drop the data packet 785 or continue transmission of the data packet 785 to the receiving host entity 150]
Claim 12
Pillay-Esnault as modified by Teh teaches the method of claim 8, wherein the packet further comprises a first destination address associated with the second computing device, [e.g. Pillay-Esnault; Para. 0114 – In an embodiment in which IEN 700 implements IP version 4 (IPv4) or IP version 6 (IPv6), the data packets 785 may include an outer IP header. The outer IP header may include a source IP address field and a destination IP address field. For the data packets 785 that are sent at step 750, the source IP address field may include the IP address of the sending host entity 160 and the destination IP address field may include the locator of the receiving host entity 150.] and wherein the method further comprises:
While Pillay-Esnault and Teh teaches the method of claim 8 and teaches separating the application identifiers from the network identifiers, the combination fails to teach receiving a second packet from a device that has a different network address than the first packet but the same application identifiers.
However, Han teaches:
receiving a second packet from a device that has a different network address than the first packet but the same application identifiers. [e.g. Han; Abstract, Para. 0022 - virtual machine is moved from one host machine to a new host machine and virtual port information including the mappings between arbitrarily assigned addresses and unique identifiers is moved with the virtual machine, meaning packets are still routed correctly based on the mapping. The mappings may be applied to the port that the migrated virtual machine uses to connect to the virtual switch on the new host machine; Para. 0027 – static unique identifier associated with a virtual machine may not change while IP address and MAC address information changes (e.g. second destination address is different from first destination address while identifier remains unchanged)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to configure the application identifier based firewall policy of the combined system to remain applicable when network address associated with endpoints change as taught by Han with the advantage that the firewall need not continually update its configurable as IP or MAC address information changes as disclosed by Han at paragraph 0027.
Thus, the combination would enable
receiving, by the firewall device, a second packet comprising the source application identifier, the destination application identifier, and a second destination address, [e.g. Pillay-Esnault; Para. 0051 - A firewall device 123 may be responsible for performing firewalling for one or more receiving host entities 150; Para. 0099 – host entities 160 (e.g. first, third, etc.) that are the only host entities permitted to transmit data packets (e.g. first, second, etc.) to the receiving host entity 150 (e.g. first, second, third, fourth, etc.) Para. 0114 – destination identifier field 780 of the data packet 785 includes an identifier of the receiving host entity 150 and source identifier field 783 of the data packet 785 includes an identifier of the sending host entity 160. (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier); In an embodiment in which IEN 700 implements IP version 4 (IPv4) or IP version 6 (IPv6), the data packets 785 may include an outer IP header. The outer IP header may include a source IP address field and a destination IP address field.] wherein the second destination address is different from the first destination address; [e.g. Han; Abstract, Para. 0022 - virtual machine is moved from one host machine to a new host machine and virtual port information including the mappings between arbitrarily assigned addresses and unique identifiers is moved with the virtual machine, meaning packets are still routed correctly based on the mapping. The mappings may be applied to the port that the migrated virtual machine uses to connect to the virtual switch on the new host machine; Para. 0027 – static unique identifier associated with a virtual machine may not change while IP address and MAC address information changes (e.g. second destination address is different from first destination address while identifier remains unchanged)] and
sending, by the firewall device based on the firewall rule, the second packet to a third computing device associated with the second destination address. .[ e.g. Pillay-Esnault; Para. 0051 - A firewall device 123 may be responsible for performing firewalling for one or more receiving host entities 150; Para. 0115 - the firewall device 123A receives the data packet 785 from the sending host entity 160, the firewall device 123A determines whether to drop the data packet 785 or continue transmission of the data packet 785 to the receiving host entity 150]
Claim 40
Pillay-Esnault as modified by Teh teaches the system of claim 37, wherein the packet further comprises:
a first source address associated with the first computing device, [e.g. Pillay-Esnault; Para. 0114 - In an embodiment in which IEN 700 implements IP version 4 (IPv4) or IP version 6 (IPv6), the data packets 785 may include an outer IP header. The outer IP header may include a source IP address field and a destination IP address field. For the data packets 785 that are sent at step 750, the source IP address field may include the IP address of the sending host entity 160 and the destination IP address field may include the locator of the receiving host entity 150.] and
a first destination address associated with the second computing device, [e.g. Pillay-Esnault; Para. 0114 - In an embodiment in which IEN 700 implements IP version 4 (IPv4) or IP version 6 (IPv6), the data packets 785 may include an outer IP header. The outer IP header may include a source IP address field and a destination IP address field. For the data packets 785 that are sent at step 750, the source IP address field may include the IP address of the sending host entity 160 and the destination IP address field may include the locator of the receiving host entity 150.]
wherein the first firewall device is further configured to:
receive, from a third computing device, a second packet [e.g. Pillay-Esnault; Para. 0115 - the firewall device 123A receives the data packet 785 from the sending host entity 160.] comprising:
the source application identifier, [e.g. Pillay-Esnault; Para. 0114 source identifier field 783 of the data packet 785 includes an identifier of the sending host entity 160. (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier)]
the destination application identifier, a second source address associated with the third computing device, [e.g. Pillay-Esnault; Para. 0099 – host entities 160 (e.g. first, third, etc.) that are the only host entities permitted to transmit data packets (e.g. first, second, etc.) to the receiving host entity 150 (e.g. first, second, third, fourth, etc.); Para. 0114 - A destination identifier field 780 of the data packet 785 includes an identifier of the receiving host entity 150 0(e.g. source and destination application identifiers when modified with Teh Source and Application Identifier). In an embodiment in which IEN 700 implements IP version 4 (IPv4) or IP version 6 (IPv6), the data packets 785 may include an outer IP header. The outer IP header may include a source IP address field and a destination IP address field. For the data packets 785 that are sent at step 750, the source IP address field may include the IP address of the sending host entity 160 and the destination IP address field may include the locator of the receiving host entity 150.]
a second destination address associated with a fourth computing device, [e.g. Pillay-Esnault; Para. 0099 – host entities 160 (e.g. first, third, etc.) that are the only host entities permitted to transmit data packets (e.g. first, second, etc.) to the receiving host entity 150 (e.g. first, second, third, fourth, etc.); Para. 0114 - A destination identifier field 780 of the data packet 785 includes an identifier of the receiving host entity 150 0(e.g. source and destination application identifiers when modified with Teh Source and Application Identifier). In an embodiment in which IEN 700 implements IP version 4 (IPv4) or IP version 6 (IPv6), the data packets 785 may include an outer IP header. The outer IP header may include a source IP address field and a destination IP address field. For the data packets 785 that are sent at step 750, the source IP address field may include the IP address of the sending host entity 160 and the destination IP address field may include the locator of the receiving host entity 150.]
send, based on the firewall rule, the second packet to the second firewall device, [e.g. Pillay-Esnault; Abstract, Para. 0089 – firewall device 123A and firewall device 123B both locally store the identity based firewall policy 290 (e.g. firewall rule) 0091 – firewall device 123A passes the data packet to firewall device 123B; Para. 0068 the identity based firewall policies 290 (e.g. firewall rule) indicate one or more identifiers (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier) associated with sending host entities 160 that are permitted/prohibited from sending data packets to a receiving host entity 150; Para – 0107 - The firewalls 123A and 123B may be configured to implement firewall policies 290 when a data packet is received that is destined for the receiving host entity 150.]
and wherein the second firewall device is further configured to:
send, based on the firewall rule, the second packet to the fourth computing device. [e.g. Pillay-Esnault; Abstract, Para. 0089 – firewall device 123A and firewall device 123B both locally store the identity based firewall policy 290 (e.g. firewall rule) 0091 – firewall device 123A passes the data packet to firewall device 123B; Para. 0068 the identity based firewall policies 290 (e.g. firewall rule) indicate one or more identifiers (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier) associated with sending host entities 160 that are permitted/prohibited from sending data packets to a receiving host entity 150; Para – 0107 - The firewalls 123A and 123B may be configured to implement firewall policies 290 when a data packet is received that is destined for the receiving host entity 150.]
While Pillay-Esnault and Teh teaches the system of claim 37 and teaches separating the application identifiers from the network identifiers, the combination fails to teach receiving a second packet from a device that has a different network address than the first packet but the same application identifiers.
However, Han teaches:
receiving a second packet from a device that has a different network address than the first packet but the same application identifiers. [e.g. Han; Abstract, Para. 0022 - virtual machine is moved from one host machine to a new host machine and virtual port information including the mappings between arbitrarily assigned addresses and unique identifiers is moved with the virtual machine, meaning packets are still routed correctly based on the mapping. The mappings may be applied to the port that the migrated virtual machine uses to connect to the virtual switch on the new host machine; Para. 0027 – static unique identifier associated with a virtual machine may not change while IP address and MAC address information changes (e.g. second destination address is different from first destination address while identifier remains unchanged)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to configure the application identifier based firewall policy of the combined system to remain applicable when network address associated with endpoints change as taught by Han with the advantage that the firewall need not continually update its configurable as IP or MAC address information changes as disclosed by Han at paragraph 0027.
Regarding claims 24, 28, 32, 36 they are device and manufacture claims essentially corresponding to the above recitations, and they are rejected, at least, for the same reasons.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US 20180343236 A1 to Pillay-Esnault et al. (hereinafter “Pillay-Esnault) in view of US 20040122964 A1 to Teh and further in view of US 6574666 B1 to Dutta et al. (hereinafter “Dutta”)
Claim 7
While Pillay-Esnault and Teh teaches the method of claim 1 and teaches locally stored firewall policies and requests for new or updated firewall policies (Pillay-Esnault - Para. 0066, 0075, 0076) the combination fails to explicitly teach initiating a request based on a determination that a firewall rule is not stored in the firewall device.
However, Dutta teaches:
determining that the firewall rule is not stored in the firewall device; [e.g. Dutta; Col 2 Ln 51-67, Col 3 Ln 1-25 - rules loaded at the firewall are search to determine whether they include a rule pertinent to the packet and no pertinent rule is found loaded at the firewall ]
sending, based on the firewall rule not being stored in the firewall device, a rule verification request [e.g. Dutta; Col 3 Ln 1-25 - If no pertinent rule is found loaded at the firewall, then a pertinent rule is retrieved. In one embodiment, a database query is formulated and sent to a database. In one embodiment, the query includes the header parameters of the packet. the database is at a remote location from the firewall]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Dutta firewall rule query in response to a firewall rule not being locally stored as a polling condition in the combined system with the advantage of minimizing resources required for the local rule set and reducing processor load by reducing the number of rules that must be searched as disclosed by Dutta in Col 2 Ln 29 – 36.
Thus the combination enables:
determining that the firewall rule is not stored in the firewall device; [e.g. Dutta; Col 2 Ln 51-67, Col 3 Ln 1-25 - rules loaded at the firewall are search to determine whether they include a rule pertinent to the packet and no pertinent rule is found loaded at the firewall ]
sending, to a firewall controller based on the firewall rule not being stored in the firewall device, a rule verification request, wherein the rule verification request comprises at least one of: the source application identifier, the destination application identifier, an address associated with the first application, or a token associated with the first application; [e.g. Dutta; Col 3 Ln 1-25 - If no pertinent rule is found loaded at the firewall, then a pertinent rule is retrieved. In one embodiment, a database query is formulated and sent to a database. In one embodiment, the query includes the header parameters of the packet. the database is at a remote location from the firewall] [e.g. Pillay-Esnault; Abstract, Para. 0075 - the firewall device 123 may also send a request to the distributed mapping system 130 (e.g. firewall controller) for updates to firewall policies 290 that are locally stored at the firewall device 123; Para. 0077 - the mapping service 303, metadata service 306, and firewall policy service 309 may all be implemented centrally; Para. – 0114 -A destination identifier field 780 of the data packet 785 includes an identifier of the receiving host entity 150, and source identifier field 783 of the data packet 785 includes an identifier of the sending host entity 160. (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier)] and
receiving, from the firewall controller, the firewall rule. [e.g. Dutta; Col 3 Ln 25-30 - Once the pertinent rule has been retrieved (e.g., in the above example, the response has been received), the rule is loaded at the firewall, step 105. In one embodiment, the rule is then implemented for the packet, and a PASS or DROP action is performed with respect to the packet.] [e.g. Pillay-Esnault; Abstract, Para. 0104 - the firewall policy service 309 may transmit the firewall policies 290 to one or more associated firewalls 123A and 123B in IEN 700.]
Claim 14
Pillay-Esnault as modified by Teh teaches the method of claim 8, further comprising: receiving, by the firewall device from a firewall controller, the firewall rule; [e.g. Pillay-Esnault; Para. 0075 - Para. 0104 - the firewall policy service 309 may transmit the firewall policies 290 to one or more associated firewalls 123A and 123B in IEN 700.] and [e.g. Pillay-Esnault; Para. 0105 - Para. 0104 - the firewalls 123A and 123B also receive the update to the existing firewall policy 290. The firewalls 123A and 123B may be configured to locally update the corresponding stored firewall policies 290 according to the update that was received by the distributed mapping system 130.]
While Pillay-Esnault and Teh teaches the method of claim 8 and teaches in paragraph 0105 that the firewalls may be able to locally update the firewall policies received from the distributed mapping system the combination fails to explicitly teach determining that the firewall rule is not stored.
However, Dutta teaches:
determining that the firewall rule is not stored in the firewall device; [e.g. Dutta; Col 2 Ln 51-67, Col 3 Ln 1-25 - rules loaded at the firewall are search to determine whether they include a rule pertinent to the packet and no pertinent rule is found loaded at the firewall ]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Dutta firewall rule query in response to a firewall rule not being locally stored as a polling condition in the combined system with the advantage of minimizing resources required for the local rule set and reducing processor load by reducing the number of rules that must be searched as disclosed by Dutta in Col 2 Ln 29 – 36.
Thus the combination enables:
determining that the firewall rule is not stored in the firewall device; [e.g. Dutta; Col 2 Ln 51-67, Col 3 Ln 1-25 - rules loaded at the firewall are search to determine whether they include a rule pertinent to the packet and no pertinent rule is found loaded at the firewall ]
sending, to a firewall controller based on the firewall rule not being stored in the firewall device, a rule verification request, wherein the rule verification request comprises at least one of: the source application identifier, the destination application identifier, an address associated with the first application, or a token associated with the first application; [e.g. Dutta; Col 3 Ln 1-25 - If no pertinent rule is found loaded at the firewall, then a pertinent rule is retrieved. In one embodiment, a database query is formulated and sent to a database. In one embodiment, the query includes the header parameters of the packet. the database is at a remote location from the firewall] [e.g. Pillay-Esnault; Abstract, Para. 0075 - the firewall device 123 may also send a request to the distributed mapping system 130 (e.g. firewall controller) for updates to firewall policies 290 that are locally stored at the firewall device 123; Para. 0077 - the mapping service 303, metadata service 306, and firewall policy service 309 may all be implemented centrally; Para. – 0114 -A destination identifier field 780 of the data packet 785 includes an identifier of the receiving host entity 150, and source identifier field 783 of the data packet 785 includes an identifier of the sending host entity 160. (e.g. source and destination application identifiers when modified with Teh Source and Application Identifier)] and
receiving, from the firewall controller, the firewall rule. [e.g. Dutta; Col 3 Ln 25-30 - Once the pertinent rule has been retrieved (e.g., in the above example, the response has been received), the rule is loaded at the firewall, step 105. In one embodiment, the rule is then implemented for the packet, and a PASS or DROP action is performed with respect to the packet.] [e.g. Pillay-Esnault; Abstract, Para. 0104 - the firewall policy service 309 may transmit the firewall policies 290 to one or more associated firewalls 123A and 123B in IEN 700.]
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER C HARRIS whose telephone number is (571)270-7841. The examiner can normally be reached Monday through Friday between 8:00 AM to 4:00 PM CST.
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, Jeffrey L Nickerson can be reached on (469) 295-9235. 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.
/CHRISTOPHER C HARRIS/Primary Examiner, Art Unit 2432
Prosecution Insights