DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Foreign priority to Chinese application CN 202210180680.4, dated 02/25/2022, and PCT application CN2023/071183, dated 01/09/2023, is acknowledged. However, a full English translation of the full priority document is required to perfect foreign priority.
The IDS documents submitted on 12/20/2023 and 06/22/2025 have been received and considered by the examiner.
Claim Objections
Claim 5 is objected to because of the following informalities: it contains an apparent typo (“set to the cache queue”, which presumably should read “sent to the cache queue”). Appropriate correction is required.
Claim 8 is objected to because of the following informalities: it contains an apparent typo (“the quantity of consecutive uploading failures failing reaching the count”). Appropriate correction is required.
Claim 9 is objected to because of the following informalities: it recites “a second warehousing timestamp” without mentioning “a first warehousing timestamp”. Appropriate correction is required.
Claim 17 is objected to because of the following informalities: it contains an apparent typo (“indicating a maximum a size allowed”). Appropriate correction is required.
Allowable Subject Matter
Claim 9 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The prior art does not fairly teach “in response to the data type being a non-discardable type, a quantity of data packets in the database being less than a quantity threshold, and the first data packet not existing in the database, determining a current timestamp as a second warehousing timestamp of the first data packet through a reporting component, sending the first data packet and the second warehousing timestamp to a database thread, and associatively storing the first data packet and the second warehousing timestamp in the database through the database thread” in combination with the other limitations of Claim 9.
Claim 10 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claim 10 is allowable because it depends on Claim 9.
Claim 13 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The prior art does not fairly teach “in response to no idle position existing in the cache queue, determining a current timestamp as a third warehousing timestamp of the third data packet through the reporting component, and sending the third data packet and the third warehousing timestamp to a database thread” in combination with the other limitations of Claim 13.
Claim 14 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The prior art does not fairly teach “allocating a target service identifier to the service data in an incremental manner, and writing the target service identifier into the log file; obtaining a maximum service identifier and a minimum service identifier in a target time period through the virtual address space; obtaining a quantity of deduplication service identifiers counted by the server in the target time period; and generating a reporting success rate according to the maximum service identifier, the minimum service identifier, and the quantity of deduplication service identifiers” in combination with the other limitations of Claim 14.
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.
Claim(s) 1, 7, 16, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamamoto et al. (US 11,159,456 B2, hereinafter “Yamamoto”) in view of Aspel et al. (US 2008/0154099 A1, hereinafter “Aspel”).
As to Claim 1:
Yamamoto describes a low-latency implementation of an intra-vehicle communications network.
Specifically, Yamamoto teaches:
An in-vehicle central control device, a database and a cache queue being arranged in the in-vehicle central control device
(“Fig. 1 is a hardware configuration diagram of a control apparatus 1. The control apparatus 1 is connected to a plurality of networks ... The six networks are, for example, controller area networks (CANs) ... Fig. 2 is a functional block diagram showing a functional configuration of the control apparatus 1” (Yamamoto col. 2, lines 64-67; col. 3, line 1; col. 4, lines 2-3).
Here, “CAN” maps to “an in-vehicle control”,
“control apparatus” 1 in Figs. 1-2 maps to “control device”,
the “MPFO buffer 11” in Fig. 2 maps to “a database”, and
“First Transmission Queue” 21a in Fig. 2 maps to “a cache queue being arranged in the in-vehicle central control device”).
Polling data packets in the database, to obtain a to-be-added data packet set, and adding the to-be-added data packet set to the cache queue
(“The MPFO management unit 12 stores, in the MPFO buffer 11, a frame that each controller 20 receives from the corresponding network. The normal transmission unit 13 transmits the frame stored in the MPFO buffer 11 to the transmission queue 21 of the controller 20 corresponding to the network serving as a transfer destination” (Yamamoto col. 4, lines 24-29).
Here, “a frame that each controller 20 receives” maps to “polling data packets ... to obtain a to-be-added data packet set”,
“the MPFO buffer 11” maps to “the database”, and
“transmits the frame stored in the MPFO buffer 11 to the transmission queue 21” maps to “adding the to-be-added data packet set to the cache queue”).
Polling the cache queue to obtain a to-be-uploaded data packet set, and uploading the to-be-uploaded data packet set through a wireless communication connection of the in-vehicle central control device
(“In Fig. 8, in S311, first, the controller 20 determines whether or not a frame is stored in the transmission queue 21. When the controller 20 determines that a frame is stored in the transmission queue 21, the processing proceeds to S312.... In S312, the controller determines whether or not the frame can be transmitted to the network. When the controller 20 determines that the frame can be transmitted to the network, the processing proceeds to S313” (Yamamoto col. 6, lines 59-67; col. 7, lines 1-2).
Here, “determines that a frame is stored in the transmission queue 21” maps to “polling the cache queue to obtain a to-be-uploaded data packet set”, and
“to the network” maps to “through a wireless communication connection of the in-vehicle central control device”).
Yamamoto does not explicitly disclose:
Storing a first data packet in the database in response to that the first data packet in the to-be-uploaded data packet set meets a continuous uploading failure condition
Deleting a second data packet from the database, in response to the second data packet in the to-be-uploaded data packet set being successfully uploaded to a server
However, Aspel does describe a method for reliable file transfers to and from a health monitoring device.
Specifically, Aspel teaches:
Storing a first data packet in the database in response to that the first data packet in the to-be-uploaded data packet set meets a continuous uploading failure condition
(“The medical data is stored in the access point in non-volatile memory in case re-transmission is required ... If the transmission fails, the reading is stored and the Cellular telephone retries at prescribed intervals” (Aspel, 0103, 0119).
Here, “the reading is stored” maps to “storing a first data packet in the database”, and
“if the transmission fails” maps to “in response to that the first data packet in the to-be-uploaded data packet set meets a continuous uploading failure condition”).
Deleting a second data packet from the database, in response to the second data packet in the to-be-uploaded data packet set being successfully uploaded to a server
(“The medical data is stored in the access point in non-volatile memory in case re-transmission is required ... Once confirmation of successful transmission is received the data is deleted” (Aspel, 0103).
Here, “the data is deleted” maps to “deleting a second packet from the database”, and
“once confirmation of a successful transmission is received” maps to “in response to the second data packet in the to-be-uploaded packet set being successfully uploaded to the server”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Aspel’s method for ensuring successful file transfer to a CAN network such as the one described in Yamamoto. Aspel’s method can help ensure that critical data is successfully transmitted and not lost on the CAN bus.
As to Claim 7:
Yamamoto teaches:
Polling the cache queue to obtain S data packets in a reporting component in response to data packets existing in the cache queue and according to queue positions of the data packets in the cache queue
(“When the priority rule 15 is as shown in the example of Fig. 3 and a total of three frames, i.e. frames having CAN-IDs “10” and “30” and a frame having a destination IF address ‘192.168.1.10’, exist in the MPFO buffer 11, those frames are transmitted to the transmission queue 21 in the following order” (Yamamoto, col. 4, lines 56-61).
Here, “frames are transmitted” maps to “polling the cache queue to obtain S data packets in a reporting component”,
“a total of three frames ... exist in the MPFO buffer 11” maps to “data packets existing in the cache queue”,
“having a destination IF address ‘192.168.1.10’” maps to “according to queue positions of the data packets”, and
“the MPFO buffer 11” maps to “the cache queue”).
Determining the S data packets as the to-be-uploaded data packet set
(“When the priority rule 15 is as shown in the example of Fig. 3 and a total of three frames, i.e. frames having CAN-IDs “10” and “30” and a frame having a destination IF address ‘192.168.1.10’, exist in the MPFO buffer 11, those frames are transmitted to the transmission queue 21 in the following order” (Yamamoto, col. 4, lines 56-61).
Here, “three frames ... are transmitted” maps to “determining the S data packets as the to-be-uploaded data packet set”).
S is a positive integer
(“When the priority rule 15 is as shown in the example of Fig. 3 and a total of three frames, i.e. frames having CAN-IDs “10” and “30” and a frame having a destination IF address ‘192.168.1.10’, exist in the MPFO buffer 11, those frames are transmitted to the transmission queue 21 in the following order” (Yamamoto, col. 4, lines 56-61).
Here, “three” maps to “S is a positive integer”).
As to Claim 16:
Yamamoto teaches:
A data processing apparatus, arranged in an in-vehicle central control device, a database and a cache queue being arranged in the in-vehicle central control device, and the apparatus comprising at least one memory and at least one processor coupled to the memory, the at least one processor being configured
(“Fig. 1 is a hardware configuration diagram of a control apparatus 1. The control apparatus 1 is connected to a plurality of networks ... The six networks are, for example, controller area networks (CANs) ... Fig. 2 is a functional block diagram showing a functional configuration of the control apparatus 1” (Yamamoto col. 2, lines 64-67; col. 3, line 1; col. 4, lines 2-3).
Here, “Control Apparatus” 1 in Figs. 1-2 maps to “a data processing apparatus, arranged in an in-vehicle central control device”,
“CAN” maps to “in-vehicle control”,
“MPFO Buffer” 11 in Fig. 2 maps to “a database”,
“First Transmission Queue” 21a in Fig. 2 maps to “a cache queue being arranged in the in-vehicle central control device”,
“Flash Memory” 5 in Fig. 1 maps to “the apparatus comprising at least one memory”, and
“CPU” 2 in Fig. 1 maps to “at least one processor coupled to the memory, the at least one processor being configured”).
Poll data packets in the database to obtain a to-be-added data packet set, and adding the to-be-added data packet set to the cache queue
(“The MPFO management unit 12 stores, in the MPFO buffer 11, a frame that each controller 20 receives from the corresponding network. The normal transmission unit 13 transmits the frame stored in the MPFO buffer 11 to the transmission queue 21 of the controller 20 corresponding to the network serving as a transfer destination” (Yamamoto col. 4, lines 24-29).
Here, “a frame that each controller 20 receives” maps to “poll data packets ... to obtain a to-be-added data packet set”,
“MPFO buffer 11” maps to “the database”, and
“transmits the frame stored in the MPFO buffer 11 to the transmission queue 21” maps to “adding the to-be-added data packet set to the cache queue”).
Poll the cache queue to obtain a to-be-uploaded data packet set, and uploading the to-be-uploaded data packet set through a wireless communication connection of the in-vehicle central control device
(“In Fig. 8, in S311, first, the controller 20 determines whether or not a frame is stored in the transmission queue 21. When the controller 20 determines that a frame is stored in the transmission queue 21, the processing proceeds to S312.... In S312, the controller determines whether or not the frame can be transmitted to the network. When the controller 20 determines that the frame can be transmitted to the network, the processing proceeds to S313” (Yamamoto col. 6, lines 59-67; col. 7, lines 1-2).
Here, “determines that a frame is stored in the transmission queue 21” maps to “poll the cache queue to obtain a to-be-uploaded data packet set”, and
“to the network” maps to “through a wireless communication connection of the in-vehicle central control device”).
Yamamoto does not explicitly disclose:
Add a first data packet to the database in response to that the first data packet in the to-be-uploaded data packet set meets a continuous uploading failure condition
Delete a second data packet from the database, in response to the second data packet in the to-be-uploaded data packet set being successfully uploaded to a server
However, Aspel does teach:
Add a first data packet to the database in response to that the first data packet in the to-be-uploaded data packet set meets a continuous uploading failure condition
(“The medical data is stored in the access point in non-volatile memory in case re-transmission is required ... If the transmission fails, the reading is stored and the Cellular telephone retries at prescribed intervals” (Aspel, 0103, 0119).
Here, “the reading is stored” maps to “add a first data packet in the database”, and
“if the transmission fails” maps to “in response to that the first data packet in the to-be-uploaded data packet set meets a continuous uploading failure condition”).
Delete a second data packet from the database, in response to the second data packet in the to-be-uploaded data packet set being successfully uploaded to a server
(“The medical data is stored in the access point in non-volatile memory in case re-transmission is required ... Once confirmation of successful transmission is received the data is deleted” (Aspel, 0103).
Here, “the data is deleted” maps to “delete a second packet from the database”, and
“once confirmation of a successful transmission is received” maps to “in response to the second data packet in the to-be-uploaded packet set being successfully uploaded to the server”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Aspel’s method for ensuring successful file transfer to a CAN network such as the one described in Yamamoto. Aspel’s method can help ensure that critical data is successfully transmitted and not lost on the CAN bus.
As to Claim 18:
Yamamoto teaches:
A non-transitory computer-readable storage medium, storing a computer program, executable by a processor to perform a data processing method
(“Fig. 1 is a hardware configuration diagram of a control apparatus 1. The control apparatus 1 is connected to a plurality of networks ... The six networks are, for example, controller area networks (CANs) ... Fig. 2 is a functional block diagram showing a functional configuration of the control apparatus 1” (Yamamoto col. 2, lines 64-67; col. 3, line 1; col. 4, lines 2-3).
Here, “Flash Memory” 5 in Fig. 1 maps to “a non-transitory computer-readable storage medium, storing a program, executable ... to perform a data processing method”, and
“CPU” 2 in Fig. 1 maps to “a processor”).
Polling data packets in the database, to obtain a to-be-added data packet set, and adding the to-be-added data packet set to the cache queue
(“The MPFO management unit 12 stores, in the MPFO buffer 11, a frame that each controller 20 receives from the corresponding network. The normal transmission unit 13 transmits the frame stored in the MPFO buffer 11 to the transmission queue 21 of the controller 20 corresponding to the network serving as a transfer destination” (Yamamoto col. 4, lines 24-29).
Here, “a frame that each controller 20 receives” maps to “polling data packets ... to obtain a to-be-added data packet set”,
“MPFO buffer 11” maps to “the database”, and
“transmits the frame stored in the MPFO buffer 11 to the transmission queue 21” maps to “adding the to-be-added data packet set to the cache queue”).
Polling the cache queue to obtain a to-be-uploaded data packet set, and uploading the to-be-uploaded data packet set through a wireless communication connection of the in-vehicle central control device
(“In Fig. 8, in S311, first, the controller 20 determines whether or not a frame is stored in the transmission queue 21. When the controller 20 determines that a frame is stored in the transmission queue 21, the processing proceeds to S312.... In S312, the controller determines whether or not the frame can be transmitted to the network. When the controller 20 determines that the frame can be transmitted to the network, the processing proceeds to S313” (Yamamoto col. 6, lines 59-67; col. 7, lines 1-2).
Here, “determines that a frame is stored in the transmission queue 21” maps to “polling the cache queue to obtain a to-be-uploaded data packet set”, and
“to the network” maps to “through a wireless communication connection of the in-vehicle central control device”).
Yamamoto does not explicitly disclose:
Storing a first data packet in the database in response to that the first data packet in the to-be-uploaded data packet set meets a continuous uploading failure condition
Deleting a second data packet from the database, in response to the second data packet in the to-be-uploaded data packet set being successfully uploaded to a server
However, Aspel does teach:
Storing a first data packet in the database in response to that the first data packet in the to-be-uploaded data packet set meets a continuous uploading failure condition
(“The medical data is stored in the access point in non-volatile memory in case re-transmission is required ... If the transmission fails, the reading is stored and the Cellular telephone retries at prescribed intervals” (Aspel, 0103, 0119).
Here, “the reading is stored” maps to “storing a first data packet in the database”, and
“if the transmission fails” maps to “in response to that the first data packet in the to-be-uploaded data packet set meets a continuous uploading failure condition”).
Deleting a second data packet from the database, in response to the second data packet in the to-be-uploaded data packet set being successfully uploaded to a server
(“The medical data is stored in the access point in non-volatile memory in case re-transmission is required ... Once confirmation of successful transmission is received the data is deleted” (Aspel, 0103).
Here, “the data is deleted” maps to “deleting a second packet from the database”, and
“once confirmation of a successful transmission is received” maps to “in response to the second data packet in the to-be-uploaded packet set being successfully uploaded to the server”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Aspel’s method for ensuring successful file transfer to a CAN network such as the one described in Yamamoto. Aspel’s method can help ensure that critical data is successfully transmitted and not lost on the CAN bus.
Claim(s) 2-3, 17, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamamoto (US 11,159,456 B2) in view of Aspel (US 2008/0154099 A1) and further in view of Herrero et al. (US 2017/0054573 A1, hereinafter “Herrero”).
As to Claim 2:
The combination of Yamamoto and Aspel does not explicitly disclose:
Receiving a cache capacity configured by a configuration server
Determining whether an idle position exists in the cache queue by comparing a size of data packets in the cache queue with the cache capacity
Allowing writing data into the cache queue in response to the size of the data packets in the cache queue being less than the cache capacity
However, Herrero does describe real time communications using a ring buffer.
Specifically, Herrero teaches:
Receiving a cache capacity configured by a configuration server
(“Server 116 [in Fig. 1], based on available memory resources, determines the buffer size N and informs client 106 through a TSCF service response” (Herrero, 0035).
Here, “determines the buffer size N and informs client 106” maps to “receiving a cache capacity configured”, and
“server 116” maps to “a configuration server”).
Determining whether an idle position exists in the cache queue by comparing a size of data packets in the cache queue with the cache capacity
(“In one embodiment, redundant traffic encoding is requested by application 104 ... The following example pseudo-code shows how the notification is enabled and what the notification callback looks like: ... if (rte_data && rte_data->available == tsc_bool_true) ... rte enabled notification on socket” (Herrero, 0049).
Here, “if ... rte_data->available == tsc_bool_true” maps to “determining whether an idle position exists” because the rte uses a ring buffer so an idle position in that buffer exists if “rte_data->available” is true,
“==” maps to “comparing”,
“rte_data” maps to “a size of data packets in the cache queue”, and
“rte_data->available” maps to “the cache capacity”).
Allowing writing data into the cache queue in response to the size of the data packets in the cache queue being less than the cache capacity
(“In one embodiment, redundant traffic encoding is requested by application 104 ... The following example pseudo-code shows how the notification is enabled and what the notification callback looks like: ... if (rte_data && rte_data->available == tsc_bool_true) ... rte enabled notification on socket” (Herrero, 0049).
Here, “rte enabled notification” maps to “allowing writing data into the cache queue”, and
“rte_data && rte_data-> available” maps to “in response to the size of the data packets in the cache queue being less than the cache capacity”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Herrero’s practice of checking if there is available space in a buffer to send a message into the CAN network described in Yamamoto. It would be obvious to prevent writes to a buffer that is full and cannot accept new input data.
As to Claim 3:
Yamamoto teaches:
A database
(Fig. 2 in Yamamoto shows a vehicle control system.
Here, “MPFO Buffer 11” maps to “a dtabase”).
The combination of Yamamoto and Aspel does not explicitly disclose:
Receiving a ... capacity configured by a configuration server
Determining whether an idle position exists ... by comparing a size of data packets ... with the ... capacity
Allowing writing data ... in response to the size of the data packets ... being less than the ... capacity
However, Herrero does teach:
Receiving a ... capacity configured by a configuration server
(“Server 116 [in Fig. 1], based on available memory resources, determines the buffer size N and informs client 106 through a TSCF service response” (Herrero, 0035).
Here, “determines the buffer size N and informs client 106” maps to “receiving a ... capacity configured”, and
“server 116” maps to “a configuration server”).
Determining whether an idle position exists ... by comparing a size of data packets ... with the ... capacity
(“In one embodiment, redundant traffic encoding is requested by application 104 ... The following example pseudo-code shows how the notification is enabled and what the notification callback looks like: ... if (rte_data && rte_data->available == tsc_bool_true) ... rte enabled notification on socket” (Herrero, 0049).
Here, “if ... rte_data->available == tsc_bool_true” maps to “determining whether an idle position exists” because the rte uses a ring buffer so an idle position in that buffer exists if “rte_data->available” is true,
“==” maps to “comparing”,
“rte_data” maps to “a size of data packets”, and
“rte_data->available” maps to “the ... capacity”).
Allowing writing data ... in response to the size of the data packets ... being less than the ... capacity
(“In one embodiment, redundant traffic encoding is requested by application 104 ... The following example pseudo-code shows how the notification is enabled and what the notification callback looks like: ... if (rte_data && rte_data->available == tsc_bool_true) ... rte enabled notification on socket” (Herrero, 0049).
Here, “rte enabled notification” maps to “allowing writing data”, and
“rte_data && rte_data-> available” maps to “in response to the size of the data packets ... being less than the cache capacity”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Herrero’s practice of checking if there is available space in a buffer to send a message into the CAN network described in Yamamoto. It would be obvious to prevent writes to a buffer that is full and cannot accept new input data.
As to Claim 17:
The combination of Yamamoto and Aspel does not explicitly disclose:
Receiving configuration information of a configuration server
The configuration information comprises one of the following:
A cache capacity, indicating a maximum a size allowed to be written into the cache queue;
A database capacity, indicating a maximum size allowed to be written into the database; and
An uploading data amount, indicating a maximum size of data packets that are simultaneously uploaded
However, Herrero does teach:
Receiving configuration information of a configuration server
(“Server 116 [in Fig. 1], based on available memory resources, determines the buffer size N and informs client 106 through a TSCF service response” (Herrero, 0035).
Here, “determines the buffer size N and informs client 106” maps to “receiving configuration information”, and
“server 116” maps to “a configuration server”).
And from the list of:
The configuration information comprises one of the following:
A cache capacity, indicating a maximum a size allowed to be written into the cache queue;
A database capacity, indicating a maximum size allowed to be written into the database; and
An uploading data amount, indicating a maximum size of data packets that are simultaneously uploaded
Herrero at least teaches:
The configuration information comprises ... a cache capacity, indicating a maximum a size allowed to be written into the cache queue;
(“Server 116 [in Fig. 1], based on available memory resources, determines the buffer size N and informs client 106 through a TSCF service response” (Herrero, 0035).
Here, “the buffer size” maps to “the configuration information comprises ... a cache capacity, indicating a maximum a size allowed to be written into the cache queue ”).
The configuration information comprises ... a database capacity, indicating a maximum size allowed to be written into the database; and
(“Server 116 [in Fig. 1], based on available memory resources, determines the buffer size N and informs client 106 through a TSCF service response” (Herrero, 0035).
Here, “the buffer size” maps to “the configuration information comprises ... a database capacity, indicating a maximum size allowed to be written into the database ”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Herrero’s practice of setting a limit on the data allowed to be written into storage into the intra-vehicle network described in Yamamoto. Any real system will be comprised of finite resources, so it would be obvious to account for this when storing data.
As to Claim 19:
The combination of Yamamoto and Aspel does not explicitly disclose:
Receiving a cache capacity configured by a configuration server
Determining whether an idle position exists in the cache queue by comparing a size of data packets in the cache queue with the cache capacity
Allowing writing data into the cache queue in response to the size of the data packets in the cache queue being less than the cache capacity
However, Herrero does teach:
Receiving a cache capacity configured by a configuration server
(“Server 116 [in Fig. 1], based on available memory resources, determines the buffer size N and informs client 106 through a TSCF service response” (Herrero, 0035).
Here, “determines the buffer size N and informs client 106” maps to “receiving a cache capacity configured”, and
“server 116” maps to “a configuration server”).
Determining whether an idle position exists in the cache queue by comparing a size of data packets in the cache queue with the cache capacity
(“In one embodiment, redundant traffic encoding is requested by application 104 ... The following example pseudo-code shows how the notification is enabled and what the notification callback looks like: ... if (rte_data && rte_data->available == tsc_bool_true) ... rte enabled notification on socket” (Herrero, 0049).
Here, “if ... rte_data->available == tsc_bool_true” maps to “determining whether an idle position exists” because the rte uses a ring buffer so an idle position in that buffer exists if “rte_data->available” is true,
“==” maps to “comparing”,
“rte_data” maps to “a size of data packets in the cache queue”, and
“rte_data->available” maps to “the cache capacity”).
Allowing writing data into the cache queue in response to the size of the data packets in the cache queue being less than the cache capacity
(“In one embodiment, redundant traffic encoding is requested by application 104 ... The following example pseudo-code shows how the notification is enabled and what the notification callback looks like: ... if (rte_data && rte_data->available == tsc_bool_true) ... rte enabled notification on socket” (Herrero, 0049).
Here, “rte enabled notification” maps to “allowing writing data into the cache queue”, and
“rte_data && rte_data-> available” maps to “in response to the size of the data packets in the cache queue being less than the cache capacity”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Herrero’s practice of checking if there is available space in a buffer to send a message into the CAN network described in Yamamoto. It would be obvious to prevent writes to a buffer that is full and cannot accept new input data.
As to Claim 20:
Yamamoto teaches:
A database
(Fig. 2 in Yamamoto shows a vehicle control system.
Here, “MPFO Buffer 11” maps to “a database”).
The combination of Yamamoto and Aspel does not explicitly disclose:
Receiving a ... capacity configured by a configuration server
Determining whether an idle position exists ... by comparing a size of data packets ... with the ... capacity
Allowing writing data ... in response to the size of the data packets ... being less than the ... capacity
However, Herrero does teach:
Receiving a ... capacity configured by a configuration server
(“Server 116 [in Fig. 1], based on available memory resources, determines the buffer size N and informs client 106 through a TSCF service response” (Herrero, 0035).
Here, “determines the buffer size N and informs client 106” maps to “receiving a ... capacity configured”, and
“server 116” maps to “a configuration server”).
Determining whether an idle position exists ... by comparing a size of data packets ... with the ... capacity
(“In one embodiment, redundant traffic encoding is requested by application 104 ... The following example pseudo-code shows how the notification is enabled and what the notification callback looks like: ... if (rte_data && rte_data->available == tsc_bool_true) ... rte enabled notification on socket” (Herrero, 0049).
Here, “if ... rte_data->available == tsc_bool_true” maps to “determining whether an idle position exists” because the rte uses a ring buffer so an idle position in that buffer exists if “rte_data->available” is true,
“==” maps to “comparing”,
“rte_data” maps to “a size of data packets”, and
“rte_data->available” maps to “the ... capacity”).
Allowing writing data ... in response to the size of the data packets ... being less than the ... capacity
(“In one embodiment, redundant traffic encoding is requested by application 104 ... The following example pseudo-code shows how the notification is enabled and what the notification callback looks like: ... if (rte_data && rte_data->available == tsc_bool_true) ... rte enabled notification on socket” (Herrero, 0049).
Here, “rte enabled notification” maps to “allowing writing data”, and
“rte_data && rte_data-> available” maps to “in response to the size of the data packets ... being less than the cache capacity”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Herrero’s practice of checking if there is available space in a buffer to send a message into the CAN network described in Yamamoto. It would be obvious to prevent writes to a buffer that is full and cannot accept new input data.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamamoto (US 11,159,456 B2) in view of Aspel (US 2008/0154099 A1) and further in view of Otsuki et al. (US 2019/0164645 A1, hereinafter “Otsuki”).
As to Claim 4:
The combination of Yamamoto and Aspel does not explicitly disclose:
Receiving an uploading size configured by a configuration server
Using the uploading size as a limiting condition, to obtain the to-be-uploaded data packet set
A size of the to-be-uploaded data packet set is not greater than the uploading size
However, Otsuki does describe a method for a server to configure a medical device with a definition file that dictates parameters for the device’s uploads to the server.
Specifically, Otsuki teaches:
Receiving an uploading size configured by a configuration server
(“[I]t is preferable that the medical apparatus hold a definition file that defines a mode of the uploading, and a server side is permitted to freely update the definition file.... As shown in Fig. 5, the definition file includes data listed below.... File division: The file division indicates ... a maximum value of one divided file size” (Otsuki, 0004, 0053, 0057).
Here, “freely update” maps to “receiving”,
“a maximum value of one divided file size” maps to “an uploading size”,
“defines” maps to “configured by”, and
“a server” maps to “a configuration server”).
Using the uploading size as a limiting condition, to obtain the to-be-uploaded data packet set
(“[I]t is preferable that the medical apparatus hold a definition file that defines a mode of the uploading, and a server side is permitted to freely update the definition file.... As shown in Fig. 5, the definition file includes data listed below.... File division: The file division indicates ... a maximum value of one divided file size” (Otsuki, 0004, 0053, 0057).
Here, “a maximum value of one divided file size” maps to “using the uploading size as a limiting condition”, and
“uploading” maps to “obtain the to-be-uploaded data packet set”).
A size of the to-be-uploaded data packet set is not greater than the uploading size
(“[I]t is preferable that the medical apparatus hold a definition file that defines a mode of the uploading, and a server side is permitted to freely update the definition file.... As shown in Fig. 5, the definition file includes data listed below.... File division: The file division indicates ... a maximum value of one divided file size” (Otsuki, 0004, 0053, 0057).
Here, “a maximum value of one divided file size” maps to “a size of the to-be-uploaded data packet size is not greater than the uploading size”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the upload size limit described in Otsuki into the intra-vehicle communication network taught in Yamamoto. The upload limit can prevent the network from becoming too congested by presenting massive uploads.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamamoto (US 11,159,456 B2) in view of Aspel (US 2008/0154099 A1) and further in view of Pittman (US 9,712,427 B1, hereinafter “Pittman”).
As to Claim 5:
Yamamoto teaches:
The cache queue
(“Fig. 2 is a functional block diagram showing a functional configuration of the control apparatus 1” (Yamamoto col. 4, lines 2-3).
Here, “First Transmission Queue” 21a in Fig. 2 maps to “the cache queue”).
A database
(Fig. 2 in Yamamoto shows a vehicle control system.
Here, “MPFO Buffer 11” maps to “a database”).
The combination of Yamamoto and Aspel does not explicitly teach:
Invoking a ... thread through a reporting component to poll the data packets ... in response to an idle position existing in the ... queue, to obtain the to-be-added data packet set
Sending the to-be-added packet set to the reporting component through the ... thread, and adding the to-be-added data packet set to the ... queue through the reporting component
However, Pittman does describe methods to communicate via a fiber network.
Specifically, Pittman teaches:
Invoking a ... thread through a reporting component to poll the data packets ... in response to an idle position existing in the ... queue, to obtain the to-be-added data packet set
(“Operation 1207 can include a read thread that polls the socket and reads the available reply message into one or more buffers, which are then attached to the virtual connection. Depending upon the available buffer space, the read thread can read an entire reply message to one or more buffers or a portion of a reply message” (Pittman col. 32, lines 46-25).
Here, “a read thread that polls the socket” maps to “invoking a ... thread through a reporting component to poll the data packets”,
“depending upon the available buffer space” maps to “in response to an idle position existing in the ... queue”, and
“read” maps to “obtain the to-be-added data packet set”).
Sending the to-be-added packet set to the reporting component through the ... thread, and adding the to-be-added data packet set to the ... queue through the reporting component
(“Operation 1207 can include a read thread that polls the socket and reads the available reply message into one or more buffers, which are then attached to the virtual connection. Depending upon the available buffer space, the read thread can read an entire reply message to one or more buffers or a portion of a reply message” (Pittman col. 32, lines 46-25).
Here, “read an entire reply message” maps to “sending the to-be-added packet set to the reporting component”,
“a read thread” maps to “through the ... thread”, and
“read an entire reply message to one or more buffers” maps to “adding the to-be-added data packets set to the cache queue through the reporting component”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Pittman’s practice of polling for new packets when there is space in an output queue in the CAN network described in Yamamoto. If an output queue has available space, it makes sense to queue up new packets for it to send.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamamoto (US 11,159,456 B2) in view of Aspel (US 2008/0154099 A1) and Pittman (US 9,712,427 B1) and further in view of Qui et al. (US 2019/0332608 A1, hereinafter “Qui”).
As to Claim 6:
Yamamoto teaches:
The cache queue
(“Fig. 2 is a functional block diagram showing a functional configuration of the control apparatus 1” (Yamamoto col. 4, lines 2-3).
Here, “First Transmission Queue” 21a in Fig. 2 maps to “the cache queue”).
A database
(Fig. 2 in Yamamoto shows a vehicle control system.
Here, “MPFO Buffer 11” maps to “a database”).
Data packets in the database
(“The MPFO management unit 12 stores, in the MPFO buffer 11, a frame that each controller 20 receives from the corresponding network. The normal transmission unit 13 transmits the frame stored in the MPFO buffer 11 to the transmission queue 21 of the controller 20 corresponding to the network serving as a transfer destination” (Yamamoto col. 4, lines 24-29).
Here, “a frame” in “the MPFO buffer 11” maps to “data packets in the database”).
The combination of Yamamoto and Aspel does not explicitly disclose:
In response to the idle position existing in the ... queue
Invoking the ... thread through the reporting component
In the ... thread, sorting the data packets
However, Pittman does teach:
In response to the idle position existing in the ... queue
(“Operation 1207 can include a read thread that polls the socket and reads the available reply message into one or more buffers, which are then attached to the virtual connection. Depending upon the available buffer space, the read thread can read an entire reply message to one or more buffers or a portion of a reply message” (Pittman col. 32, lines 46-25).
Here, “depending upon the available buffer space” maps to “in response to an idle position existing in the ... queue”).
Invoking the ... thread through the reporting component
(“Operation 1207 can include a read thread that polls the socket and reads the available reply message into one or more buffers, which are then attached to the virtual connection. Depending upon the available buffer space, the read thread can read an entire reply message to one or more buffers or a portion of a reply message” (Pittman col. 32, lines 46-25).
Here, “a read thread that polls the socket” maps to “invoking the ... thread through the reporting component”).
The combination of Yamamoto, Aspel, and Pittman does not explicitly disclose:
Sorting the packets ... according to first warehousing timestamps of the data packets ... to obtain sorted data packets
Polling the sorted data packets to obtain K data packets, and determining the K data packets as the to-be-added data packet set
K is a positive integer
However, Qiu does describe methods to organize blockchain transactions.
Specifically, Qiu teaches:
Sorting the packets ... according to first warehousing timestamps of the data packets ... to obtain sorted data packets
(“[T]he timestamp in each piece of data may first be obtained, and a plurality of pieces of data may be sorted according to the order of the timestamps” (Qiu, 0110).
Here, “a plurality of pieces of data may be sorted” maps to “sorting the packets ... to obtain sorted data packets”,
“according to the order of the timestamps” maps to “according to first warehousing timestamps of the data packets”).
Polling the sorted data packets to obtain K data packets, and determining the K data packets as the to-be-added data packet set
(“[T]he first server cluster may sort the data of the leaf node, sequentially select a pre-determined number of pieces of data from the sorted data for placement into corresponding sub-leaf nodes, and set corresponding sub-node identifiers for the sub-leaf nodes” (Qiu, 0109).
Here, “select a pre-determined number of pieces of data from the sorted data” maps to “polling the sorted data packets to obtain K data packets”,
“select ... data from the sorted data for placement into corresponding sub-leaf nodes” maps to “determining the K data packets as the to-be-added data packet set”).
K is a positive integer
(“In one example, the pre-determined number of pieces of data may be three pieces” (Qiu, 0111).
Here, “the pre-determined number of pieces of data may be three” maps to “K is a positive integer”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Qiu’s method of sorting data before selecting a subset of it into the intra-vehicle CAN network described in Yamamoto. Sorting data gives it organization and context before it is operated on.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamamoto (US 11,159,456 B2) in view of Aspel (US 2008/0154099 A1) and further in view of Ma et al. (US 2017/0303159 A1, hereinafter “Ma”).
As to Claim 8:
Yamamoto teaches:
Adding the first data packet to the cache queue
(“The MPFO management unit 12 stores, in the MPFO buffer 11, a frame that each controller 20 receives from the corresponding network. The normal transmission unit 13 transmits the frame stored in the MPFO buffer 11 to the transmission queue 21 of the controller 20 corresponding to the network serving as a transfer destination” (Yamamoto col. 4, lines 24-29).
Here, “transmits the frame stored in the MPFO buffer 11 to the transmission queue 21” maps to “adding the first data packet to the cache queue”).
The combination of Yamamoto and Aspel does not explicitly disclose:
Accumulating a quantity of consecutive uploading failures of the first data packet, in response to the first data packet in the to-be-uploaded data packet set failing to be uploaded
Determining that the first data packet meets the continuous uploading failure condition, in response to the quantity of consecutive uploading failures reaching a count threshold
Determining that the first data packet does not meet the continuous uploading failure condition, in response to the quantity of consecutive uploading failures failing reaching the count threshold
Re-adding the first data packet to the cache queue through a reporting component
However, Ma does describe a method to dynamically adapt transmission parameters to the conditions of a wireless link.
Specifically, Ma teaches:
Accumulating a quantity of consecutive uploading failures of the first data packet, in response to the first data packet in the to-be-uploaded data packet set failing to be uploaded
(“Transmission of a MAC Protocol Data Unit (MPDU) may fail, for example, when a sender does not receive an acknowledgement (ACK) after a maximum number of retransmissions, e.g., based on a retry limit. Otherwise, a transmission may succeed” (Ma, 0100).
Here, “a maximum number of retransmissions” without “an acknowledgement (ACK)” map to “accumulating a quantity of consecutive uploading failures of the first data packet”, and
“does not receive an acknowledgement” maps to “in response to the first data packet in the to-be-uploaded data packet set failing to be uploaded”).
Determining that the first data packet meets the continuous uploading failure condition, in response to the quantity of consecutive uploading failures reaching a count threshold
(“Transmission of a MAC Protocol Data Unit (MPDU) may fail, for example, when a sender does not receive an acknowledgement (ACK) after a maximum number of retransmissions, e.g., based on a retry limit. Otherwise, a transmission may succeed” (Ma, 0100).
Here, “Transmission ... may fail” maps to “determining that the first data packet meets the continuous uploading failure condition”, and
“a maximum number of retransmissions ... based on a retry limit” maps to “in response to the quantity of consecutive uploading failures reaching a count threshold”).
Determining that the first data packet does not meet the continuous uploading failure condition, in response to the quantity of consecutive uploading failures failing reaching the count threshold
(“Transmission of a MAC Protocol Data Unit (MPDU) may fail, for example, when a sender does not receive an acknowledgement (ACK) after a maximum number of retransmissions, e.g., based on a retry limit. Otherwise, a transmission may succeed” (Ma, 0100).
Here, “otherwise, a transmission may succeed” (i.e. a case where “transmission” has not reached “a maximum number of retransmissions”) maps to “determining that the first data packet does not meet the continuous uploading failure condition”, and
“based on a retry limit” maps to “in response to the quantity of consecutive uploading failures failing reaching the count threshold”).
Re-adding the first data packet ... through a reporting component
(“Transmission of a MAC Protocol Data Unit (MPDU) may fail, for example, when a sender does not receive an acknowledgement (ACK) after a maximum number of retransmissions, e.g., based on a retry limit. Otherwise, a transmission may succeed” (Ma, 0100).
Here, “a retry” maps to “re-adding the first packet ... through a reporting component”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the retransmission limit described in Ma into the CAN network taught in Yamamoto. CAN messages can also benefit from a retransmission limit that prevents a copious amount of messages from flooding the network.
Claim(s) 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamamoto (US 11,159,456 B2) in view Aspel (US 2008/0154099 A1) and Pittman (9,712,427 B1) and further in view of Park et al. (US 2017/0085340 A1, hereinafter “Park”).
As to Claim 11:
Yamamoto teaches:
Adding the third data packet to the cache queue through a reporting component
(“The MPFO management unit 12 stores, in the MPFO buffer 11, a frame that each controller 20 receives from the corresponding network. The normal transmission unit 13 transmits the frame stored in the MPFO buffer 11 to the transmission queue 21 of the controller 20 corresponding to the network serving as a transfer destination” (Yamamoto col. 4, lines 24-29).
Here, “transmits the frame stored in the MPFO buffer 11 to the transmission queue 21” maps to “adding the third data packet to the cache queue through the reporting component”).
The combination of Yamamoto and Aspel does not explicitly teach:
Adding the third data packet ... in response to an idle position existing in the cache queue
However, Pittman does teach:
Adding the third data packet ... in response to an idle position existing in the cache queue
(“Operation 1207 can include a read thread that polls the socket and reads the available reply message into one or more buffers, which are then attached to the virtual connection. Depending upon the available buffer space, the read thread can read an entire reply message to one or more buffers or a portion of a reply message” (Pittman col. 32, lines 46-25).
Here, “read an entire reply message to one or more buffers” maps to “adding the third data packet”, and
“depending upon the available buffer space” maps to “in response to an idle position existing in the cache queue”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Pittman’s practice of polling for new packets when there is space in an output queue in the CAN network described in Yamamoto. If an output queue has available space, it makes sense to queue up new packets for it to send.
The combination of Yamamoto, Aspel, and Pittman also does not explicitly disclose:
Obtaining service data uploaded by a service layer, and performing packing processing on the serving data, to generate a third data packet
However, Park does describe a method to control a vehicle’s internal communication network.
Specifically, Park teaches:
Obtaining service data uploaded by a service layer, and performing packing processing on the serving data, to generate a third data packet
(“[T]he network managing unit 140 is operated to easily perform network resource management in order to support the communication of packets through the network fabric according to a global vehicle network communication protocol. Here, when there is a large amount of data, a compression algorithm may be used” (Park, 0040).
Here, “support the communication of packets through the network fabric” maps to “obtaining service data uploaded by a service layer”, and
“a compression algorithm may be used” maps to “performing packing processing on the serving data, to generate a third data packet”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the data compression described in Park into Yamamoto’s intra-vehicle network. Compression can help minimize the amount of traffic on the network, freeing bandwidth for other devices to communicate.
As to Claim 12:
The combination of Yamamoto and Aspel does not explicitly disclose:
Obtaining the service data uploaded by the service layer in a service thread, and sending the service data to the reporting component through the service thread
However, Pittman does teach:
Obtaining the service data uploaded by the service layer in a service thread, and sending the service data to the reporting component through the service thread
(“Operation 1207 can include a read thread that polls the socket and reads the available reply message into one or more buffers, which are then attached to the virtual connection. Depending upon the available buffer space, the read thread can read an entire reply message to one or more buffers or a portion of a reply message” (Pittman col. 32, lines 46-25).
Here, “a read thread that polls the socket and reads the available reply message” maps to “obtaining the service data uploaded by the service layer in a service thread”,
“reads the available reply message into one or more buffers” maps to “sending the service data to the reporting component”, and
“a read thread” maps to “the service thread”).
Thus, it would have been obvious to one of ordinary skill in the art to incorporate Pittman’s practice of using a thread to read in data into the intra-vehicle network described in Yamamoto. Using a thread to accept input data increase parallelization, making data processing faster and more efficient.
The combination of Yamamoto, Aspel, and Pittman also does not explicitly disclose:
Packing the service data based on the reporting component to generate the third data packet in response to a data amount of the service data meeting a packing condition
However, Park does teach:
Packing the service data based on the reporting component to generate the third data packet in response to a data amount of the service data meeting a packing condition
(“[T]he network managing unit 140 is operated to easily perform network resource management in order to support the communication of packets through the network fabric according to a global vehicle network communication protocol. Here, when there is a large amount of data, a compression algorithm may be used” (Park, 0040).
Here, “a compression algorithm may be used” on “a large amount of data” maps to “packing the service data based on the reporting component to generate the third data packet”, and
“when there is a large amount of data” maps to “in response to a data amount of the service data meeting a packing condition”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the data compression described in Park into Yamamoto’s intra-vehicle network. Compression can help minimize the amount of traffic on the network, freeing bandwidth for other devices to communicate.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamamoto (US 11,159,456 B2) in view of Aspel (US 2008/0154099 A1) and further in view of Johnson et al. (US 2007/0201362 A1, hereinafter “Johnson”).
As to Claim 15:
The combination of Yamamoto and Aspel does not explicitly disclose:
In response to the second data packet in the to-be-uploaded data packet set being successfully uploaded to an access layer, unpacking the second data packet by the access layer, and distributing the service data that is obtained through unpacking to the server
However, Johnson does describe methods to maximize the efficiency of limited physical bandwidth.
Specifically, Johnson teaches:
In response to the second data packet in the to-be-uploaded data packet set being successfully uploaded to an access layer, unpacking the second data packet by the access layer, and distributing the service data that is obtained through unpacking to the server
(“[A]pplications residing in the application layer 310 receive, generate, store, and transmit data 360 [in Fig. 3].... Media access layer applications are configured to encapsulate/unpack at least one packet 370 of at least one datagram 380” (Johnson, 0037).
Here, the “media access layer” that “receive[s] ... data 360” maps to “in response to the second data packet in the to-be-uploaded data packet set being successfully uploaded to an access layer”,
“unpack at least one packet 370” maps to “unpacking the second data packet ... and distributing service data that is obtained through unpacking”,
“access layer” maps to “an access layer”, and
“access layer applications” at destination node 300c in Fig. 3 map to “the server”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Johnson’s practice of unpacking data at the service layer into the vehicle control network described in Yamamoto. Compressing data for transmission and unpacking it when it’s received allows for succinct and efficient transmission of large volumes of data.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Benjamin Peter Welte whose telephone number is (703)756-5965. The examiner can normally be reached Monday - Friday, 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, Chirag Shah, can be reached at (571)272-3144. 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.
/B.P.W./Examiner, Art Unit 2477
/CHIRAG G SHAH/Supervisory Patent Examiner, Art Unit 2477