Multicore data processing system with local and global input/output devices and graphical interface comprising such a data processing system
Summary by NHIP
GPU-CPU Parallel Data Transfer System
The system features a multicore processor with dedicated local interfaces for exclusive peripheral access and global interfaces for shared resources. Each core connects to a local bus via direct access interfaces operating without arbitration, while the GPU and CPU link through a single data transfer device enabling parallel data movement.
Claim Score by NHIP
Abstract
A multicore data processing system includes a set of data processing cores. At least a part of each data processing core includes a set of local data input and output interfaces for access to peripheral devices dedicated to said cores. It further includes a set of global data input and output interfaces for access to peripheral devices shared between said cores.

Term
9.5 yearsleft in the term
Expires 10 March 2036, including 338 days of term adjustment.
- Priority
- Filed
- Granted
- Today
- Expires
12 claims: 2 independent, 10 dependent
- 1Broadest claimClaim Score 29, narrow(NHIP)A multicore data processing system, comprising:at least one graphics processing unit (GPU) comprising a set of data processing cores, wherein at least a part of each data processing core comprises a set of local data input and output interfaces for access to a plurality of dedicated external peripheral devices, wherein each of the local data input and output interfaces is a direct access interface configured to operate without global sharing and without arbitration, wherein each of the plurality of dedicated external peripheral devices communicates with a corresponding one of the set of data processing cores via a local bus;at least one central processing unit (CPU), wherein the at least one graphics processing unit (GPU) which communicates with the central processing unit, wherein each of a set of data processing cores of the central processing unit are connected to a processing core of the graphics processing unit by a single data transfer device so as to produce a parallel data transfer between said graphics processing unit and said central processing unit;anda set of global data input and output interfaces for access to peripheral devices shared between ones of said set of data processing cores;wherein said data processing cores communicate with each other via a global bus.
- 7A graphical interface for an aircraft cockpit, comprising a multicore data processing system, the multicore data processing system comprising:a set of data processing cores, wherein at least a part of each data processing core comprises a set of local data input and output interfaces for access to a plurality of dedicated external peripheral devices, wherein each of the local data input and output interfaces is a direct access interface configured to operate without sharing and without arbitration, wherein each of the plurality of dedicated external peripheral devices dedicated to said cores communicates with a corresponding one of the set of data processing cores via a local bus;anda set of global data input and output interfaces for access to peripheral devices shared between ones of said set of data processing cores;wherein ones of said set of data processing cores communicate with each other via a global busfurther comprising at least one graphics processing unit (GPU) comprising the set of data processing cores that comprises said local interfaces and said global interfacesfurther comprising at least one central processing unit (CPU) and at least one graphics processing unit (GPU) which communicates with the central processing unit, wherein each of a set of data processing cores of the central processing unit is connected to a processing core of the graphics processing unit by a single data transfer device so as to produce a parallel data transfer between said graphics processing unit and said central processing unit.
Independent claims2
75 paragraphs in 5 sections, as filed
PRIORITY CLAIM
This application claims priority to U.S. Provisional Application Ser. No. 61/976,078 filed Apr. 7, 2014 and French Patent Application No. FR 1457008 filed Jul. 21, 2014, which are incorporated herein by reference in its entirety.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to multicore data processing systems. In a non-limiting application, the present invention relates in particular to multicore systems for a graphical interface based on the use of a graphics processing unit (GPU) which is able to interwork with a central processing unit (CPU). The invention also generally relates to a man-machine interface using such a processing system. In a specific embodiment, the invention relates to data processing systems for man/machine interfaces installed on-board aircraft.
2. Description of the Relevant Art
A need in fact exists to have touch-sensitive man/machine interfaces on-board aircraft.
In the field of graphical interfaces, data processing systems are conventionally used to perform graphics processing operations and create graphical content intended to be displayed on a screen of the interface. This may involve, in particular, creating graphical content comprising manually manipulable touch areas, in this case by a pilot, for the performance of predefined functions.
In the prior art, data processing architectures can generally be implemented in the form of single-core CPUs, multiple central processing units (multi-CPUs) or multicore CPUs. For the implementation of graphics processing, predominantly multicore architectures are used and, in particular, graphics processing units are used that interwork with a central processing unit to increase processing power.
In the case of single-core CPUs, the basic component of an architecture of this type is the processor, which is a component enabling the interpretation of machine instructions defining computer programs.
As is known, in order that a system integrating a processor can operate, it is connected to a permanent storage device which enables the storage of the program that is to be run, to a fast memory for reading and writing the variables used in the running of the programs, and to peripherals of the input/output, communication bus, memory controller, etc., type enabling the exchange of data with the outside of the system.
Modern processors integrated on a chip also integrate a communication bus and very fast cache memory for the storage, as close as possible to the program running area, of the variables used by the program, only the relatively large or least-used variables being sent to the fast memory.
In addition to the processor, Systems on Chip (SoCs) integrate a certain number of peripherals.
Finally, microcontrollers are chips that integrate all of the elements necessary for the operation of the processor, i.e. memory and peripherals.
In the case of single-core CPUs, increasing performance requirements for the processors tend to increase progressively the frequency of operation, made possible by the ever-increasing etching fineness of the silicon. However, the increase in frequency also causes a very substantial increase in consumption, in such a way that the gain in performance becomes marginal in the face of the increase in consumption. It has therefore been proposed to replicate the processing cores in order to parallelize the running of a program, but without increasing the operating frequency.
In a conventional multicore CPU architecture, each core has a first level of cache memory, referred to as the first-level cache memory. The different cores can then share a different cache memory, referred to as the second-level cache memory. A third level of cache memory can be provided when some cores are to be combined.
The parallelization of tasks and the allocation of the instructions to be carried out to one or the other of the cores are performed via the set of instructions interpreted by the processor and by the implemented operating system (OS) which can allocate a given task according to the different cores. This is then referred to as a multicore processor. An implementation strategy of this type may also be applicable to multicore SoCs.
Another strategy consists in providing an architecture similar to the conventional architecture but, instead of parallelizing the operation, the different cores are used to render the processing more reliable. The cores execute the same instructions to within a clock pulse, and the processing operations are then compared in order to obtain a reliable operation under critical conditions. This strategy is known by the name of “Lockstep”.
Another strategy consists in replicating a system rather than a core. This is then referred to as a multiprocessor. Each processor is independent and does not share a cache memory with the others. This type of architecture is generally set up externally in order to implement supercomputers or groups of networked servers to perform relatively complex processing operations requiring substantial processing resources.
In the case of GPU architectures, the graphics processing units, in the same way as CPUs, are processing architectures executing a set of instructions. However, a GPU is a processor optimized for graphics processing operations such as hardware acceleration, three-dimensional processing, video decoding, etc.
GPUs have for a long time consisted of multiple processing cores which distribute graphics tasks among themselves. This involves parallel-processing architectures. As previously indicated, GPUs are predominantly multicore units and may comprise more than 1000 cores, in the case of the most powerful. A certain number of processing operations are allocated to the different cores, to be performed by a controller.
In the case of data processing systems intended to be installed on-board aircraft, as will be understood, this type of electronic system is subject to severe constraints in terms of control of the equipment used, and of determinism, making it necessary to determine with certainty the operation of the system, for example concerning the data transfer duration. They require a validation and certification by the competent authorities. Data processing systems for the on-board man-machine interfaces for commercial aircraft must therefore comply with a certain number of development recommendations and rules.
In the prior art, on-board processing systems are generally implemented on the basis of “Commercial Off The Shelf” (COTS) components, i.e. components that are mass-produced in order to reduce production and maintenance costs. However, the use of conventional COTS components firstly causes problems of obsolescence, making it necessary to procure a large number of components and store them in order to guarantee the maintainability of the product. Given the development time and service life of a product for the aeronautical industry, which may amount to several decades, it is often the case that the components used in the design of an electronic system are in fact obsolete even before the end of the design process, making it necessary to implement periodic modification and recertification phases.
Secondly, the COTS electronic components are generally derived from consumer markets or from the telecommunications sector and are then optimized for non-aeronautical applications. Their use in the aeronautical field involves the deactivation of the original applications, their modification to make them compatible with the aeronautical field, then a certification, incurring additional costs.
Furthermore, standard multicore processing systems comprise only peripheral systems and memories shared among the different processing cores. The cores communicate with data input and output interfaces via a common interface bus to access resources shared between the cores. This results in a requirement for arbitration in the potentially concurrent access to said peripheral systems. This concurrent access is managed in a conventional COTS system by an uncontrolled coherence system. The use of COTS components in an aeronautical system therefore requires the implementation of a large number of software and hardware locks to guarantee the operation of the components while following the recommendations of the certification authorities. The addition of these locks entails a substantial degradation in the performance of the central data processing units.
SUMMARY OF THE INVENTION
In light of the above, the embodiments described herein propose to mitigate problems of determinism in the concurrent access situations encountered in the multifunction data processing systems by limiting the arbitrations implemented upon access to shared resources.
In one embodiment, a multicore data processing system, includes a set of data processing cores and in which at least a part of each data processing core includes a set of local data input and output interfaces for access to peripheral devices dedicated to said cores.
The system further includes a set of global data input and output interfaces for access to peripheral devices shared between said cores.
Thus, by providing local input and output interfaces each of the processing cores has access to its own memories and/or local peripheral systems so that each processing core is totally independent and autonomous with respect to the others. Each of the processing cores is therefore capable of operating without interaction with the other cores.
According to an embodiment, the system includes a set of at least one central processing unit comprising data processing cores that include said local interfaces and said global interfaces. In other words, the processing cores constitute a central processing unit CPU.
According to an embodiment, the multicore system includes a set of at least one graphics processing unit comprising data processing cores that include said local interfaces and said global interfaces. The data processing cores thus constitute graphics processing units.
In one embodiment, the system includes at least one central processing unit and at least one graphics processing unit which communicates with the central processing unit, the processing cores of the central processing unit being each connected to a processing core of the graphics processing unit via a single data transfer means in such a way as to implement a data transfer in parallel between said graphics processing unit and said central processing unit.
There is thus obtained an increase in the processing power while addressing the problem of aeronautical certification by multiplying the CPU/GPU processing cores in order to obtain a cloned architecture having the same task parallelization advantages as a multicore architecture, while limiting the disadvantages of complexity and optionally of uncontrolled shared resources which are not conceivable for reasons of aeronautical safety and criticality.
Advantageously, the data processing cores are connected to an internal local data transfer device connected to said interfaces.
The local internal data transfer device may be connected to peripheral devices each dedicated to one processing core.
Moreover, the data processing cores are advantageously connected to a global data transfer device internal to said graphics processing unit or to said central processing unit and connected to peripheral devices shared between the processing cores.
Preferably, at least a part of each processing core includes a dedicated operating system.
A further embodiment relates to a graphical interface for an aircraft cockpit that includes a multicore data processing system as defined above.
BRIEF DESCRIPTION OF THE DRAWINGS
Other objects, characteristics and advantages of the invention will become apparent from a reading of the detailed description which follows, given purely by way of a non-limiting example, with reference to the attached drawings, in which:
<figref idref="DRAWINGS">FIG. 1</figref> illustrates the general architecture of a conventional data processing system produced from COTS components;
<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of a part of a conventional multicore data processing system, showing the sharing of peripheral devices;
<figref idref="DRAWINGS">FIG. 3</figref> shows the general architecture of a data processing system;
<figref idref="DRAWINGS">FIG. 4</figref> shows a part of a data processing system showing the use of peripherals dedicated to each processing core and shared peripheral devices; and
<figref idref="DRAWINGS">FIGS. 5A and 5B</figref> are views showing the coupling between a CPU and GPU according to the prior art and according to the embodiments described herein, respectively.
While the invention may be susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. The drawings may not be to scale. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but to the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
It is to be understood the present invention is not limited to particular devices or methods, which may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used in this specification and the appended claims, the singular forms “a”, “an”, and “the” include singular and plural referents unless the content clearly dictates otherwise. Furthermore, the word “may” is used throughout this application in a permissive sense (i.e., having the potential to, being able to), not in a mandatory sense (i.e., must). The term “include,” and derivations thereof, mean “including, but not limited to.” The term “coupled” means directly or indirectly connected.
Reference will be made first of all to <figref idref="DRAWINGS">FIG. 1</figref>, which illustrates the architecture of a multicore data processing system according to the prior art, using commercial off-the-shelf components COTS.
As can be seen in <figref idref="DRAWINGS">FIG. 1</figref>, this data processing system is hinged around a dual-core processor P associated with local cache memories <b>1</b> and <b>2</b>, dedicated respectively to the storage of data and to the storage of instructions, and with a higher level shared cache memory <b>3</b> used when the local cache memories <b>1</b> and <b>2</b> are full and associated with a shared memory controller <b>4</b> allowing access to external memories, for example of DDR (double data rate) type.
A common bus <b>5</b> incorporating a cache consistency protocol associated with first communication control peripheral devices <b>6</b> and second input and output peripheral devices <b>7</b> ensures the exchange of data with the processor P.
As indicated previously, this type of architecture presents a certain number of drawbacks relating to the sharing of the cache memory <b>3</b>, of the memory controller <b>4</b> and of the common bus <b>5</b>.
The use of shared means specifically requires the provision of an extensive arbitration in order to authorize access to the processor. Furthermore, the data transfer time on the common bus is not guaranteed. In particular, when the number of cores increases, the management of priorities and the calculation of access times becomes more complex to perform. Furthermore, the number of inputs and outputs is limited.
The deterministic operation of this type of component, notably concerning the data transfer time, which cannot be determined with certainty without employing costly means, is therefore not guaranteed.
Now referring to <figref idref="DRAWINGS">FIG. 2</figref>, in which a number of data processing cores “core#<b>1</b>”, “core#<b>2</b>”, “core#<b>3</b>” are schematically represented, each associated with a cache memory L1 and with a high level cache memory L2 which communicate via local bus B, it can be seen that, according to a conventional architecture, input/output (I/O) interfaces such as IO<b>1</b> and IO<b>2</b> ensure the communication with traditionally shared external devices such that the access to these input/output interfaces which is performed via an interface bus B′ involves an access arbitration.
As indicated previously, the traditional multicore architectures, intended to be embedded onboard aircraft, have to be subject to development rules and recommendations published by the certification authorities. These rules economically and technically penalize the development of an architecture based on COTS components.
<figref idref="DRAWINGS">FIG. 3</figref> shows the general architecture of a multicore data processing system, according to an embodiment, for graphical interface.
To meet the rules and recommendations published by the certification authorities, all the memories (Flash, RAM, Cache) are here separated between the cores to thus limit the use of shared resources. To guarantee a deterministic access to all the other shared resources, a partitioned communication element is used to handle the communication of the different CPU cores. This element can, for example, be a bus or a network on chip NoC.
The same strategy is used for the GPU cores. The GPU cores are independent and are connected to a single CPU core via a dedicated bus. Each GPU core produces a graphics image connected to the application which it manages. The different images produced are then assembled by a mixer, ultimately to produce a screen image which is intended to be displayed on the screen of a man-machine interface.
Each CPU/GPU pair thus hosts a graphics application distinct and independent from the others. This architecture therefore enables the development in parallel and by a plurality of suppliers of man-machine interface applications for different commercial avionics systems. This entirely partitioned architecture enables the implementation of an incremental certification. In other words, it is possible to update one core without impacting on the others.
<figref idref="DRAWINGS">FIG. 3</figref> shows that the central processing unit CPU and the graphics processing unit GPU each include a group of data processing cores C<b>1</b>-C<b>6</b> and C′ <b>1</b>-C′<b>6</b> respectively, in this case six in number, interconnected via dedicated buses B<b>1</b>-B<b>6</b> or, in a general manner, via a dedicated data transfer device.
The problems of arbitration and non-guaranteed data transfer time no longer arise in this architecture, the data being transported between the processing cores on non-shared buses.
As can be seen, the data processing cores of the central processing unit are organized on the same model and are based on the use of one processing core, such as <b>8</b>. Each processing core comprises an internal communication bus <b>9</b> or, in a general manner, a data transfer device, which performs the communication within the core between the various components which make it up and with local peripheral devices.
Each processing core in fact includes different types of memory with, inter alia, a permanent memory <b>10</b>, for example a Flash memory, and a random access memory <b>11</b>, for example a DDR memory, associated with a permanent memory controller <b>12</b> and a random access memory controller <b>13</b>. Obviously, equipping the processing cores with other types of local peripheral devices, notably other types of memory, does not exceed the scope of the invention. As will be described with reference to <figref idref="DRAWINGS">FIG. 4</figref>, each processing core also includes a certain number of local data input and output peripherals which may differ from one core to the other.
Communication peripherals <b>14</b> perform the communication between the dedicated buses B<b>1</b>-B<b>6</b> and the associated internal communication bus <b>9</b>.
Alongside the local peripherals and memories <b>10</b> and <b>11</b> dedicated to each processing core, the central processing unit CPU furthermore includes global memories and peripherals shared among the cores. This concerns, in particular, the memories <b>15</b>, <b>16</b> and <b>17</b> associated with their respective memory controllers <b>18</b>, <b>19</b> and <b>20</b>. By way of illustration, but in a non-limiting manner, this concerns Flash memories, DDRs or global shared peripherals <b>21</b>, <b>22</b> and <b>23</b>, for example ARINC <b>429</b> or ARINC <b>825</b>. In the proposed application, which relates to graphical interfaces for cockpit equipment for aircraft, memories of this type may, for example, be used for recording information relating to a flight.
A global internal bus <b>24</b> or, in a general manner, a data transfer element, performs the exchange of data between the data processing cores C<b>1</b>-C<b>6</b>, with the memories <b>15</b>, <b>16</b> and <b>17</b> and with the global peripheral devices <b>21</b>, <b>22</b> et <b>23</b>.
The data processing cores C′ <b>1</b>-C′<b>6</b> of the graphics processing unit have a similar structure and are based on the use of a processing core such as <b>25</b>. This processing core <b>25</b> communicates with an internal communication bus <b>26</b> or, in a general manner, with a data transfer means, which is connected via communication links <b>27</b> and <b>28</b> to the dedicated buses B<b>1</b>-B<b>6</b>.
Alongside the processing core <b>25</b>, each data processing core C′ <b>1</b>-C′<b>6</b> furthermore incorporates a GPU graphics processing core <b>29</b> connected to the internal bus <b>26</b>. Finally, a local bus <b>30</b> or a data transfer means, which communicates with the communication links <b>27</b> and <b>28</b>, with the processing core <b>25</b> and with the GPU processing core <b>29</b>, is connected to an external local memory <b>31</b> associated with a corresponding controller <b>32</b>.
Furthermore, the graphics processing unit GPU comprises a mixer <b>33</b> connected to the local bus <b>30</b> of each data processing unit C′ <b>1</b>-C′<b>6</b>.
In fact, each CPU/GPU pair performs a task which is allocated to it and generates a portion of the final image. The mixer <b>33</b> combines these various images to produce the final screen displayed on the man-machine interface. Optionally, the processing system that has just been described may be equipped with a video input <b>34</b>, an external memory <b>35</b> associated with a corresponding controller <b>36</b> and with an arbitration system <b>37</b> for accessing external shared data. An image retrieval device <b>38</b> associated with a flow manager <b>39</b> combines videos or images retrieved from the input <b>34</b> or the memory <b>35</b> in order to generate the final image.
As will be understood, the architecture that has just been described can be likened to a multiprocessor architecture integrated onto one and the same chip. In fact, since each core is independent and has its own dedicated memory controllers and peripherals, the architecture is similar to a multi-SoC architecture.
With reference to <figref idref="DRAWINGS">FIG. 4</figref>, which shows a strategy for installing an operating system in a data processing system, it can be seen that each processing core, denoted C″<b>1</b>, C″<b>2</b> or C″<b>3</b>, incorporates a certain number of Input/Output interfaces <b>42</b>, <b>43</b>, <b>44</b> which communicate with a core “core#<b>1</b>”, “core#<b>2</b>” or “core#<b>3</b>” via a local bus B, while other Input/Output interfaces <b>45</b> are shared among the processing cores with which they communicate via an interface bus B′. This strategy may apply equally to both the central processing unit and the graphics processing unit. In other words, two Input/Output interface levels are provided, the architecture integrating not only local Input/Output interfaces dedicated to a core, but also global Input/Output interfaces which are shared among the cores.
It will be understood that the direct-access local I/O interfaces, without sharing and without arbitration, enable faster access to local peripherals dedicated to one core, whereas the global I/O interfaces enable access to shared peripheral devices.
It will moreover be noted that, in one implementation, the processing cores of the GPU and of the CPU can incorporate a dedicated operating system.
The deterministic access to the shared resources makes the use of a controlled shared access bus <b>24</b> (<figref idref="DRAWINGS">FIG. 5</figref>) desirable.
The bus <b>24</b> is thus associated with arbitration means serving to arbitrate the data exchanges with the shared devices or, in other words, to arbitrate access by the cores to the shared resources. By way of example, these arbitrations may take the form of a scheduler, for example integrated into the bus, periodically allocating communication times for each core in succession.
Finally, referring to <figref idref="DRAWINGS">FIG. 5A</figref> and <figref idref="DRAWINGS">FIG. 5B</figref>, it is conceivable for, contrary to the conventional CPU/GPU architectures which use a single shared communication bus <b>46</b>, the data processing system according to the embodiments described herein to be based on an independent dedicated bus <b>47</b> between each CPU core and its associated GPU core. These separate buses thus allow parallel and efficient data transfers.
Further modifications and alternative embodiments of various aspects of the invention will be apparent to those skilled in the art in view of this description. Accordingly, this description is to be construed as illustrative only and is for the purpose of teaching those skilled in the art the general manner of carrying out the invention. It is to be understood that the forms of the invention shown and described herein are to be taken as examples of embodiments. Elements and materials may be substituted for those illustrated and described herein, parts and processes may be reversed, and certain features of the invention may be utilized independently, all as would be apparent to one skilled in the art after having the benefit of this description of the invention. Changes may be made in the elements described herein without departing from the spirit and scope of the invention as described in the following claims.
Contents5
5 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US2011208997A1 | Cites | United States of America | Search report |
| US2012269091A1 | Cites | United States of America | Search report |
| US2014201472A1 | Cites | United States of America | Search report |
| US2015149713A1 | Cites | United States of America | Search report |
| US2015178879A1 | Cites | United States of America | Search report |
| US6195593B1 | Cites | United States of America | Search report |
| US6456628B1 | Cites | United States of America | Search report |
| US6823472B1 | Cites | United States of America | Search report |
| US7324438B1 | Cites | United States of America | Search report |
| US20110208997A1 | Cites | United States of America | Search report |
| US20120269091A1 | Cites | United States of America | Search report |
| US20140201472A1 | Cites | United States of America | Search report |
| US20150149713A1 | Cites | United States of America | Search report |
| US20150178879A1 | Cites | United States of America | Search report |
14 members in 4 offices
Priority claims11
| Document | Office | Kind | Date |
|---|---|---|---|
| 201461976078 | United States of America | P | |
| 201461976078 | United States of America | P | |
| 1457008 | France | – | |
| 1457008 | France | A | |
| 1457008 | France | A | |
| 201514680443 | United States of America | A | |
| 1457008 | – | – | – |
| 61976078 | – | – | – |
| FR20140057008 | – | – | – |
| US201461976078P | – | – | – |
| US201514680443 | – | – | – |
Members14
| Document | Office | Kind | |
|---|---|---|---|
| CA2886466A1 | Canada | A1 | |
| CA2887077A1 | Canada | A1 | |
| DE102015104872A1 | Germany | A1 | |
| DE102015105153A1 | Germany | A1 | |
| US2015286589A1 | United States of America | A1 | |
| US2015287157A1 | United States of America | A1 | |
| FR3019667A1 | France | A1 | |
| FR3019668A1 | France | A1 | |
| FR3019668B1 | France | B1 | |
| FR3019667B1 | France | B1 | |
| US10509737B2 | United States of America | B2 | |
| US10762005B2This record | United States of America | B2 | |
| CA2886466C | Canada | C | |
| CA2887077C | Canada | C |
103 transactions on the USPTO file
Allowed after 3 non-final rejections, 3 final rejections and 2 RCEs.
- Non-final rejections
- 3
- Final rejections
- 3
- RCEs
- 2
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Payment of Maintenance Fee, 4th Year, Large EntityM1551 | M1551 | |
| Post Issue Communication - Certificate of CorrectionN423 | N423 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Printer Rush- No mailingTCPB | TCPB | |
| Printer Rush- No mailingTCPB | TCPB | |
| Pubs Case Remand to TCPUBTC | PUBTC | |
| Receipt into PubsR1021 | R1021 | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Reasons for AllowanceEX.R | EX.R | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Final ActionA.NE | A.NE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Applicant Initiated Interview SummaryMEXIA | MEXIA | |
| Interview Summary - Applicant Initiated - TelephonicEXAT | EXAT | |
| Interview Summary- Applicant InitiatedEXIA | EXIA | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Electronic request for Examiner InterviewM865E | M865E | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Advisory Action (PTOL - 303)MCTAV | MCTAV | |
| Advisory Action (PTOL-303)CTAV | CTAV | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Final ActionA.NE | A.NE | |
| PILOT- Request for After Final Consideration ProgramRAFC | RAFC | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Email NotificationEML_NTR | EML_NTR | |
| Application ready for PDX access by participating foreign officesCCRDY | CCRDY | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Request for Foreign Priority (Priority Papers May Be Included)RQPR | RQPR | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Email NotificationEML_NTR | EML_NTR | |
| Application Is Now CompleteCOMP | COMP | |
| Filing Receipt - UpdatedFLRCPT.U | FLRCPT.U | |
| Sent to Classification ContractorPGPC | PGPC | |
| FITF set to YES - revise initial settingFTFS | FTFS | |
| Oath or Declaration Filed (Including Supplemental)C602 | C602 | |
| Oath or Declaration Filed (Including Supplemental)C602 | C602 | |
| Patent Term Adjustment - Ready for ExaminationPTA.RFE | PTA.RFE | |
| Payment of additional filing fee/PreexamFLFEE | FLFEE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Email NotificationEML_NTR | EML_NTR | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Notice Mailed--Application Incomplete--Filing Date AssignedINCD | INCD | |
| Cleared by L&R (LARS)L128 | L128 | |
| Referred to Level 2 (LARS) by OIPE CSRL198 | L198 | |
| Applicants have given acceptable permission for participating foreignAPPERMS | APPERMS |
21 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Certificate of correctionCC | CC | |
| Certificate of correctionCC | CC | |
| Information on status: patent grantGrantedSTCF | STCF | |
| Information on status: patent grantGrantedSTCF | STCF | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| Information on status: patent application and granting procedure in generalSTPP | STPP | |
| AssignmentAS | AS |
Numbers
- Publication
- 10762005
- Publication, DOCDB
- 10762005
- Publication, EPODOC
- US10762005
- Application
- 14680443
- Application, DOCDB
- 201514680443
- Application, EPODOC
- US201514680443
Titles
- English
- Multicore data processing system with local and global input/output devices and graphical interface comprising such a data processing system
Patent term adjustment
- A delay
- +345 daysthe office missed an examination deadline
- B delay
- +117 dayspendency past three years
- Applicant delay
- −124 days
- Net adjustment
- 338 days
Classification
- CPC, 5
- G06F13/124
- G06F13/4068
- G06T1/20
- G06F15/17337
- G06T2210/52
- IPC, 3
- G06T1 20
- G06F13 12
- G06F13 40
- USPC, 1
- 700121000