Remarks
Claims 1-12 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claims 1-12 have been considered but are moot in view of the new ground(s) of rejection presented below.
With respect to Applicant’s allegations directed to message queues, Applicant must file evidentiary documents officially if Applicant wants such documents to be considered evidentiary. Also, Wikipedia can be modified by anyone at any time, so using Wikipedia for definitions is not recommended. Moreover, Applicant fails to describe what language precisely provides a definition of a message queue in the specification. The specification does not require that the message queue be used in any specific form of asynchronous communications. The specification does not even use the word “asynchronous” so it’s entirely unclear just what language Applicant is attempting to rely on. Any queue that includes messages is within the BRI of message queue. Furthermore, Applicant has not even attempted to prove that the message queues cited in the rejection do not meet any actual definition thereof. As noted in the rejection, a message queue associated with the network function may be a data store storing message contents for a worker to grab, any network communications involving at least one message queue (e.g., in the NIC or network stack), as is known in the art, or the like, as examples.
Claim Objections
Claims 1, 2, 5, 7, 8, and 11 are objected to because of the following informalities: Claim 1 refers to “the IP address” in the final limitation. However, multiple IP addresses are present in claim 1 already and it is unclear just which IP address is being referenced here. Claims 2, 5, 7, 8, and 11 have the same issue and are objected to for the same reasons. 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 2 and 8 are 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 states “wherein updating the prefix list to allow communication includes adding an identifier that includes the IP address to the prefix list.” However, claim 1 does not include any step of “updating the prefix list to allow communication” and, rather, has been amended to state “updating, by the worker and in response to the message, the prefix message to include the IP address”. Thus, claim 2 is not referencing any step properly. Moreover, since claim 1 already includes updating the list with the IP address, it appears as though claim 2 should have been canceled. Claim 8 has the same issue and is rejected for the same reasons.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over Miller (U.S. Patent Application Publication 2016/0373405) in view of Mishra (U.S. Patent Application Publication 2021/0045193) and Sharma (U.S. Patent 10,469,389).
Regarding Claim 1,
Miller discloses an automated process for implementing IP based filtering between a first network function and a second network function, comprising:
Initializing a prefix list associated with a first network function (Exemplary Citations: for example, Abstract, Paragraphs 18-21, 32, 35, 37, 45, 50-52, as well as many citations below, as well as associated figures; anywhere Miller discusses security tables, address lists, address ranges/prefixes/CIDR, including IP addresses (which can be prefixes), etc., associated with a network function, such as a VM, service, service provider network, etc., as examples. It is noted that all of the initializing steps in any claims are met simply by the element existing, showing it has been initialized);
Initializing a message queue associated with the first network function, wherein the message queue receives updates for the prefix list from notification functions in response to being subscribed to the notification functions (Exemplary Citations: for example, Abstract, Paragraphs 35, 37, 49, 53, 55, 58, 80, 83, 91, 92, 96, 97, 98, 101, 103, 108, 111, 112, 121, 125, 126, 127, 133, 135, 136, 139, 140-142, 149, 151, 152, 157, and associated figures; initializing of any message queue associated with the network function, such as a data store storing message contents for a worker to grab, any network communications involving at least one message queue (e.g., in the NIC or network stack), as is known in the art, or the like, as examples. It is also noted that any memory in which a message is stored for any period of time is, itself, a message queue as well, since it includes a list of at least one message; any of the above-described queues being setup to receive, for example, explicit notifications, messages, updated lists, DNS info, or the like, as examples. Exemplary Citations: for example, Abstract, Paragraphs 18-21, 32, 35, 37, 45, 50-53, 55, 58, 59, 80, 92-96, 106-108, 111, 112, 117, 119-121, 125-133, and associated figures; updating the above-described lists, for example);
Running a worker to maintain the prefix list, wherein the worker consumes messages from the message queue and edits the prefix list (Exemplary Citations: for example, Abstract, Paragraphs 35, 37, 49, 53, 55, 58, 80, 83, 91, 92, 96, 97, 98, 101, 103, 108, 111, 112, 121, 125, 126, 127, 133, 135, 136, 139, 140-142, 149, 151, 152, 157, and associated figures; this could be explicit reference to the worker/combined workers within the reference, the network manager, address auditor, and/or address merger (which may be combined, as in paragraph 101), or the like, that take messages as inputs, and result in editing of a security table or list, for example);
Initializing a notification service associated with a second network function (Exemplary Citations: for example, Abstract, Paragraphs 35, 37, 49, 53, 55, 58, 80, 83, 91, 92, 96, 97, 98, 101, 103, 108, 111, 112, 121, 125, 126, 127, 133, 135, 136, 139, 140-142, 149, 151, 152, 157, and associated figures; any element that notifies any of the above-described queues, for example, such as in explicit notifications, messages, updated lists, DNS info, or the like, as examples);
Subscribing the message queue of the first network function to the notification service of the second network function (Exemplary Citations: for example, Abstract, Paragraphs 35, 37, 49, 53, 55, 58, 80, 83, 91, 92, 96, 97, 98, 101, 103, 108, 111, 112, 121, 125, 126, 127, 133, 135, 136, 139, 140-142, 149, 151, 152, 157, and associated figures; any of the above-described queues being setup to receive, for example, explicit notifications, messages, updated lists, DNS info, or the like, as examples);
Instantiating an instance of the second network function, wherein an IP address is assigned to the second network function in response to being instantiated (Exemplary Citations: for example, Paragraphs 15, 18, 19, 25, 28, 30, 37, 45, 49, 55, 56, 80, 83, 89, 100, 117, 125, 126, and associated figures; instantiating new VM, service, or the like, resulting in a new IP address being added, for example);
Broadcasting, by the notification service, a messages including the IP address to message queues subscribed to the notification service (Exemplary Citations: for example, Abstract, Paragraphs 35, 37, 49, 53, 55, 58, 80, 83, 91, 92, 96, 97, 98, 101, 103, 108, 111, 112, 121, 125, 126, 127, , 133, 135, 136, 139, 140-142, 149, 151, 152, 157, and associated figures; message with IP address to the queue(s) described above, for example);
Consuming, by the worker and from the message queue, the message including the IP address (Exemplary Citations: for example, Abstract, Paragraphs 35, 37, 49, 53, 55, 58, 80, 83, 91, 92, 96, 97, 98, 101, 103, 108, 111, 112, 121, 125, 126, 127, , 133, 135, 136, 139, 140-142, 149, 151, 152, 157, and associated figures; the above-described worker grabbing the message contents, IP address, or the like, for example); and
Updating, by the worker and in response to the message, the prefix list to include the IP address (network function and the second network function on the IP address (Exemplary Citations: for example, Abstract, Paragraphs 18-21, 32, 35, 37, 45, 50-53, 55, 58, 59, 80, 92-96, 106-108, 111, 112, 117, 119-121, 125-133, and associated figures; updating the above-described lists to include IP address, for example); and
Forwarding, by a load balancer a communication having an IP address to the first network function and from the second network function in response to the prefix list including the IP address (Exemplary Citations: for example, Abstract, Paragraphs 18-21, 32, 35, 37, 45, 50-53, 55, 58, 59, 80, 87, 92-96, 106-108, 111, 112, 116, 117, 119-121, 125-133, and associated figures; load balancer being used to forward communications using IP addresses, for example);
But does not appear to explicitly disclose that the network functions are Open RAN network functions and that the IP address of the communication is masked.
Mishra, however, discloses that the network functions are Open RAN network functions (The entirety of Mishra is directed to an OpenRAN architecture. Exemplary Citations: for example, Abstract; Paragraphs 20-24, 26, 28, 57, 87, 167, 231-236, and associated figures; Open RAN network functions, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the Open RAN techniques of Mishra into the address management system of Miller in order to increase extensibility in the system, to allow the system to be used with an open radio access network standard, help modernize networks, reduce deployment cost and complexity, increase operational efficiency, allow customers to find new revenue streams, and/or increase security in the system.
Sharma, however, discloses that the IP address of the communication is masked (Exemplary Citations: for example, Column 16, lines 7-16; Column 18, lines 31-41; and associated figures; load balancer uses masked IP address, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the masked address load balancing techniques of Sharma into the address management system of Miller in order to allow the system to deal with masked addresses, to allow for load balancing using masked addresses, to increase speed of lookups, to enhance scalability, and/or to increase security in the system.
Regarding Claim 7,
Claim 7 is a process claim that is broader than process claim 1 and is rejected for the same reasons.
Regarding Claim 2,
Miller as modified by Mishra and Sharma discloses the method of claim 1, in addition, Miller discloses that updating the prefix list to allow communication includes adding an identifier that includes the IP address to the prefix list (Exemplary Citations: for example, Abstract, Paragraphs 18-21, 32, 35, 37, 45, 50-53, 55, 58, 59, 80, 92-96, 106-108, 111, 112, 117, 119-121, 125-133, and associated figures).
Regarding Claim 8,
Claim 8 is a process claim that is broader than process claim 2 and is rejected for the same reasons.
Regarding Claim 3,
Miller as modified by Mishra and Sharma discloses the method of claim 1, in addition, Miller discloses terminating the instance in response to a declining load on the first Open RAN (Mishra: The entirety of Mishra is directed to an OpenRAN architecture. Exemplary Citations: for example, Abstract; Paragraphs 20-24, 26, 28, 57, 87, 167, 231-236, and associated figures) network function (Exemplary Citations: for example, Abstract, Paragraphs 18, 20, 37, 57-59, 90-98, 117, 121, 139-143, 149-152, and associated figures; removing address and terminating a VM, service when no longer needed, or the like, for example).
Regarding Claim 9,
Claim 9 is a process claim that is broader than process claim 3 and is rejected for the same reasons.
Regarding Claim 4,
Miller as modified by Mishra and Sharma discloses the method of claim 3, in addition, Miller discloses broadcasting, by the notification service, a second message indicating termination of the instance having the IP address to the message queues subscribed to the notification service (Exemplary Citations: for example, Abstract, Paragraphs 18, 20, 37, 57-59, 90-98, 117, 121, 139-143, 149-152, and associated figures; message regarding address removal, termination, or the like, going to all relevant parties that need to receive such as notification, for example).
Regarding Claim 10,
Claim 10 is a process claim that is broader than process claim 4 and is rejected for the same reasons. It is noted that claims 1 and 7 have already been rejected showing the Open RAN network function associated with the notification service, for example. Please see above.
Regarding Claim 5,
Miller as modified by Mishra and Sharma discloses the method of claim 4, in addition, Miller discloses consuming, by the worker and from the message queue, the second message including termination of the instance having the IP address (Exemplary Citations: for example, Abstract, Paragraphs 18, 20, 37, 57-59, 90-98, 117, 121, 139-143, 149-152, and associated figures; worker, as above, grabbing message from queue, for example); and
Updating, by the worker and in response to consuming the message, the prefix list to block communication between the first Open RAN (Mishra: The entirety of Mishra is directed to an OpenRAN architecture. Exemplary Citations: for example, Abstract; Paragraphs 20-24, 26, 28, 57, 87, 167, 231-236, and associated figures) network function and the second Open RAN (Mishra: The entirety of Mishra is directed to an OpenRAN architecture. Exemplary Citations: for example, Abstract; Paragraphs 20-24, 26, 28, 57, 87, 167, 231-236, and associated figures) network function on the IP address (Exemplary Citations: for example, Abstract, Paragraphs 18, 20, 37, 57-59, 90-98, 117, 121, 139-143, 149-152, and associated figures; updating list to remove IP address/prefix, for example).
Regarding Claim 11,
Claim 11 is a process claim that is broader than process claim 5 and is rejected for the same reasons.
Regarding Claim 6,
Miller as modified by Mishra and Sharma discloses the method of claim 4, in addition, Miller discloses initializing a security control associated with the first Open RAN (Mishra: The entirety of Mishra is directed to an OpenRAN architecture. Exemplary Citations: for example, Abstract; Paragraphs 20-24, 26, 28, 57, 87, 167, 231-236, and associated figures) network function, wherein the security control creates rules based on the prefix list (Exemplary Citations: for example, Abstract, Paragraphs 18-21, 32, 35, 37, 45, 50-53, 55, 58, 59, 80, 92-96, 106-108, 111, 112, 117, 119-121, 125-133, and associated figures; security table, security group, etc., at the resource, which sets forth rules based on the lists, for example).
Regarding Claim 12,
Miller as modified by Mishra and Sharma discloses the method of claim 7, in addition, Miller discloses that a security group associated with the second network function creates rules based on the prefix list (Exemplary Citations: for example, Abstract, Paragraphs 18-21, 32, 35, 37, 45, 50-53, 55, 58, 59, 80, 92-96, 106-108, 111, 112, 117, 119-121, 125-133, and associated figures; security table, security group, etc., at the resource, which sets forth rules based on the lists, for example).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jeffrey D Popham whose telephone number is (571)272-7215. The examiner can normally be reached Monday through Friday 9:00-5:30.
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 Nickerson can be reached at (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.
/Jeffrey D. Popham/Primary Examiner, Art Unit 2432
Prosecution Insights