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 .
Remarks
This action is in response to the application received on 4/4/25. Claims 1-20 are pending in the application.
Claims 1-20 are rejected under 35 U.S.C. 101.
Claims 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over Harvey et al. (US 2006/0190575), and further in view of Huber et al. (US 2015/0082975).
Claims 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Harvey in view of Huber, and further in view of Khan et al. (US 2024/0112134).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Harvey in view of Harvey et al. (US 2006/0190575), and further in view of Huber et al. (US 2015/0082975) and Khan et al. (US 2024/0112134).
Claim Interpretation
Claims 1-20 include language that is directed towards contingent limitations. The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met.
For example, in claim 1, “creating an output XML file containing a first element based on the template file” only occurs “when the value of the bus message type is equal to the value of the transmission user identification attribute.” If “the value of the bus message type” does not equal “the value of the transmission user identification attribute”, the creation of “an output XML file containing a first element based on the template file” is not required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 2A, Prong One asks: Is the claim directed to a law of nature, a natural phenomenon (product of nature) or an abstract idea? See MPEP 2106.04 Part I. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. See MPEP 2106.04(a).
With respect to claims 1 and 15, the limitation of “defining an event element”, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, nothing in the claim element precludes the step from practically being performed in the mind. For example, “defining” in the context of this claim encompasses the user thinking of data. Similarly, the limitation of “identifying a message on a shared bus” and “determining a bus message type of the message”, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. For example, “identifying” and “determining” in the context of this claim encompasses the user observing data.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
At step 2a, prong two, this judicial exception is not integrated into a practical application. The claim recites “creating a template file” and “creating an output XML file.” These elements do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception and provide only insignificant extra solution activity that is mere data gathering in conjunction with the abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
With respect to “creating a template file” and “creating an output XML file”, the courts have found limitations directed towards storing to be well-understood, routine, and conventional. See MPEP 2106.05(d)(II). Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts") and “storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
Considering the additional elements individually and in combination and the claim as a whole, the additional elements do not provide significantly more than the abstract idea. The claim is not patent eligible.
With respect to claims 2, 3, and 16, the limitations are directed towards creating files and elements. These elements do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception and provide only insignificant extra solution activity in conjunction with the abstract idea. The courts have found limitations directed towards storing to be well-understood, routine, and conventional. See MPEP 2106.05(d)(II). Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts") and “storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
With respect to claims 4-14 and 17-19, the limitations further define the event element data and do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
With respect to claim 20, the limitations are essentially the same as claims 1-19, and are rejected for the same reasons.
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-12 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Harvey et al. (US 2006/0190575), and further in view of Huber et al. (US 2015/0082975).
With respect to claim 1, Harvey teaches a method for creating a standardized XML format comprising the steps of:
defining an event element (Harvey, pa 0041, Configuration templates 210 each comprise a set of stored data that defines a configuration of a network device in terms of one or more CLI commands and zero or more modifiable parameters.);
creating a template file having the event element (Harvey, pa 0030, The administrator/planner creates one or more common configuration templates);
identifying a message on a shared bus (Harvey, pa 0033, The order entry system 104 receives one or more orders and can communicate over an event service 120 with a workflow manager 106. & pa 0035, Event Service 120 is implemented in the form of The Information Bus software, which is commercially available from TIBCO Software, Inc. Event Gateway 118 provides as an interface that permits network devices 114 to communicate with Event Service 120.);
determining a bus message type of the message (Harvey, pa 0054, When the device 114 is powered-up at customer premises 112, the device connects to Configuration Server 116 by establishing a TCP/IP connection. The device issues an HTTP get request to Web server 206 of Configuration Server 116. To uniquely identify itself to the Configuration Server 116 and to the Web server, the device 114 provides its token as a unique identifier.); and
creating an output XML file containing a first element based on the template file when the value of the bus message type is equal to the value of the transmission user identification attribute (Harvey, pa 0055, In response, based on the device's unique identifier, configuration Server 116 retrieves one of the configuration templates 210 that is associated with the device 114. … As a result, a stream or file of XML format configuration information is created and potentially stored.).
Harvey doesn't expressly discuss defining an event element wherein the event element comprises: an event user identification attribute having a value; a transmission element, wherein the transmission element further comprises: a transmission user identification attribute having a value, a transmission type attribute having a value, a transmission name attribute having a value, a transmission type count attribute having a value, and a transfer element, wherein the transfer element further comprises: a transfer type attribute having a value, a transfer receiver attribute having a value, and a transfer sender attribute having a value.
Huber teaches defining an event element (Huber, pa 0042, The aircraft can use the MIL-STD-1760 mass data transfer (MDT) protocol to download MDT files to the store over the MIL-STD-1553 or EBR-1553 interface. The MDT protocol can define how the data is physically transferred to an aircraft store by breaking up a file into discrete 13R messages. & pa 0051, The GSE computer application software can implement the MIL-STD-1553 messaging protocol and MIL-STD-1760 mass data transfer (MDT) protocol as the messaging and MDT protocols apply to a MIL-STD-1553 bus controller.) wherein the event element comprises: an event user identification attribute having a value; a transmission element, wherein the transmission element further comprises: a transmission user identification attribute having a value, a transmission type attribute having a value, a transmission name attribute having a value, a transmission type count attribute having a value (Huber, Fig. 7, pa 0010, FIG. 7 illustrates a diagram of a mission data exchange format (MiDEF) module including three submodules in accordance with an example & pa 0045, The Universal Armament Interface (UAI) mission files have a dynamic structure in a Mission Data Exchange Format (MiDEF), as defined by MIL-STD-3014. MiDEF is a structure used by the UAL The architecture of a MiDEF file can be hierarchical or "nested" and dynamic. Each MiDEF file can include at least one module. A module can include a header that can include a table of contents and module data, which can include one or more sub-modules 460, 462, and 464 and/or primitive data elements, as illustrated by FIG. 7.… The defined module types and primitive data elements can be defined by MIL STD-3014. The size of a MiDEF file can be variable as the size can depend upon which elements are included in the modules and sub-modules & pa 0051, the GSE computer application software can combine the individual binary MiDEF files created by the mission planning application into a single "super-MiDEF" file), and a transfer element, wherein the transfer element further comprises: a transfer type attribute having a value, a transfer receiver attribute having a value, and a transfer sender attribute having a value (Huber, Fig. 4 & pa 0039, In the controller to RT transfer, the bus controller sends one 16-bit receive command word, immediately followed by 1 to 32 16-bit data words. … In the RT to controller transfer, the bus controller sends one transmit command word to a remote terminal.);
identifying a message on a shared bus (Huber, pa 0031, The MIL-STD-1553 bus controller (BC) can be a terminal that initiates information transfers on the data bus. & pa 0040, FIG. 4 illustrates the basic formats of three basic types of MIL-STD-1553 information transfers including bus controller to remote terminal transfers (BC-to-RT), remote terminal to bus controller transfers (RT-to-BC), and remote terminal to remote terminal (RT-to-RT) transfers…The MIL-STD-1553 information transfers can be related to the data flow and can be referred to as messages & pa 0051, The interface bridge can implement the MIL-STD-1553 messaging protocol … The GSE computer application can initiate transfer of the super-MiDEF file via the MDT protocol. The interface bridge can accept the MDT download and save the file to non-volatile memory);
determining a bus message type of the message (Huber, pa 0040, FIG. 4 illustrates the basic formats of three basic types of MIL-STD-1553 information transfers. & pa 0041, The aircraft avionics can read the mission data on the cartridge and parse the mission data into its individual components. & pa 0052-0053, In in-flight operation 330, the interface bridge can perform interface translation and perform a MIL-STD-1760 MDT download of MiDEF mission files to the weapon 332 … The interface bridge can retrieve the mission data stored in non-volatile memory and parse mission data into its individual MiDEF module components. After waiting the initial duration of time and if no RT side MDT are in process the interface bridge can sequentially convert each individual MiDEF module into a corresponding MDT file format and download the MDT file to the weapon via the bus controller of the interface bridge. Examiner note: The type of information transfer is determined by parsing the message);
creating an output … file containing a first element based on the template file when the value of the bus message type is equal to the value of the transmission user identification attribute (Huber, pa 0041, The output of the mission planning system software can be written to a portable memory cartridge. Prior to takeoff the pilot or ground crew can insert the mission cartridge into the cartridge reader in the cockpit. The aircraft avionics can read the mission data on the cartridge and parse the mission data into its individual components. Some of these components can be the mission data files for the smart weapons loaded on the aircraft. … The aircraft avionics can determine which mission files are for each weapon and proceed to download those files to each of the weapons. & pa 0051, The GSE computer application can initiate transfer of the super-MiDEF file via the MDT protocol. The interface bridge can accept the MDT download and save the file to non-volatile memory).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Harvey with the teachings of Huber because it provides an integrated, centralized system control and standard interface for equipment connected to the bus (Huber, pa 0028).
With respect to claim 2, Harvey in view of Huber teaches the method according to claim 1 further comprising the steps of: creating a first template file having a first event element wherein the transmission user identification attribute of the first transmission element of the first template file has a first value; creating a second template file having a second event element wherein the transmission user identification attribute of the second transmission element of the second template file has a second value (Harvey, pa 0030, The administrator/planner creates one or more common configuration templates); creating a first element of the output XML file based on the first template file when the value of the bus message type is equal to the first value; and creating a second element of the output XML file based on the second template file when the value of the bus message type is equal to the second value (Harvey, pa 0055, In response, based on the device's unique identifier, configuration Server 116 retrieves one of the configuration templates 210 that is associated with the device 114. … As a result, a stream or file of XML format configuration information is created and potentially stored. & Huber, pa 0041, The output of the mission planning system software can be written to a portable memory cartridge. Prior to takeoff the pilot or ground crew can insert the mission cartridge into the cartridge reader in the cockpit. The aircraft avionics can read the mission data on the cartridge and parse the mission data into its individual components. Some of these components can be the mission data files for the smart weapons loaded on the aircraft. … The aircraft avionics can determine which mission files are for each weapon and proceed to download those files to each of the weapons. & pa 0051, The GSE computer application can initiate transfer of the super-MiDEF file via the MDT protocol. The interface bridge can accept the MDT download and save the file to non-volatile memory. Examiner note: These limitations are contingent on the “when” condition of each limitation. The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met).
With respect to claim 3, Harvey in view of Huber teaches the method according to claim 2 further comprising the steps of: creating a third template file having a third event element wherein the transmission user identification attribute of the third transmission element of the third template file has a third value (Harvey, pa 0030, The administrator/planner creates one or more common configuration templates); and creating a third element of the output XML file based on the third template file when the value of the bus message type is equal to the third value (Harvey, pa 0055, In response, based on the device's unique identifier, configuration Server 116 retrieves one of the configuration templates 210 that is associated with the device 114. … As a result, a stream or file of XML format configuration information is created and potentially stored. & Huber, pa 0041, The output of the mission planning system software can be written to a portable memory cartridge. Prior to takeoff the pilot or ground crew can insert the mission cartridge into the cartridge reader in the cockpit. The aircraft avionics can read the mission data on the cartridge and parse the mission data into its individual components. Some of these components can be the mission data files for the smart weapons loaded on the aircraft. … The aircraft avionics can determine which mission files are for each weapon and proceed to download those files to each of the weapons. & pa 0051, The GSE computer application can initiate transfer of the super-MiDEF file via the MDT protocol. The interface bridge can accept the MDT download and save the file to non-volatile memory).
With respect to claim 4, Harvey in view of Huber teaches the method according to claim 1 wherein the transmission user identification attribute of the transmission element of the template has a value equal to the value of the event user identification attribute of the template (Harvey, pa 0055, In response, based on the device's unique identifier, configuration Server 116 retrieves one of the configuration templates 210 that is associated with the device 114. … As a result, a stream or file of XML format configuration information is created and potentially stored. & Huber, pa 0046, The structure of MiDEF submodules can be defined in an interface control document (ICD) between a store OFP and a store mission planning module. The individual data elements can be defined in MIL-STD-3014. Also, the functional class code identifier of each module can be specified in MIL-STD-3014. The MiDEF ICD can define the data elements that are members of each module.).
With respect to claim 5, Harvey in view of Huber teaches the method according to claim 1 wherein the value of the transfer type attribute indicates both a transmitter of the message and a receiver of the message, the value of the transfer receiver attribute indicates the receiver of the message, and the value of the transfer sender attribute indicates the transmitter of the message (Huber, Fig. 3 command word addresses & pa 0034, Command words are transmitted by the bus controller and include a 3 bit-time sync pattern (i.e., bits 1-3), a 5 bit RT address field (i.e., bits 4-8; RT address 0-31), a 1 transmit/receive (T/R) field (i.e., bit 9; 0 for receive or 1 for transmit), a 5 bit subaddress/mode field (i.e., bits 10-14; indicate the location (sub-address) to hold or get data on the RT).
With respect to claim 6, Harvey in view of Huber teaches the method according to claim 1 wherein the transfer element further comprises a from controller element (Huber, Fig. 4 & pa 0039, In the controller to RT transfer, the bus controller sends one 16-bit receive command word, immediately followed by 1 to 32 16-bit data words.).
With respect to claim 7, Harvey in view of Huber teaches the method according to claim 6 wherein the from controller element comprises a receive command element and a data words element when the message is received and a transmit command element when the message is transmitted (Huber, Fig. 4 & pa 0039, In the controller to RT transfer, the bus controller sends one 16-bit receive command word, immediately followed by 1 to 32 16-bit data words. … the bus controller sends one transmit command word to a remote terminal.).
With respect to claim 8, Harvey in view of Huber teaches the method according to claim 7 wherein the transmit command element comprises: a remote terminal address element, a sub address or mode element, a word count or mode code element, and a command word element; and the receive command element comprises: a remote terminal address element, a sub address or mode element, a word count or mode code element, and a command word element (Huber, Fig. 3 & pa 0034, Command words are transmitted by the bus controller and include… a 5 bit RT address field (i.e., bits 4-8; RT address 0-31), a 1 transmit/receive (T/R) field (i.e., bit 9; 0 for receive or 1 for transmit), a 5 bit subaddress/mode field (i.e., bits 10-14; indicate the location (sub-address) to hold or get data on the RT …, a 5 bit word count/mode code field).
With respect to claim 9, Harvey in view of Huber teaches the method according to claim 1 wherein the transfer element comprises a from receiving device element when the message is received and a from transmitting device element when the message is transmitted (Huber, Fig. 4 & pa 0039, The remote terminal responds with a status word. In the transmit mode command with data word(s), the bus controller sends one command word with a subaddress of 0 or 31 signifying a mode code type command. The remote terminal responds with a status word immediately followed by a data word.).
With respect to claim 10, Harvey in view of Huber teaches the method according to claim 9 wherein the from receiving device element comprises: a status word element; and the from transmitting device element comprises: a status word element, and a data words element (Huber, pa 0039, The remote terminal responds with a status word. In the transmit mode command with data word(s), the bus controller sends one command word with a subaddress of 0 or 31 signifying a mode code type command. The remote terminal responds with a status word immediately followed by a data word.).
With respect to claim 11, Harvey in view of Huber teaches the method according to claim 1 wherein the transfer element comprises an error element (Huber, pa 0037, If either RT fails to send its status or the expected data or indicates a problem through the setting of error bits in the status word, the bus controller may retry the transmission.).
With respect to claim 12, Harvey in view of Huber teaches the method according to claim 11 wherein the error element is assigned a value to indicate that no error is present (Huber, pa 0037, The status word at the end of a data transfer sequence ensures that the data has been received and that the result of the data transfer is acceptable. If either RT fails to send its status or the expected data or indicates a problem through the setting of error bits in the status word, the bus controller may retry the transmission.).
With respect to claims 15-19, the limitations are essentially the same as claims 1-3 and 6-10, and are rejected for the same reasons.
Claims 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Harvey in view of Huber, and further in view of Khan et al. (US 2024/0112134).
With respect to claim 13, Harvey in view of Huber teaches the method according to claim 1 as discussed above. Harvey in view of Huber doesn't expressly discuss wherein the transmission element comprises a metadata element.
Khan teaches wherein the transmission element comprises a metadata element (Khan, Fig. 6 & pa 0057, When a user enters “inventory spill,” the template may recognize “inventory spill” as a type of incident and retrieve a template for that event from a template store that will be described in more detail below. The template then generates the fields associated with an inventory spill and provides menus where appropriate, such as for locations, assets affected, and priority level, and text-based fields for fields such as additional details.).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Harvey in view of Huber with the teachings of Khan because creating tasks and reporting incidents optimizes performance (Khan, pa 0055).
With respect to claim 14, Harvey in view of Huber and Khan teaches the method according to claim 13 wherein the metadata element comprises: an event date time element; a snooper type element; a standard element; and a bus element (Khan, pa 0057, When a user enters “inventory spill,” the template may recognize “inventory spill” as a type of incident and retrieve a template for that event from a template store that will be described in more detail below. The template then generates the fields associated with an inventory spill and provides menus where appropriate, such as for locations, assets affected, and priority level, and text-based fields for fields such as additional details. Examiner note: The references do not specify the metadata element comprises: an event date time element; a snooper type element; a standard element; and a bus element, however, it would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to have used this data because the method has the aforementioned benefits and the benefits would apply regardless of the type of data.).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Harvey in view of Harvey et al. (US 2006/0190575), and further in view of Huber et al. (US 2015/0082975) and Khan et al. (US 2024/0112134).
With respect to claim 20, Harvey teaches a method for creating a standardized XML format comprising the steps of:
defining an event element wherein the event element comprises:
an event user identification attribute having a value (Harvey, pa 0054, When the device 114 is powered-up at customer premises 112, the device connects to Configuration Server 116 by establishing a TCP/IP connection. The device issues an HTTP get request to Web server 206 of Configuration Server 116. To uniquely identify itself to the Configuration Server 116 and to the Web server, the device 114 provides its token as a unique identifier.);
identifying a message on a shared bus (Harvey, pa 0033, The order entry system 104 receives one or more orders and can communicate over an event service 120 with a workflow manager 106. & pa 0035, Event Service 120 is implemented in the form of The Information Bus software, which is commercially available from TIBCO Software, Inc. Event Gateway 118 provides as an interface that permits network devices 114 to communicate with Event Service 120.);
determining a bus message type of the message (Harvey, pa 0054, When the device 114 is powered-up at customer premises 112, the device connects to Configuration Server 116 by establishing a TCP/IP connection. The device issues an HTTP get request to Web server 206 of Configuration Server 116. To uniquely identify itself to the Configuration Server 116 and to the Web server, the device 114 provides its token as a unique identifier. & pa 0053, the minimal configuration of the device causes the device to look for its initial configuration from a Web server using a CLI command of the type described further herein);
creating a first template file having a first event element wherein the transmission user identification attribute of the transmission element of the first template file has a first value (Harvey, pa 0030, The administrator/planner creates one or more common configuration templates, which can contain Universal Resource Locators (URLs) that identify the location of the device information, which is stored in a repository. Using such templates, an individual device configuration is dynamically built utilizing information located in the repository. The repository may be, for example, a directory or database. This enables templates to be used for multiple devices. & pa 0053, the minimal configuration of the device causes the device to look for its initial configuration from a Web server using a CLI command of the type described further herein);
creating a second template file having a second event element wherein the transmission user identification attribute of the transmission element of the second template file has a second value (Harvey, pa 0030, The administrator/planner creates one or more common configuration templates, which can contain Universal Resource Locators (URLs) that identify the location of the device information, which is stored in a repository. Using such templates, an individual device configuration is dynamically built utilizing information located in the repository. The repository may be, for example, a directory or database. This enables templates to be used for multiple devices. Examiner note: templates are created for multiple devices & pa 0053, the minimal configuration of the device causes the device to look for its initial configuration from a Web server using a CLI command of the type described further herein);
creating a third template file having a third event element wherein the transmission user identification attribute of the transmission element of the third template file has a third value (Harvey, pa 0030, The administrator/planner creates one or more common configuration templates, which can contain Universal Resource Locators (URLs) that identify the location of the device information, which is stored in a repository. Using such templates, an individual device configuration is dynamically built utilizing information located in the repository. The repository may be, for example, a directory or database. This enables templates to be used for multiple devices. Examiner note: templates are created for multiple devices);
creating a first element of an output XML file based on the first template file when the value of the bus message type is equal to the first value; and creating a second element of the output XML file based on the second template file when the value of the bus message type is equal to the second value; and creating a third element of the output XML file based on the third template file when the value of the bus message type is equal to the third value (Harvey, pa 0055, In response, based on the device's unique identifier, configuration Server 116 retrieves one of the configuration templates 210 that is associated with the device 114. … As a result, a stream or file of XML format configuration information is created and potentially stored. Examiner note: These limitations are contingent on the “when” condition of each limitation. The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met).
Harvey doesn't expressly discuss a transmission element, wherein the transmission element further comprises: a transmission user identification attribute having a value, a transmission type attribute having a value, a transmission name attribute having a value, a transmission type count attribute having a value, a transfer type attribute having a value indicating both a transmitter of the message and a receiver of the message, a transfer receiver attribute having a value indicating the receiver of the message, a transfer sender attribute having a value indicating the transmitter of the message, a from controller element further comprising: a receive command element and a data words element when the message is received, wherein the receive command element further comprises: a remote terminal address element, a sub address or mode element, a word count or mode code element, and a command word element; and a transmit command element when the message is transmitted, wherein the transmit command element further comprises: a remote terminal address element, a sub address or mode element, a word count or mode code element, and a command word element; and a from receiving device element when the message is received, wherein the from receiving device element further comprises a status word element; a from transmitting device element when the message is transmitted, wherein the from transmitting device element further comprises: a status word element, and a data words element; an error element assigned a value to indicate that no error is present.
Huber teaches defining an event element wherein the event element comprises: an event user identification attribute having a value;
a transmission element, wherein the transmission element further comprises: a transmission user identification attribute having a value, a transmission type attribute having a value, a transmission name attribute having a value, a transmission type count attribute having a value (Huber, Fig. 7, pa 0010, FIG. 7 illustrates a diagram of a mission data exchange format (MiDEF) module including three submodules in accordance with an example & pa 0045, The Universal Armament Interface (UAI) mission files have a dynamic structure in a Mission Data Exchange Format (MiDEF), as defined by MIL-STD-3014. MiDEF is a structure used by the UAL The architecture of a MiDEF file can be hierarchical or "nested" and dynamic. Each MiDEF file can include at least one module. A module can include a header that can include a table of contents and module data, which can include one or more sub-modules 460, 462, and 464 and/or primitive data elements, as illustrated by FIG. 7.… The defined module types and primitive data elements can be defined by MIL STD-3014. The size of a MiDEF file can be variable as the size can depend upon which elements are included in the modules and sub-modules & pa 0051, the GSE computer application software can combine the individual binary MiDEF files created by the mission planning application into a single "super-MiDEF" file), and a transfer element, wherein the transfer element further comprises:
a transfer type attribute having a value indicating both a transmitter of the message and a receiver of the message, a transfer receiver attribute having a value indicating the receiver of the message, a transfer sender attribute having a value indicating the transmitter of the message (Huber, Fig. 3 command word addresses & pa 0034, Command words are transmitted by the bus controller and include a 3 bit-time sync pattern (i.e., bits 1-3), a 5 bit RT address field (i.e., bits 4-8; RT address 0-31), a 1 transmit/receive (T/R) field (i.e., bit 9; 0 for receive or 1 for transmit), a 5 bit subaddress/mode field (i.e., bits 10-14; indicate the location (sub-address) to hold or get data on the RT), a from controller element (Huber, Fig. 4 & pa 0039, In the controller to RT transfer, the bus controller sends one 16-bit receive command word, immediately followed by 1 to 32 16-bit data words.) further comprising:
a receive command element and a data words element when the message is received, wherein the receive command element further comprises: a remote terminal address element, a sub address or mode element, a word count or mode code element, and a command word element (Huber, Fig. 3 & pa 0034, Command words are transmitted by the bus controller and include… a 5 bit RT address field (i.e., bits 4-8; RT address 0-31), a 1 transmit/receive (T/R) field (i.e., bit 9; 0 for receive or 1 for transmit), a 5 bit subaddress/mode field (i.e., bits 10-14; indicate the location (sub-address) to hold or get data on the RT …, a 5 bit word count/mode code field); and
a transmit command element when the message is transmitted, wherein the transmit command element further comprises: a remote terminal address element, a sub address or mode element, a word count or mode code element, and a command word element (Huber, Fig. 3 & pa 0034, Command words are transmitted by the bus controller and include… a 5 bit RT address field (i.e., bits 4-8; RT address 0-31), a 1 transmit/receive (T/R) field (i.e., bit 9; 0 for receive or 1 for transmit), a 5 bit subaddress/mode field (i.e., bits 10-14; indicate the location (sub-address) to hold or get data on the RT …, a 5 bit word count/mode code field); and
a from receiving device element when the message is received, wherein the from receiving device element further comprises a status word element (Huber, pa 0039, In the RT to controller transfer, the bus controller sends one transmit command word to a remote terminal. The remote terminal responds with a status word.);
a from transmitting device element when the message is transmitted, wherein the from transmitting device element further comprises: a status word element, and a data words element (Huber, pa 0039, In the transmit mode command with data word(s), the bus controller sends one command word with a subaddress of 0 or 31 signifying a mode code type command. The remote terminal responds with a status word immediately followed by a data word.);
an error element assigned a value to indicate that no error is present (Huber, pa 0037, The status word at the end of a data transfer sequence ensures that the data has been received and that the result of the data transfer is acceptable. If either RT fails to send its status or the expected data or indicates a problem through the setting of error bits in the status word, the bus controller may retry the transmission.);
identifying a message on a shared bus (Huber, pa 0031, The MIL-STD-1553 bus controller (BC) can be a terminal that initiates information transfers on the data bus. & pa 0040, FIG. 4 illustrates the basic formats of three basic types of MIL-STD-1553 information transfers including bus controller to remote terminal transfers (BC-to-RT), remote terminal to bus controller transfers (RT-to-BC), and remote terminal to remote terminal (RT-to-RT) transfers…The MIL-STD-1553 information transfers can be related to the data flow and can be referred to as messages & pa 0051, The interface bridge can implement the MIL-STD-1553 messaging protocol … The GSE computer application can initiate transfer of the super-MiDEF file via the MDT protocol. The interface bridge can accept the MDT download and save the file to non-volatile memory);
determining a bus message type of the message (Huber, pa 0040, FIG. 4 illustrates the basic formats of three basic types of MIL-STD-1553 information transfers. & pa 0041, The aircraft avionics can read the mission data on the cartridge and parse the mission data into its individual components. & pa 0052-0053, In in-flight operation 330, the interface bridge can perform interface translation and perform a MIL-STD-1760 MDT download of MiDEF mission files to the weapon 332 … The interface bridge can retrieve the mission data stored in non-volatile memory and parse mission data into its individual MiDEF module components. After waiting the initial duration of time and if no RT side MDT are in process the interface bridge can sequentially convert each individual MiDEF module into a corresponding MDT file format and download the MDT file to the weapon via the bus controller of the interface bridge. Examiner note: The type of information transfer is determined by parsing the message);
creating a first template file having a first event element wherein the transmission user identification attribute of the transmission element of the first template file has a first value; creating a second template file having a second event element wherein the transmission user identification attribute of the transmission element of the second template file has a second value; creating a third template file having a third event element wherein the transmission user identification attribute of the transmission element of the third template file has a third value (Huber, pa 0045, Each MiDEF file can include at least one module. A module can include a header that can include a table of contents and module data, which can include one or more sub-modules 460, 462, and 464 and/or primitive data elements, as illustrated by FIG. 7. & pa 0046, the functional class code identifier of each module can be specified in MIL-STD-3014. The MiDEF ICD can define the data elements that are members of each module.);
creating a first element of an output … file based on the first template file when the value of the bus message type is equal to the first value; and creating a second element of the output … file based on the second template file when the value of the bus message type is equal to the second value; and creating a third element of the output … file based on the third template file when the value of the bus message type is equal to the third value (Huber, pa 0041, The output of the mission planning system software can be written to a portable memory cartridge. Prior to takeoff the pilot or ground crew can insert the mission cartridge into the cartridge reader in the cockpit. The aircraft avionics can read the mission data on the cartridge and parse the mission data into its individual components. Some of these components can be the mission data files for the smart weapons loaded on the aircraft. … The aircraft avionics can determine which mission files are for each weapon and proceed to download those files to each of the weapons. & pa 0051, The GSE computer application can initiate transfer of the super-MiDEF file via the MDT protocol. The interface bridge can accept the MDT download and save the file to non-volatile memory).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Harvey with the teachings of Huber because it provides an integrated, centralized system control and standard interface for equipment connected to the bus (Huber, pa 0028).
Harvey in view of Huber doesn't expressly discuss wherein the transmission element comprises a metadata element.
Khan teaches a metadata element (Khan, Fig. 6 & pa 0057, When a user enters “inventory spill,” the template may recognize “inventory spill” as a type of incident and retrieve a template for that event from a template store that will be described in more detail below. The template then generates the fields associated with an inventory spill and provides menus where appropriate, such as for locations, assets affected, and priority level, and text-based fields for fields such as additional details.) further comprising: an event date time element; a snooper type element; a standard element; and a bus element (Khan, pa 0057, When a user enters “inventory spill,” the template may recognize “inventory spill” as a type of incident and retrieve a template for that event from a template store that will be described in more detail below. The template then generates the fields associated with an inventory spill and provides menus where appropriate, such as for locations, assets affected, and priority level, and text-based fields for fields such as additional details. Examiner note: The references do not specify the metadata element comprises: an event date time element; a snooper type element; a standard element; and a bus element, however, it would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to have used this data because the method has the aforementioned benefits and the benefits would apply regardless of the type of data.).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Harvey in view of Huber with the teachings of Khan because creating tasks and reporting incidents optimizes performance (Khan, pa 0055).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRITTANY N ALLEN whose telephone number is (571)270-3566. The examiner can normally be reached M-F 9 am - 5:00 pm EST.
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, Sherief Badawi can be reached at 571-272-9782. 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.
/BRITTANY N ALLEN/ Primary Examiner, Art Unit 2169