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-20 have been examined.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/7/25 has been entered.
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.
Response to Arguments
Applicant's arguments filed on 11/7/25 have been fully considered but they are not persuasive.
Applicant mainly argues that the prior art of record does not disclose “generating, …based on the request, the new communication protocol suing a generative model; …and causing… an endpoint in a network to communicate using the new communication protocol via the software.” Applicant asserts that Keini is directed to interoperability in heterogeneous IoT environments by enabling device that already speak different communication protocols to interact by creating translators, and Keini’s “generation” is confined to translation artifacts that bridge between existing protocols. However, it’s unclear what portions of Keini is referred to for the mapping and translation artifacts that bridge between existing protocols because the portions of Keini cited by the examiner focus on generating custom communication protocols based on protocol specification requested by users (Keini: [0018]-[0021]). Furthermore, Keini aims to solve similar problem as present application, which is to circumvent attacks targeting off-the-shelf communication protocols by generating custom/proprietary communication protocol enforcing components (Keini: [0005]).
Lastly, Keini discloses receiving request through user interface to define and generate custom communication protocol that can be implemented via software/protocol enforcing component (e.g. driver or application), wherein the protocol enforcing component are deployed to endpoints in network to properly process communication using the custom protocol ([0025]). Applicant is encouraged to contact the examiner regarding claim interpretation.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-6, 8, 10-16, 18 and 20 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Keini et al. U.S. Pub. No. 2017/0099322 (hereinafter Keini).
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 (Keini: [0019]-[0020]: protocol abstraction model generates definitions/protocol rules based on specification defined by user; [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).
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 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]).
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 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Keini.
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.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Keini in view of Yan et al. U.S. Pat. No. 11,968,088 (hereinafter Yan).
As per claim 9 and 19, Keini discloses the limitations in claims 1 and 11 respectively. Keini 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).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Li et al. U.S. 2021/0099424 discloses industrial control system comprising a protocol creation module that is capable of allowing users to input their proprietary protocol and to configure customized firewall rules or define payload frame in a firewall rules library.
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