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 .
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in France on 8/3/2023. It is noted, however, that applicant has not filed a certified copy of the FR 2308428 application as required by 37 CFR 1.55.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, and 4 – 13 are rejected under 35 U.S.C. 103 as being unpatentable over Sanderson et al. US Patent Application Publication No. 2021/0081251 (herein after referred to as Sanderson) in view of Pop et al. US Application Publication No. 2010/0070730 (herein after referred to as Pop), Brief US Patent No. 8286188 (herein after referred to as Brief), and Sykes et al. US Patent Application Publication No. 2016/0080491 (herein after referred to as Sykes).
Regarding claim 1, Sanderson describes a platform for executing avionics applications (…the avionics platform 10 includes a memory 12, an operating system 20, a processor 21, a set 19 of input/output peripherals and an electronic control device 24 (page 2, paragraph [0047])), comprising: a multi-core processor (The processor 21… is a multicore processor… (page 3, paragraph [0055])); a management unit (…an electronic control device 24 (page 2, paragraph [0047]). The electronic control device 24 for example includes a memory 26… and an electronic control unit 25 (page 3, paragraph [0059])); a plurality of shared resources (…the avionics platform 10 includes… a set 19 of input and/or output peripherals… (page 2, paragraph [0047]). According to the invention, the partitions PARTAPP1 and PARTAPP2 are defined such that these access commands to the IO peripherals are sent to the partition for access to the IO peripherals PARTSERV_IO (page 3, paragraph [0063])); and a memory comprising (…a memory 12 (page 2, paragraph [0047])): a plurality of avionics partitions executing a plurality of avionics applications by said multi-core processor (The memory 12 stores a plurality of partitions 14. These partitions 14 include the partitions PARTAPPi, with i=1 to m, m being an integer greater than or equal to 2, which are software applications also called avionics functions… (page 2, paragraphs [0049] – [0050]). The electronic control unit 25 of the electronic control device 24 is suitable for sequencing the execution of the partitions on the processor 21… (page 3, paragraph [0060])); an input/output (IO) server for access to shared resources by said avionics partitions (According to the invention, the partitions further include a specific partition PARTSERV_IO 14, called partition for access to the IO peripherals. This partition PARTSERV_IO 14 is suitable for centralizing the exchanges with the IO peripherals 18 (page 2, paragraph [0051])); and a shared memory space, access of which is controlled by said management unit (The allocations are determined by said control unit 25. The predetermined times are in particular calculated based on a time allocation budgeted for each partition during the installation thereof on the platform 1, according to targeted performance objectives (page 3, paragraph [0062]). The exchanges between the partition PARTSERV_IO for access to the IO resources and the avionics partitions PARTAPP1 and PARTAPP2, comprising the transmission of these commands, then the provision of the result of the implementation of these commands, are done via a memory, for example of the nondedicated volatile RAM type, referenced 15 in Fig. 1, in which the avionics partitions PARTAPP1 and PARTAPP2 write the access commands to the IO peripherals, in which the partition PARTSERV_IO reads these commands, then writes the result therein of the performance of these commands following the reading/writing in the IO peripherals indicated in the commands and lastly in which the avionics partitions PARTAPP1 and PARTAPP2 extract the result of their commands for access of the IO peripherals (page 3, paragraph [0070])). In one embodiment, the commands and results of commands assume the form of messages, based on the programming interface (API) of standard A653: the applications PARTAPP1 and PARTAPP2 acquire messages previously read by the partition PARTSERV_IO and push messages toward the partition PARTSERV_IO for the physical sending of these messages toward IO1 or IO2 during its next time allocation (page 3, paragraph [0071]). A budget in terms of the use of the memory and a budget in terms of usage time of the processor (based on which the predetermined time will be set indicated in each allocation of the allocation list 27)… (page 3, paragraph [0072])), the shared memory space performing data sharing between a data producing partition and a predetermined group of N data consuming partitions exclusively via a data sharing structure outside the data producing and data consuming partitions, allocated in the shared memory space (In one embodiment, the commands and results of commands assume the form of messages, based on the programming interface (API) of standard A653: the applications PARTAPP1 and PARTAPP2 acquire messages previously read by the partition PARTSERV_IO and push messages toward the partition PARTSERV_IO for the physical sending of these messages toward IO1 or IO2 during its next time allocation (page 3, paragraph [0071]). …The electronic control unit 25 of the electronic control device 24 is suitable for sequencing the execution of the partitions on the processor 21 based on a sequential list of allocations 27 stored for example in the memory 26 (page 3, paragraph [0060]). …During this time t2, each partition PARTAPPi, i=1, 2 writes, in the RAM 15, its commands for access to the peripherals IO1, IO2 18 (in the form of messages to be emitted in the API case of standard A653) and extracts, from the RAM, the access command results previously deposited in the RAM (in the form of acquired messages in the API case of standard A653) by the partition PARTSERV_IO 14 (page 4, paragraph [0081]). Fig. 1 shows RAM 15 being outside and separate from the producing/consuming partitions PARTAPP1 14, PARTAPP2 14, and PARTSERV_IO 14), the data producing partition and each data consuming partition corresponding to said IO server or to one of said avionics partitions, the data sharing structure comprising at least two saving addresses which are used by the data producing partition to write two different data (…During this time t2, each partition PARTAPPi, i=1, 2 writes, in the RAM 15, its commands for access to the peripherals IO1, IO2 18 (in the form of messages to be emitted in the API case of standard A653) and extracts, from the RAM, the access command results previously deposited in the RAM (in the form of acquired messages in the API case of standard A653) by the partition PARTSERV_IO 14 (page 4, paragraph [0081]). In the case that each of the two partitions are depositing messages in the memory RAM 15 they must be written to two different memory locations in order to be read out successfully). Sanderson does not specifically disclose the guarantee that the shared memory space is shared in accordance with read and write permissions for each partition at any given address, the data sharing structure consisting of N+2 saving addresses, nor being enabling concurrent read and write whereby said IO sever writes a following datum at an address while said avionics partitions read a preceding datum at another address.
Pop describes a system for minimizing memory access conflicts of process communication channels. Specifically, the reference presents examples of synchronization that are used to ensure a producer and consumer do not concurrently access the same memory location. A producer may correspond to a processor core, such as processor core 112a in Fig. 1, supplying data, such as in an array, while executing a task or a thread. A consumer may correspond to a processor core, such as processor core 112b in Fig. 1, retrieving data, such as in an array, while executing a parallel task or a parallel thread. For example, referring to Fig. 3A, one embodiment of a source code pattern with regular data dependences within an array is shown. Automatic parallelization techniques based on data dependence analysis information (page 3, paragraph [0034]). While processor core 112b is executing a producer task, producing data for stream copies 440 and 460, and filling data copy 414b to be subsequently sent to producer sliding windows 444 and 464, processor core 112a may be concurrently executing a consumer task, reading data from stream copy 440, and reading from data copy 414a which was previously read from consumer sliding window 442. Consumer sliding window 442, and correspondingly 462, may be full and designated for reading data by core 112a. In fact, a snapshot in the middle of code execution may show core 112a is reading data for the loop of lines 9-11, which is presently stored in filled space 446. The pointers within stream 440 may have been updated and core 112a is now allowed to begin reading consumer sliding window 442 which has new data. More up-to-date copies of consumer sliding window 442 may be found in the cache hierarchy, such as data copies 418a and 414a. The size of the consumer sliding window may be the same size as the producer sliding window for ease of implementation sake. Alternatively, when core 112a has permission to read from a window due to no overlap of the producer and consumer sliding windows, rather than read data from stream copy 440, core 112a may send a communicative probe to locate required data. If a copy of the required updated data is in cache 416b or 412b of processing unit 420b, then a copy of the required data may be sent from processing unit 420b to cache 412a (page 4, paragraph [0047]). The embodiment shown in FIG. 4 is for illustrative purposes only. In other embodiments, more than two processing units 420 may be included in a system and more than one stream 440 may be concurrently implemented in shared cache memory 440 and main memory 450. In the above example, the producer sliding window 444 and consumer sliding window 442 are shown moving from left to right, but in other embodiments, they may move from right to left. Also, the producer sliding window 444 may wrap around stream 440 during execution and, in a snapshot, be located to the left of consumer sliding window 442. Also, for a multi-core processor implementation, a stream 440 may correspond to a single processor and to a single processing unit 420, wherein a producer sliding window 444 corresponds to a first core within a multi-core processor and consumer sliding window 442 corresponds to a second core within the same multi-core processor. Other combinations and embodiments are possible and contemplated (page 4, paragraph [0049]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Pop teachings in the Sanderson system. Skilled artisan would have been motivated to incorporate the method of sliding windows for consumers and producers as taught by Pop in the Sanderson system for effectively managing access to shared memory space without explicit locking. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as multi-core systems with shared memory. This close relation between both of the references highly suggests an expectation of success.
Brief discloses a method for advanced interprocess communication. Specifically, the described interprocess memory controller may maintain a set of permissions for each buffer allocated from shared memory by the respective processes in a multi-process device. For example, when a process allocates a buffer from the shared memory, the described interprocess memory controller may allocate permission to write to, and to free, the allocated buffer to the allocating process. Such allocated permissions may be stored by the described interprocess memory controller, in association with the allocated buffer, in physical memory. When a pointer to a buffer is passed, or transferred, from a first process, i.e., the sending process, to a second process, i.e., the receiving process, as part of an interprocess communication, the described interprocess memory controller may reallocate permission to write to, and to free, the allocated buffer to the receiving process by updating the buffer's permission data stored in physical memory. In this manner, the efficiency of interprocess communication is greatly increased and the integrity of the shared memory is maintained (column 3, lines 1 – 19).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Brief teachings in the Sanderson in view of Pop system. Skilled artisan would have been motivated to incorporate the method of including an interprocess memory controller configured to maintain a set of permissions as taught by Brief in the Sanderson in view of Pop system for effectively managing permissions to shared memory in a way that the efficiency of interprocess communication is greatly increased and the integrity of the shared memory is maintained (column 3, lines 16 – 19). In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as multi-core systems with shared memory. This close relation between both of the references highly suggests an expectation of success.
Sykes describes a method for accessing data in a shared memory by at least one client. Specifically, in one embodiment, a mechanism for accessing data in a shared memory by at least one client, the mechanism including an allocation of data in the shared memory into at least one topic, the allocation being accessible by a predetermined constant address, the at least one topic having a number of buffers, the number of buffers being equal to a number of clients accessing the at least one topic, plus two for each server accessing the at least one topic, each client and each server having an active access pointer, and an active access pointer director to direct active access pointers to buffers based on a transaction request from a client or a server. One buffer always includes the most recent data in the shared memory, and at least one buffer is always available to access data in the shared memory. Additionally, the active access pointers are allocated among buffers by the active access pointer director using only machine assembly language transactions without copying the data at an operating system level (page 1, paragraph [0003]). A first client 54 and second client 56 are associated with, respectively a first buffer 58 and a second buffer 60. Accordingly, the first and second buffers 58, 60 have been identified as occupied buffers 44. A third client 62 is shown unassociated with the topic 32, as is the server 50. While each of the active access pointers 42, 52 are shown as part of the clients 40 or servers 50, respectively, embodiments of the invention may include active access pointers 42, 52 as part of the topic 32 and/or buffers 36 (page 2, paragraph [0021]). In one embodiment, the number of buffers 36 in each topic 32, and the size of the each buffer 36 are predefined during the initialization of the shared memory 22, based on a known number of clients 40 and/or servers 50 capable of accessing the topic 32. In another embodiment, the number of buffers 36, in each topic 32, is defined at or during runtime by the collective number of clients 40 and servers 50, then accessing the topic 32. In any of the described embodiments, the total number of buffers 36 may be equal to the number of clients 40 accessing the topic 32, plus two buffers 36 for each server 50 accessing the topic 32 (page 2, paragraph [0022]). Turning now to FIG. 3, a mechanism for accessing data in the topic 32 and/or buffer 36 of the shared memory 22 is described. A third client 62 is communicatively coupled with the topic 32, and communicates with the active access pointer director 38 of the topic (illustrated as dotted-line communication 64) to request a transaction with the data. The active access pointer director 38 responds to the third client 62, identifying a third buffer 66 which includes the most recent data 48 of the topic 32. The third client 62, now directed to the third buffer 66, instructs its active access pointer 42 to the third buffer 66 (illustrated as a second communication 68). At this stage, the third client 62 accesses the data stored in the third buffer 66 (the most recent data 48), and performs the intended transaction on the data (page 2, paragraph [0023]). In the description of Figure 3, there are 3 clients [N] and 1 server. The number of buffers can therefore be represented as N + 2.
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Sykes teachings in the Sanderson in view of Pop and Brief system. Skilled artisan would have been motivated to use a number of accessible locations equal to the number of clients plus two for each server as taught by Sykes in the Sanderson in view of Pop and Brief system for effectively providing shared access to data with a specific number of buffers. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as shared memory management in an aviation system. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 4, Sanderson in view of Pop, Brief, and Sykes describe the platform according to claim 1 (see above), wherein the data sharing structure further comprises at least one metadatum for determining a data saving address to be used by the or each data producing/consuming partition (Sanderson clearly discloses that the partitions write messages into RAM. In order to write data into memory it is necessarily inherent that some form of addressing is used).
Regarding claim 5, Sanderson in view of Pop, Brief, and Sykes describe the platform according to claim 1 (see above), wherein the data sharing structure has a structure of a first type when N is strictly greater than 1, wherein the data producing partition corresponds to said IO server and each data consuming partition corresponds to one of said avionics partitions, and wherein the structure of the first type comprises N+2 saving addresses(Sanderson, page 3, paragraph [0070]) (Sykes, page 2, paragraphs [0022] and [0023]).
Regarding claim 6, Sanderson in view of in view of Pop, Brief, and Sykes describe the platform according to claim 5 (see above), wherein among the N+2 saving addresses of the structure of the first type, two addresses are dedicated to the writing by the data producing partition of a preceding datum and a following datum, and N other addresses are dedicated to the reading by each of the N data consuming partitions of the predetermined group, of the preceding datum (Sykes, page 2, paragraphs [0022] and [0023]).
Regarding claim 7, Sanderson in view of Pop, Brief, and Sykes describe the platform according to claim 5 (see above), wherein said shared memory space comprises a structure of the first type for each group of N avionics partitions sharing the data produced by said IO server (Sykes, page 2, paragraphs [0022] and [0023]) (Sanderson, page 3, paragraph [0070]).
Regarding claim 8, Sanderson in view of Pop, Brief, and Sykes describe the platform according to claim 5 (see above), wherein the data sharing structure has a structure of a second type when N equals 1, the data producing partition corresponding to said IO server and the data consuming partition corresponding to a single avionics partition, wherein the at least two saving addresses form a queue for reading/writing a preceding datum and a following datum (Sykes, page 2, paragraphs [0022] and [0023]) (Sanderson, page 3, paragraph [0070]).
Regarding claim 9, Sanderson in view of Pop, Brief, and Sykes describe the platform according to claim 5 (see above), wherein the data sharing structure has a structure of a third type when N is equal to 1, the producer partition corresponding to a single avionics partition and the consumer partition corresponding to said IO server, and wherein the at least two saving addresses form a queue for reading/writing a preceding datum and a following datum (Sykes, page 2, paragraphs [0022] and [0023]) (Sanderson, page 3, paragraph [0070]).
Regarding claim 10, Sanderson in view of Pop, Brief, and Sykes describe the platform according to claim 5 (see above), wherein said shared memory space comprises a plurality of data sharing structures, each data sharing structure corresponding to a structure of the first type, a structure of a second type, or a structure of a third type (Sykes, page 2, paragraphs [0022] and [0023]) (Sanderson, page 3, paragraph [0070]).
Regarding claim 11, Sanderson in view of Pop, Brief, and Sykes describe the platform according to claim 5 (see above), wherein said shared memory space comprises: a plurality of data sharing structures, each data sharing structure corresponding to a structure of the first type, a structure of a second type or a structure of a third type; and a structure of the second type and/or a structure of the third type for each of said avionics partitions, wherein the data sharing structure has a structure of the second type when N equals 1, wherein the data producing partition corresponds to said IO server, wherein the data consuming partition corresponds to a single one of said avionics partitions, and wherein the at least two saving addresses form a queue for reading/writing a preceding datum and a following datum (Sykes, page 2, paragraphs [0022] and [0023]) (Sanderson, page 3, paragraph [0070]).
Regarding claim 12, Sanderson in view of Pop, Brief, and Sykes describe a method for executing avionics applications, implemented by the platform according to claim 1 (see above), the method comprising writing two different data into two saving addresses of the or each data sharing structure, by the data producing partition (…During this time t2, each partition PARTAPPi, i=1, 2 writes, in the RAM 15, its commands for access to the peripherals IO1, IO2 18 (in the form of messages to be emitted in the API case of standard A653) and extracts, from the RAM, the access command results previously deposited in the RAM (in the form of acquired messages in the API case of standard A653) by the partition PARTSERV_IO 14 (Sanderson, page 4, paragraph [0081]). The act of writing data to a location may be interpreted as “producing” since stored data is produced from the perspective of the memory).
Regarding claim 13, Sanderson in view of Pop, Brief, and Sykes describe a non-transient computer-readable medium comprising instructions which, when executed by a programmable electronic system cause the programmable electronic system to, implement a method according to claim 12 (…software instructions of the compute program stored in a memory (Sanderson, page 5, paragraph [0095])).
Claims 2 – 3 are rejected under 35 U.S.C. 103 as being unpatentable over Sanderson in view of Pop, Brief, and Sykes, further in view of Polley et al. US Patent No. 11048548 (herein after referred to as Polley).
Regarding claim 2, Sanderson in view of Pop, Brief, and Sykes describe the platform according to claim 1 (see above), wherein said shared memory space comprises for each of said avionics partitions, a second shared memory zone (The exchanges between the partition PARTSERV_IO for access to the IO resources and the avionics partitions PARTAPP1 and PARTAPP2, comprising the transmission of these commands, then the provision of the result of the implementation of these commands, are done via a memory, for example of the nondedicated volatile RAM type, referenced 15 in Fig. 1, in which the avionics partitions PARTAPP1 and PARTAPP2 write the access commands to the IO peripherals, in which the partition PARTSERV_IO reads these commands, then write the result therein of the performance of these commands following the reading/writing in the IO peripherals indicated in the commands and lastly in which the avionics partitions PARTAPP1 and PARTAPP2 extract the result of their commands for access to the IO peripherals (Sanderson, page 3, paragraph [0070])) and each second shared memory zone being read/write accessible to the corresponding avionics partition (Sanderson, page 3, paragraph [0070]), wherein said management unit makes the different avionics partitions follow the reading/writing in the different zones. Sanderson does not specifically disclose first shared memory zone, wherein the first shared memory zone being read-only accessible to all of said avionics partitions.
Polley describes a multi-core processing environment capable of quantifying shared system resources access includes several processing cores, each core having several applications running thereon and accessing SSRs via virtual machines. Specifically, it is disclosed that each processing core may incorporate one or more guest operating systems 118 and user applications (e.g., avionics applications) executing thereon. Shared system resources may include but are not limited to, system memory, flash memory, non-volatile memory, or types of read-only memory (ROM) (column 4, lines 26 – 55).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Polley teachings in the Sanderson in view of Pop, Brief, and Sykes system. Skilled artisan would have been motivated to incorporate the method of using read-only memory in an avionics system as taught by Polley in the Sanderson in view of Pop, Brief, and Sykes system for effectively providing a conventional memory type (read-only). In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as multi-core avionics systems. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 3, Sanderson in view of Pop, Brief, Sykes, and Polley describe the platform according to claim 2 (see above) wherein the data sharing structure is distributed between the zones according to the need thereof to write/read corresponding data (Sanderson, page 3, paragraph [0070]).
Response to Arguments
Applicant argues, with respect to claim 1, that Sanderson in view of Pop and Brief do not teach or suggest the amended limitations. Examiner has clarified the rejection by adding Sykes, which is more specific about the number of entries, as explained in the amended rejection above.
Applicant argues, with respect to the remaining claims, that they depend from claim 1 and are therefore allowable for the same reasons argued. Examiner refers to rejections and responses above as to why these claims are not currently allowable.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RALPH A VERDERAMO III whose telephone number is (571)270-1174. The examiner can normally be reached Monday through Friday 8:30 AM - 5:00 PM.
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, Reginald Bragdon can be reached at (571) 272-4204. 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.
/RALPH A VERDERAMO III/Examiner, Art Unit 2139
/REGINALD G BRAGDON/Supervisory Patent Examiner, Art Unit 2139
rv
October 8, 2026
