DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-22 have been examined.
Examiner’s Comment
The term “communication protocol” is interpreted as set of instructions or configurations to enforce/implement communication policy or rules. Therefore, the claims are examined based on broadest reasonable interpretation consistent with the Specification. Applicant is advised to further recite functional steps associated with protocol generation and define the scope of new communication protocols instead of reciting the steps at a high level of generality to expedite prosecution. Furthermore, Applicant is advised to further clarify the steps taken to generate new protocols instead of merely reciting generating protocol with generative machine learning models.
Response to Arguments
Applicant’s arguments with respect to claims 1-22 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Specifically, Amend et al. U.S. 12,212,640, discloses method for providing a generic multipath system by flexible selection of network protocols based on AI/machine learning models. Disclosure of Amend reasonably corresponds to disputed limitations as set forth below.
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.
Claim 1-8, 10-18, 20 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Keini et al. U.S. Pub. No. 2017/0099322 (hereinafter Keini) in view of in view of Amend et al. U.S. et al. U.S. 12,212,640 (hereinafter Amend).
As per claim 1, 11 and 20, Kein discloses a method/apparatus/medium, comprising:
one or more network interfaces (Keini: Fig. 3: network interface; [0030]);
a processor coupled to the one or more network interfaces and configured to execute one or more processes (Keini: Fig. 3: communication layer constructor with processors; [0055]); and
a memory configured to store a process that is executable by the processor, the process when executed configured to:
receive a request to generate a new communication protocol that was previously non-existent (Keini: 0018]: receive user input/request to generate a specific communication protocol implementation tailored for certain application, which may be non-existent; [0024]: software tools are provided for graphically defining the specification for the specific communication protocol);
generate, based on the request, new protocol rules for the new communication protocol using a generative model, wherein the generative model autonomously determines the new protocol rules including at least one of: header fields, header field sizes, cipher suites, or handshake exchanges (Keini: [0019]-[0020]: protocol abstraction model automatically generates definitions/protocol rules based on specification defined by user; [0032]: communication model comprises allowed field types, allowed message types, etc.; [0087]: communication model comprises the specifics of a protocol definition including various specific rules);
storing, in storage space of the space that is available, new protocol rules (Keini: [0034]: definitions repository for storing predefined definitions associated with the specific protocol);
configure software to access new protocol rules to enable the software to use the new communication protocol (Keini: [0019]- [0021]: generate protocol enforcing component/software are configured based on the communication protocol using protocol definitions and rules; [0025]: enforcing component implemented as software or driver); and
cause an endpoint in a network to communicate using the new communication protocol via the software (Keini: [0025]: protocol enforcing component/software is deployed as gateway or operating system level communication driver or linked to application software to monitor communication traffic).
Keini does not explicitly disclose machine learning model trained on a training dataset of protocol standards. However, Amend discloses using AI/ML models to generate and configure network protocols that are trained based on protocol standards (Amend: col. 2 lines 41-56: access library of network protocols; col. 5 lines 11-28: allowing selection of a mix of network protocols; col. 7 lines 5-16: the selection is implemented by AI and or machine learning mechanism that improves over time). It would have been obvious to one having ordinary skill in the art to implement AI/ML models to improve intent-based network configuration based on traffic data because they are analogous art involving customized network configuration. The motivation to combine would be to provide generic multipath system using various network protocols.
As per claim 2 and 12, Keini discloses the limitations in claims 1 and 11 respectively. Keini further discloses wherein the apparatus receives the request from a user interface (Keini: [0035]: GUI configured to present user various selectable options to define and configure communication protocol).
As per claim 3 and 13, Keini discloses the limitations in claims 1 and 11 respectively. Keini further wherein the software comprises an operating system, a device driver, or an application (Keini: [0019]-[0021]; [0025]: the protocol enforcing component can be implemented by software, driver, etc.).
As per claim 4 and 14, Keini discloses the limitations in claims 1 and 11 respectively. Keini further discloses wherein the generative model is configured to generate a new format for the new communication protocol that it had not generated previously (Keini: [0022]-[0025]: definitions of the protocol specification defined by user to ensure messages received comply with the policy, e.g. allowed field types, message types, classes, structures, etc.).
As per claim 5 and 15, Keini discloses the limitations in claims 1 and 11 respectively. Keini further discloses wherein the request includes a seed value that the generative model uses to generate the new communication protocol (Keini: [0030]: input data about specific communication protocol to generate the communication protocol model).
As per claim 6 and 16, Keini discloses the limitations in claims 1 and 11 respectively. Keini further discloses wherein the apparatus is the endpoint in the network (Keini: Fig. 3; [0079]-[0082]).
As per claim 7 and 17, Keini discloses the limitations in claims 1 and 11 respectively. Keini discloses generating secure network communication protocol based on user defined input (Keini: [0018]: secure and robust protocol enforcing components). Keini does not explicitly disclose wherein the new communication protocol encrypts communications sent by the software via the network and decrypts communications received by the software via the network. However, defining cryptographic protocol for network communication is well known in the art.
As per claim 8 and 18, Keini discloses the limitations in claims 1 and 11 respectively. Keini further discloses wherein the apparatus causes the endpoint in the network to communicate using the new communication protocol via the software by: distributing the software to the endpoint (Keini: [0025]; [0060]: deploy the protocol enforcing component to endpoint; [0076]-[0077]: ).
As per claim 10, Keini discloses the limitations of claim 11. Keini further discloses the endpoint communicates with a second endpoint in the network using the new network protocol, and wherein the second endpoint executes a copy of the software to communicate using the new communication protocol (Keini: Fig. 3; [0097]-[0098]).
As per claim 11, Keini as modified discloses the limitations of claim 1. Keini as modified further discloses tracking configurations of communication protocols generated by the generative machine learning model over time; and ensuring that the new communication protocol uses a new format that was not previously generated (Amend: col. 2 lines 41-56: access library of network protocols; col. 5 lines 11-28: allowing selection of a mix of network protocols; col. 7 lines 5-16: the selection is implemented by AI and or machine learning mechanism that improves over time). Same rationale applies here as above in rejecting claim 1.
Claims 9, 19 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Keini in view of Amend and further in view of Yan et al. U.S. Pat. No. 11,968,088 (hereinafter Yan).
As per claim 9 and 19, Keini as modified discloses the limitations in claims 1 and 11 respectively. Keini as modified does not explicitly disclose wherein the generative model comprises a large language model (LLM). However, Yan discloses managing network configuration using large language model to update and deploy network configuration (Yan: col. 1 ll. 39-67). It would have been obvious to one having ordinary skill in the art to utilize LLM to configure network communication because Keini and Yan both disclose configuring network protocol through user defined parameters. The motivation to combine would be to provide ease of use model that does not require substantial knowledge in network configuration language (Yan: col. 1 ll. 6-15).
As per claim 22, Keini as modified discloses the limitations of claim 1. Keini as modified does not explicitly disclose updating the software to use an updated communication protocol generated by the generative model, wherein the updated communication protocol is different from the new communication protocol. However, Yan discloses managing network configuration using large language model to update and deploy network configuration (Yan: col. 1 ll. 39-67). It would have been obvious to one having ordinary skill in the art to utilize LLM to configure network communication because Keini and Yan both disclose configuring network protocol through user defined parameters. The motivation to combine would be to provide ease of use model that does not require substantial knowledge in network configuration language (Yan: col. 1 ll. 6-15).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
O’Neil U.S. 2020/0389500 discloses network application security policy generation using machine learning models.
DelloStritto et al. U.S. 2008/0082683 discloses communication of information between a plurality of network elements using various protocols.
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 SHIN HON (ERIC) CHEN whose telephone number is (571)272-3789. The examiner can normally be reached Monday to Thursday 9am- 7pm.
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, Lynn Feild can be reached at 571-272-2092. 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.
/SHIN-HON (ERIC) CHEN/ Primary Examiner, Art Unit 2431
Prosecution Insights