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 .
This Office Action is in response to amendment filed on 12/23/2025.
Response to Amendment
By this amendment, claims 1, 6-8, and 13-14 are amended. Therefore, claims 1-14 are pending. Any objections and rejections not repeated below is withdrawn due to Applicant's amendment.
Response to Arguments
Applicant's arguments filed 12/23/2025 have been fully considered but they are not persuasive. Applicant argues in substance:
As acknowledged by the Office Action, the detailed steps of "controlling, by the controller domain, the client domains in parallel to enable multi-processing for the client domains" are not disclosed by Petras.
Applicant agrees. Specifically, Petras does not mention parsing of configuration file, starting of a unix domain socket server, instantiating of instances, recording of sockets, among other things.
With regard to point (a), Examiner respectfully disagrees with Applicant that Petras does not disclose "controlling, by the controller domain, the client domains in parallel to enable multi-processing for the client domains" for the reasons in this Office Action’s 103 rejection below. However, Examiner does agree with Applicant that Petras does not disclose parsing of configuration file, starting of a unix domain socket server, instantiating of instances, recording of sockets, among other things (as prior arts Peeters and Bailey teaches the above). Therefore, the claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
First, the sub models in Peeters obtained by cutting up a single model are not equivalent to the instances of pre-existing SystemC intellectual property modules from a previous single-threaded ESL virtual platform. As a result, there is also no mentioning of instantiating in Peeters. The same applies to Petras as well as other cited references.
Second, for the same reason, no recording of sockets of respective instances are disclosed. In this regard, Peeters only mentions broken links between sub models.
Third, no parsing to determine specific SystemC intellectual property modules included in each client domain is disclosed. The parsing of configuration files in Peeters as cited by Examiner relates to wrapper association between the sub models. The only similarity between these two lies in the term parsing.
With regard to point (b), Examiner respectfully disagrees with Applicant. First, Petras discloses Col. 1 lines 21-22 “Most virtual platform simulations, such as SystemC based simulations, are inherently sequential in nature”. This indicates that the partitioned model comprising processor core models 105, 110, 115, 120 from Petras originates from a sequential simulation and thus is equivalent to a previous single-threaded ESL virtual platform comprising instances of pre-existing SystemC intellectual property modules. Second, Peeters discloses recording of sockets of respective instances wherein ([Abstract]; [Page 2 par. 7]) “Therefore, some communication links between SystemC modules are broken as the result of the cutting. These broken links are replaced by virtual links, providing the inter-cluster communication substrate”. The virtual links replacing the broken links are interpreted as the recording of sockets between SystemC modules (instances). Third, Peeters discloses Page 3 par 5 “Wrapper association, used to create a virtual link, is made before the simulation begins. Associations are specified in a configuration file, containing wrappers unique identifiers. This file is loaded at start-up and parsed to build virtual links” and Page 3 par 4 “both wrappers are implemented as SystemC modules”. Thus, the configuration file must specify the wrappers (SystemC modules) in order to associate and link them. Therefore, the claims are rejected for the reasons in this Office Action’s 103 rejection below. Argument has not been found to be persuasive.
Drawings
The drawings are objected to because “Client domain” should read “Controller domain 0” in Fig. 2. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
[0010], [0036], [0038], [0057], and [0059] “…the salve module…” should read “…the slave module…”.
Appropriate correction is required.
Claim Objections
Claims 1-14 are objected to because of the following informalities:
In Claims 1 and 8, “a plurality of client domains” should read “client domains”.
In Claim 1, “determine the SystemC intellectual property modules included in each client domain” should read “determine the pre-existing SystemC intellectual property modules included in each client domain”.
In Claims 5 and 12, “by the master model” should read “by a master model”.
In Claims 5 and 12, “the messages in the predefined message format to the remote target proxy through a corresponding unix domain socket” should read “the messages in the predefined message format to the remote target proxy through the corresponding unix domain socket”.
In Claim 7, “the step of controlling the client domains” should read “steps of controlling the client domains”.
In Claim 8, “determine SystemC intellectual property modules included in each client domain” should read “determine the pre-existing SystemC intellectual property modules included in each client domain”.
In Claim 8, “its own instances of SystemC intellectual property modules” should read “its own instances of the pre-existing SystemC intellectual property modules”.
In Claim 12, “wherein the client domains are communicated with each other through a corresponding unix domain socket” should read “wherein the client domains are communicated with each other through the corresponding unix domain socket”.
Any claim not specifically mentioned above, is objected due to its dependency on an objected claim.
Appropriate correction is required.
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-3 and 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over Petras et al. Pat. No. US 10,445,445 B2 (hereafter Petras) in view of Peeters et al. NPL “A SystemC TLM Framework for Distributed Simulation of Complex Systems with Unpredictable Communication” (hereafter Peeters), and further in view of Bailey Pub. No. US 2008/0155103 Al.
Regarding claim 1, Petras teaches a multi-processing (simulation of a plurality of processor core models) accelerating (can result in a 2x to 8x improvement in simulation speed) method (method for simulation of a prototype system) based on an electronic-system-level virtual platform (The method for the virtual prototype simulation disclosed herein allows multiple processor core models to be simulated concurrently) (In some embodiments, the virtual prototype simulation is a SystemC simulation) ([Col. 2 line 30-Col. 3 line 19]; [Col. 5 lines 27-49]; [Col. 6 lines 26-40]; [Col. 9 lines 4-11]; Fig. 1-2), comprising: creating (initialization of the virtual prototype simulation 100 in FIG. 1) a controller domain (ROTS 130 is controlled by the simulation kernel 135 that represents a simulation scheduler) and a plurality of client domains (processor core models 105, 110, 115, 120) on the electronic-system-level virtual platform (The method for the virtual prototype simulation disclosed herein allows multiple processor core models to be simulated concurrently) (In some embodiments, the virtual prototype simulation is a SystemC simulation) ([Col. 6 lines 41- Col. 7 line 64]; Fig. 1-2), wherein each client domain corresponds to a process (Each processor core model in the parallel mode 604 is executed in a different OS thread) (Col. 14 line 55 - Col. 15 line 6]; Fig. 1-2 & 6) and comprises instances of pre-existing SystemC intellectual property modules from a previous single-threaded ESL virtual platform (Most virtual platform simulations, such as SystemC based simulations, are inherently sequential in nature) ([Col. 1 lines 21-22]); and controlling, by the controller domain (ROTS 130 is controlled by the simulation kernel 135 that represents a simulation scheduler), the client domains (processor core models 105, 110, 115, 120) in parallel (FIG. 4, the processor core models 105 and 110 are executed in parallel) to enable multi-processing (simulation of a plurality of processor core models) for the client domains (Col. 2 line 30-Col. 3 line 19]; [Col. 5 lines 27-49]; [Col. 6 lines 26-40]; [Col. 9 lines 4-11]; Fig. 1-4).
Petras fails to teach by: during initialization, parsing, by the controller domain, a configuration file to determine the SystemC intellectual property modules included in each client domain … and during modularization, instantiating, by each client domain, the instances of the pre-existing SystemC intellectual property modules and recording initiator TLM sockets or target TLM sockets of the respective instances.
In analogous art Peeters teaches by: during initialization (Wrapper association, used to create a virtual link, is made before the simulation begins), parsing, by the controller domain (The hardware part of the validation model (figure 2a)), a configuration file to determine the SystemC intellectual property modules included in each client domain (Wrapper association, used to create a virtual link, is made before the simulation begins. Associations are specified in a configuration file, containing wrappers unique identifiers. This file is loaded at start-up and parsed to build virtual links) ([Page 3 par 5]; Fig. 2) … and during modularization, instantiating, by each client domain, the instances of the pre-existing SystemC intellectual property modules (Simulated system model is cut up and distributed across separate simulation engines, each part being evaluated in parallel of others) and recording initiator TLM sockets or target TLM sockets of the respective instances (Therefore, some communication links between SystemC modules are broken as the result of the cutting. These broken links are replaced by virtual links, providing the inter-cluster communication substrate.) ([Abstract]; [Page 2 par. 7]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Petras to incorporate the teachings of Peeters to synchronize execution for parallel TLM simulations (Peeters Page 1 par. 4).
Petras and Peeters fail to teach starting a unix domain socket server, and waiting for the client domains to connect to the unix domain socket server.
In analogous art Bailey teaches starting a unix domain socket server (server starts the unix domain server) (Accordingly, and according to one exemplary embodiment of the present invention, the use of Unix domain sockets are extended to support communication across operating system images), and waiting for the client domains to connect to the unix domain socket server (The server then uses the socket to bind() to a local internet address and port, which represents the service that is being provided (step 214), and listens (step 216) for client application 220 to connect() to the service (step 224).) ([0029]-[0033]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Petras and Peeters to incorporate the teachings of Bailey to provide two-way communication through system barriers for the multi-processor system (Bailey [0001]-[0011]).
Regarding claim 2, Petras, Peeters, and Bailey teach the multi-processing accelerating method based on the electronic-system-level virtual platform according to claim 1, and Petras further teaches wherein each client domain comprises a client and SystemC intellectual property models (In some embodiments, the virtual prototype simulation is a SystemC simulation), each client is used to communicate with the controller domain (immediate request flag 435) ([Col.2 line 30-Col. 3 line 19]; [Col. 5 lines 27-49]; [Col. 6 lines 26-40]; [Col. 9 lines 4-11]; Fig. 1-2 & 4).
Regarding claim 3, Petras, Peeters, and Bailey teach the multi-processing accelerating method based on the electronic-system-level virtual platform according to claim 1, and Bailey further teaches wherein the controller domain is communicated with each client domain through a corresponding unix domain socket (The server then uses the socket to bind() to a local internet address and port, which represents the service that is being provided (step 214), and listens (step 216) for client application 220 to connect() to the service (step 224) ... Accordingly, and according to one exemplary embodiment of the present invention, the use of Unix domain sockets are extended to support communication across operating system images) ([0029] - [0033]).
Regarding claim 8, Petras further teaches a multi-processing accelerating system based on an electronic-system-level virtual platform (FIG. 9 is an example block diagram of a computer system that may perform the virtual prototype simulation in FIG. 1) ([Col. 21 line 62- Col. 22 line 13]; Fig. 9). The other limitations are substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 9, it is a machine claim whose limitations are substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 10, it is a machine claim whose limitations are substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
Claims 4 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Petras et al. Pat. No. US 10,445,445 B2 (hereafter Petras) in view of Peeters et al. NPL “A SystemC TLM Framework for Distributed Simulation of Complex Systems with Unpredictable Communication” (hereafter Peeters), further in view of Bailey Pub. No. US 2008/0155103 Al as applied to claims 1-3 and 8-10 above, and further in view of Okman Pub. No. US 2021/0133000 Al.
Regarding claim 4, Petras, Peeters, and Bailey teach the multi-processing accelerating method based on the electronic-system-level virtual platform according to claim 1.
Petras, Peeters, and Bailey fail to teach wherein the client domains are communicated with each other through a corresponding unix domain socket.
In analogous art Okman teaches wherein the client domains are communicated with each other through a corresponding unix domain socket (Client domain A and client domain B (Acting as a target) communicate via shared UDS for request, FD transfers, signal propagation and return code. Communication is point-to-point between containers in the same Pod) ([0004]; [0009]-[0022]; [0024], [0026]; [0028]; [0031]-[0036]; [0038]-[0046]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Petras, Peeters, and Bailey to incorporate the teachings of Okman to enable point to point communication between domains working in a multi-processor environment (Okman [0002]).
Regarding claim 11, it is a machine claim whose limitations are substantially the same as those of claim 4. Accordingly, it is rejected for substantially the same reasons.
Claims 5-6 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Petras et al. Pat. No. US 10,445,445 B2 (hereafter Petras) in view of Peeters et al. NPL “A SystemC TLM Framework for Distributed Simulation of Complex Systems with Unpredictable Communication” (hereafter Peeters), further in view of Bailey Pub. No. US 2008/0155103 Al, further in view of Okman Pub. No. US 2021/0133000 Al as applied to claims 4 and 11 above, and further in view of Jiang CN111666164A.
Regarding claim 5, Petras, Peeters, and Bailey teach the multi-processing accelerating method based on the electronic-system-level virtual platform according to claim 1.
Petras, Peeters, and Bailey fail to teach steps where the client domains are communicated with each other through a corresponding unix domain socket comprise … through a corresponding unix domain socket.
In analogous art Okman teaches steps where the client domains are communicated with each other through a corresponding unix domain socket comprise … through a corresponding unix domain socket (Client domain A and client domain B (Acting as a target) communicate via shared UDS for request, FD transfers, signal propagation and return code. Communication is point-to-point between containers in the same Pod) ([0004]; [0009]-[0022]; [0024], [0026]; [0028]; [0031]-[0036]; [0038]-[0046]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Petras, Peeters, and Bailey to incorporate the teachings of Okman to enable point to point communication between domains working in a multi-processor environment (Okman [0002]).
Petras, Peeters, Bailey, and Okman fail to teach setting two of the client domains communicated with each other to be a master module domain and a slave module domain respectively, wherein the master module domain comprises a master module and a remote initiator proxy, and the slave module domain comprises a slave module and a remote target proxy; encoding and serializing, by the master model, transaction-level-modeling (TLM) messages into messages in a predefined message format, and transmitting the messages in the predefined message format to the remote initiator proxy; transmitting, by the remote initiator proxy, the messages in the predefined message format to the remote target proxy … deserializing and decoding, by the remote target proxy, the messages in the predefined message format to obtain the TLM messages, and transmitting the TLM messages to the slave module; and receiving, by the slave module, the TLM messages.
In analogous art Jiang teaches setting two of the client domains communicated with each other (two parties establish a session connection for transmitting the transaction-level modeling) (The Initiator and Target TLM are connected through sockets) to be a master module domain (stub) and a slave module domain (the proxy) respectively, wherein the master module domain comprises a master module and a remote initiator proxy, and the slave module domain comprises a slave module and a remote target proxy (The stub acts as an initiator in the transaction-level modeling, and the proxy acts as a target in the transaction-level modeling); encoding and serializing, by the master model, transaction-level-modeling (TLM) messages into messages in a predefined message format, and transmitting the messages in the predefined message format to the remote initiator proxy; transmitting, by the remote initiator proxy, the messages in the predefined message format to the remote target proxy (The local method of the Stub packages the remote method name and calling parameters into a transaction-level modeling general load class tlm_generic_payload, and transmits the tlm_generic_payload to the proxy unit Proxy in the service module) … deserializing and decoding, by the remote target proxy, the messages in the predefined message format to obtain the TLM messages (The proxy unit Proxy parses the tlm_generic_payload sent from the Stub), and transmitting the TLM messages to the slave module (The proxy unit calls the remote method in the service module that actually processes the data according to the parsed result); and receiving, by the slave module, the TLM messages (Therefore, after the proxy Proxy parses the remote method name and call parameters in tlm_generic_payload, it can directly The remote method name calls the remote method of the service module (ie, the actual data processing method), and the data processing method of the service module performs actual business processing on the data).([Page 2 par. 1]; [Page 3]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Petras, Peeters, Bailey, and Okman to incorporate the teachings of Jiang to increase the speed of transaction level modeling, allowing for software to be more efficiently prototyped and tested (Jiang Page 2 par. 5).
Regarding claim 6, Petras, Peeters, Bailey, Okman, and Jiang teach the multi-processing accelerating method based on the electronic-system-level virtual platform according to claim 5, and Jiang further teaches wherein the master module and the salve module are implemented by SystemC intellectual property models of corresponding client domains respectively (Transaction Level Modeling (TLM) is a set of C++ library codes based on SystemC for transaction-level modeling of chips) (The stub acts as an initiator in the transaction-level modeling, and the proxy acts as a target in the transaction-level modeling), and the remote initiator proxy and the remote target proxy are implemented by client instances of corresponding client domains respectively (two parties establish a session connection for transmitting the transaction-level modeling) (The Initiator and Target TLM are connected through sockets) ([Page 2 par. 1]; [Page 3]).
Regarding claim 12, it is a machine claim whose limitations are substantially the same as those of claim 5. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 13, it is a machine claim whose limitations are substantially the same as those of claim 6. Accordingly, it is rejected for substantially the same reasons.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Petras et al. Pat. No. US 10,445,445 B2 (hereafter Petras) in view of Peeters et al. NPL “A SystemC TLM Framework for Distributed Simulation of Complex Systems with Unpredictable Communication” (hereafter Peeters), further in view of Bailey Pub. No. US 2008/0155103 Al as applied to claims 1-3 and 8-10 above, and further in view of Tan et al. Pat. No. US 8,849,644 B2 (hereafter Tan).
Regarding claim 7, Petras, Peeters, and Bailey teach the multi-processing accelerating method based on the electronic-system-level virtual platform according to claim 1, and Bailey further teaches during start-up, creating, by each client domain (client application 120 intends to establish a connection to server application 110), its own ("socket()" system call which creates the socket and returns the socket descriptor handle) remote initiator sockets or its own remote target sockets (bind() and connect() socket calls that establish the binding to the service and the start the logical communication channel), and establishing connections among the client domains based on a confirmation message from the controller domain (server 200) (the client and server use read() and write() (steps 128 and 118) system calls to send and receive messages over the logical communication channel) ([0029]-[00331]).
Petras, Peeters, and Bailey fail to teach starting, by each client domain, its own SystemC kernels when all the client domains receive a barrier message from the controller domain; and during operation, when any client domain transmits an end message to the controller domain, broadcasting, by the controller domain, the end message to the other client domains to stop the operation of all the client domains and end the operation of the controller domain.
In analogous art Tan teaches starting (event queue 106 starts execution), by each client domain, its own SystemC kernels (a plurality of kernels are provided. Each kernel may simulate a partition of a design under test) when all the client domains receive a barrier message from the controller (a master kernel 104) domain (A globally aggregated status for the above information may be aggregated and communicated to all the kernels. For example, a master kernel 104 can be designated that aggregates the status); and during operation, when any client domain transmits an end message to the controller domain, broadcasting (A globally aggregated status for the above information may be aggregated and communicated to all the kernels. For example, a master kernel 104 can be designated that aggregates the status), by the controller domain (a master kernel 104), the end message to the other client domains to stop the operation of all the client domains and end the operation of the controller domain (information on if any kernel has been instructed to end the simulation) ([Abstract]; [Col. 2 line 25 - Col. 4 line 28]; [Col. 6 lines 26-44]; Figs. 1, 3).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Petras, Peeters, and Bailey to incorporate the teachings of Tan to control access to resources when executing parallel simulations and prevent slowdowns caused by threads not being able to access necessary resource sectors (Tan Col. 1 lines 12-27).
Regarding claim 14, it is a machine claim whose limitations are substantially the same as those of claim 7. Accordingly, it is rejected for substantially the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. In particular, US 11475199 B1 is cited because it discloses parallelizing simulation of circuit designs with socket communications.
THIS ACTION IS MADE FINAL. 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.
Examiner respectfully requests, in response to this Office action, support be
shown for language added to any original claims on amendment and any new claims.
That is, indicate support for newly added claim language by specifically pointing to
page(s) and line number(s) in the specification and/or drawing figure(s). This will assist
Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111 (c).
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN CHE-CHUN TONG whose telephone number is (703)756-1737. The examiner can normally be reached Monday-Thursday: 7:30 AM to 5:00 PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on (571)270-1014. 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.
/J.C.T./Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights