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 .
This office action is in response to communication filed on January 30, 2026.
Status of claims within the present application:
Claims 1 – 13 and 15 – 17 are pending.
Claims 1 – 2, 8, and 13 are amended.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 30, 2026 has been entered.
Response to Arguments
With regards to claims 1 – 13 and 15 – 17 that were rejected under 35 U.S.C. 103 as being unpatentable over US 20180177437 A1 to Yoshioka in view of US 20200184706 A1 to Speasl et al., (hereinafter, “Speasl”), applicant’s argument, see page [6 – 10] of applicant’s remarks, filed on January 30, 2026, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 – 2, 5 – 6, 8, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190044726 A1 to Macieira et al., (hereinafter, “Macieira”) in view of US 20190302766 A1 to Mondello et al., (hereinafter, “Mondello”).
Regarding claim 1, Macieira teaches a module comprising at least one sensor, a processor, and a memory unit, [Macieira, para. 25 discloses the cloud 100 may represent the Internet, or may be a local area network (LAN), or a wide area network (WAN), such as a proprietary network for a company. The IoT devices may include any number of different types of devices, grouped in various combinations. For example, a traffic control group 106 may include IoT devices along streets in a city. These IoT devices may include stoplights, traffic flow monitors, cameras, weather sensors, and the like. Para. 30 discloses the IoT device 250 may include a processor 252 (e.g., processing circuitry), which may be a microprocessor, a multi-core processor, a multithreaded processor, an ultra-low voltage processor, an embedded processor, or other known processing element. Para. 31 discloses he processor 252 may communicate with a system memory 254 over an interconnect 256 (e.g., a bus). Any number of memory devices may be used to provide for a given amount of system memory. As examples, the memory may be random access memory (RAM) in accordance with a Joint Electron Devices Engineering Council (JEDEC) design such as the DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4).] wherein: the at least one sensor is configured to obtain sensor data; [Macieira, para. 50 discloses the networking components 322A-D may include routers, data aggregators, compute devices, complex sensors, or other devices that are able to receive data from a sensor 312A-D, process the data, and transmit the data toward devices in the output layer 330 or offsite, such as to a cloud 324. The networking components 322A-D may include rules or other configuration information to control how to respond to input data received from the sensors 312A-D. In addition to performing data operations to the input sensor data, the networking components 322A-D may also timestamp the information, perform logging actions, tag data with signatures or other identifiers, or the like.] and the processor is configured to obtain a hash value of a payload; [Macieira, para. 68 discloses as each node senses data values, it stores the data values in respective entries in a Data Integrity Register (DIR). The DIR for a given node includes values sensed at that node, along with an integrity hash computed for each respective value. The integrity hash is a hash of the data. Optionally, the hash may be signed (e.g., encrypted) by the node.] and the processor is further configured to: and produce a data block comprising the obtained hash value, the obtained sensor data, and the generated signature that is separate from the obtained hash value; [Macieira, para. 79 discloses the sensor data, respective signatures of the sensor data, aggregate data, and hash value for the aggregate data are bundled in a data structure. Bundling refers to operations such as data concatenation, data packaging, data transformation, data aggregation, data formatting, or other data operations to store the sensor data, respective signatures, aggregate data, and hash value together. In an embodiment, the sensor data and the respective signatures of the sensor data are unmodified to allow the subscriber nodes to validate the sensor data using the respective signatures.] wherein the at least one sensor comprises a positioning sensor, and the obtained sensor data comprises a positioning information regarding a position of the module where the processor obtained the hash value [Macieira, para. 40 discloses the interconnect 256 may couple the processor 252 to an external interface 270 that is used to connect external devices or subsystems. The external devices may include sensors 272, such as accelerometers, level sensors, flow sensors, optical light sensors, camera sensors, temperature sensors, a global positioning system (GPS) sensors, pressure sensors, barometric pressure sensors, and the like. Para. 41 discloses a display or other output device 284 may be included to show information, such as sensor readings or actuator position. An input device 286, such as a touch screen or keypad may be included to accept input. An output device 284 may include any number of forms of audio or visual display, including simple visual outputs such as binary status indicators (e.g., LEDs) and multi-character visual outputs, or more complex outputs such as display screens (e.g., LCD screens), with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the IoT device 250.], But Macieira does not teach generate a signature of the obtained hash value and the obtained sensor data using a signature key stored in the memory unit.
However, Mondello does teach generate a signature of the obtained hash value and the obtained sensor data using a signature key stored in the memory unit. [Mondello, para. 25 discloses a secret key can be used to sign a hash of the stored sensor data to generate a signature. To verify whether the sensor data in the storage device 112 has been altered, the secret key can be applied to a hash of the current data stored in the storage device 112 to generate a current signature for comparison with the signature created at the time of the recordation of the sensor data.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Mondello’s system with Macieira’s system, with a motivation to create authenticity verification data that can be used to verify the authenticity of the sensor data stored in the storage device 112. [Mondello, para. 25]
As per claim 2, modified Macieira teaches the module according to claim 1, wherein the at least one sensor further comprises at least one of the following: a time sensor, wherein the obtained sensor data further comprises a time information regarding a time at which the processor obtained the hash value, [Macieira, para. 50 discloses the networking components 322A-D may include rules or other configuration information to control how to respond to input data received from the sensors 312A-D. In addition to performing data operations to the input sensor data, the networking components 322A-D may also timestamp the information, perform logging actions, tag data with signatures or other identifiers, or the like.] or an environmental sensor, wherein the obtained sensor data further comprises an environmental information regarding an environmental parameter determined by the environmental sensor when the processor obtained the hash value. [Macieira, para. 22 discloses many different devices may contribute to a single aggregated packet of information that may then be passed on to a single receiver (e.g., actuator, controller, etc.) that performs a function based on the aggregate value. For example, an industrial park region may have environmental sensors that measure toxic and non-toxic gases, particulates, humidity, or temperature. An aggregate measurement may be computed by a concentrator sensor, for example, by taking the mean, mode, or median of discrete measurements. Other data functions may be used instead of central tendency functions, such as selecting a maximum or minimum value from the discrete measurements, performing statistical analysis, or the like. The concentrator sensor forwards to other monitoring nodes or controller nodes.]
As per claim 5, modified Macieira teaches the module according to claim 1, wherein the positioning information comprises information related to at least one of a source of the positioning information or a type of raw data of the positioning information from which a position of the module is obtained. [Macieira, para. 40 discloses the interconnect 256 may couple the processor 252 to an external interface 270 that is used to connect external devices or subsystems. The external devices may include sensors 272, such as accelerometers, level sensors, flow sensors, optical light sensors, camera sensors, temperature sensors, a global positioning system (GPS) sensors, pressure sensors, barometric pressure sensors, and the like. Para. 27 discloses a group of IoT devices (e.g., the traffic control group 106) may request a current weather forecast from a group of remote weather stations 114, which may provide the forecast without human intervention. Further, an emergency vehicle 124 may be alerted by an automated teller machine 120 that a burglary is in progress. As the emergency vehicle 124 proceeds towards the automated teller machine 120, it may access the traffic control group 106 to request clearance to the location, for example, by lights turning red to block cross traffic at an intersection in sufficient time for the emergency vehicle 124 to have unimpeded access to the intersection.]
As per claim 6, modified Macieira teaches the module according to claim 1, further comprising a transmitter, wherein the transmitter is configured to transmit the produced data block to a server. [Macieira, para. 79 discloses the sensor data, respective signatures of the sensor data, aggregate data, and hash value for the aggregate data are bundled in a data structure. Para. 80 discloses the data structure is exposed to subscriber nodes on the IoT network. The data may be exposed by providing accessibility to the data, such as by way of access control list (ACL), access control entry (ACE), or policy controls. In an embodiment, the data structure is organized to reflect a network topology of the IoT network.]
Regarding claim 8, it recites features similar to features within claim 1, therefore, it is rejected in a similar manner.
Regarding claim 13, it recites features similar to features within claim 1, therefore, it is rejected in a similar manner.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over US 20190044726 A1 to Macieira et al., (hereinafter, “Macieira”) in view of US 20190302766 A1 to Mondello et al., (hereinafter, “Mondello”) in further view of US 20180177437 A1 to Yoshioka and US 20200184706 A1 to Speasl et al., (hereinafter, “Speasl”).
Regarding claim 3, modified Macieira teaches the module according to claim 2, but modified Macieira does not teach wherein the time information obtained by the time sensor comprises at least one of the following: a Coordinated Universal Time, UTC, tracked by the time sensor in the module, a time information obtained by the time sensor from a mobile communication network based on 3GPP standards, a time information obtained by the time sensor from a global navigation satellite system constellation, or time metadata, in case the time sensor comprises a Temperature Compensated Crystal Oscillator, (TCXO), comprising information regarding a model of the TCXO.
However, Yoshioka does teach wherein the time information obtained by the time sensor comprises at least one of the following: a Coordinated Universal Time, UTC, tracked by the time sensor in the module, [Yoshioka, para. 144 discloses the kinds of firmware FW1 to FWm perform processing for acquiring the sensor signals, for example, at a frequency corresponding to an output rate of the sensors and storing (outputting) the sensor signals in association with acquisition time information. The acquisition time information may be absolute time such as UTC (Coordinated Universal Time) or JST (Japan Standard Time) or may be information such as a timestamp.] or time metadata, in case the time sensor comprises a Temperature Compensated Crystal Oscillator, (TCXO), comprising information regarding a model of the TCXO. [Yoshioka, para. 71 discloses The external oscillator 160 may be, for example, an oscillator used for processing (frequency conversion) of a GNSS signal in the RF circuit. Specifically, a TCXO (Temperature Compensated Crystal Oscillator) having high accuracy is used as the external oscillator 160. The internal oscillator 116 is, for example, a ring oscillator.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Yoshioka’s system with modified Macieira’s system, with a motivation for the clock-frequency control section 1155 performs, on the basis of at least one of a biological signal, a satellite signal, and an environment signal, control for changing a clock frequency of a clock signal supplied to the processing section 112. In a narrow sense, the clock-frequency control section 1155 performs control for changing an oscillation frequency of the internal oscillator 116. [Yoshioka, para. 72]
However, modified Macieira in view of Yoshioka does not teach wherein the time information obtained by the time sensor comprises at least one of the following: a time information obtained by the time sensor from a mobile communication network based on 3GPP standards, a time information obtained by the time sensor from a global navigation satellite system constellation, but Speasl does teach wherein the time information obtained by the time sensor comprises at least one of the following: a time information obtained by the time sensor from a mobile communication network based on 3GPP standards, [Speasl, para. 93 discloses the digital media capture device can first synchronize its image and/or sensor data with a second device, such as a mobile device 760 and/or a base station 410/415. For example, a camera of a UAV 110 or sensor payload device 120 may first synchronize its data with a user mobile device 760 (e.g., a smartphone or wearable device) or a base station 410/415, which can then transmit the certified digital media to the internet 720 and server(s) 725 of the cloud system. Other devices, such as handheld digital cameras, body cameras, and binoculars may include the digital media capture device, and/or in some cases may connect with the server(s) 725.] a time information obtained by the time sensor from a global navigation satellite system constellation, [Speasl, para. 19 discloses Media data may include geospatial data, images, videos, audio, IR, laser rangefinder data, GNSS data, LIDAR data, RADAR data, SONAR data, accelerometer data, gyroscope data, or data from any other sensor discussed herein. Para. 120 discloses These may also include Global Navigation Satellite System (GNSS) receivers or transceivers that are used to determine a location of the computing system 900 based on receipt of one or more signals from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, the US-based Global Positioning System (GPS), the Russia-based Global Navigation Satellite System (GLONASS), the China-based BeiDou Navigation Satellite System (BDS), and the Europe-based Galileo GNSS. Input devices 960 may include receivers or transceivers corresponding to one or more of these GNSS systems]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Speasl’s system with modified Macieira’s system, with a motivation for all data (e.g., media asset and/or additional data and/or metadata) can, in some embodiments, be secured in a local database with a globally unique identifier to ensure its integrity. The asset's security and integrity can be ensured via a Digital Signature that is made up of a SHA1 digest, the time that the asset was captured and the device of origin. This allows the mobile app or server to detect changes due to storage or transmission errors as well as any attempt to manipulate or change the content of the asset. The Digital Signature can be encrypted with a public/private key-pair that is generated uniquely for that asset by the media capture device [Speasl, para. 86]
Claims 4, 7, 9 – 12, and 15 – 17 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190044726 A1 to Macieira et al., (hereinafter, “Macieira”) in view of US 20190302766 A1 to Mondello et al., (hereinafter, “Mondello”) in further view of US 20200184706 A1 to Speasl et al., (hereinafter, “Speasl”).
Regarding claim 4, modified Macieira teaches the module according to claim 1, but modified Macieira does not teach wherein the positioning information comprises at least one of the following: 2-dimensional or 3-dimensional positioning coordinates, or raw data of a position of the module from which 2-dimensional or 3-dimensional positioning coordinates are derivable.
However, Speasl does teach wherein the positioning information comprises at least one of the following: 2-dimensional or 3-dimensional positioning coordinates, or raw data of a position of the module from which 2-dimensional or 3-dimensional positioning coordinates are derivable. [Speasl, para. 88 discloses metadata may include, for example, time, location, media capture, orientation, media size, resolution, frame size, elevations, centimeter 3D GPS position, UAV speed, flight path over the property with media overlap settings, heading, airspeed, and various navigational invomation from the UAV 110 and/or from the sensor payload device 120. Para. 19 discloses The payload device records media data using one or more cameras and/or other sensors as well as geospatial data (such as locations) via positioning sensors and other sensors. Media data may include geospatial data, images, videos, audio, IR, laser rangefinder data, GNSS data, LIDAR data, RADAR data, SONAR data, accelerometer data, gyroscope data, or data from any other sensor discussed herein. The media data and geospatial data may be first verified as genuine via a media certification process and then used to generate a 3D representation of at least part of a property, such as a building.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Speasl’s system with modified Macieira’s system, with a motivation for all data (e.g., media asset and/or additional data and/or metadata) can, in some embodiments, be secured in a local database with a globally unique identifier to ensure its integrity. The asset's security and integrity can be ensured via a Digital Signature that is made up of a SHA1 digest, the time that the asset was captured and the device of origin. This allows the mobile app or server to detect changes due to storage or transmission errors as well as any attempt to manipulate or change the content of the asset. The Digital Signature can be encrypted with a public/private key-pair that is generated uniquely for that asset by the media capture device [Speasl, para. 86]
Regarding claim 7, modified Macieira teaches the module according to claim 1, but modified Macieira does not teach wherein the produced data block further comprises an identifier of the module.
However, Speasl does teach wherein the produced data block further comprises an identifier of the module. [Speasl, para. 86 discloses all data (e.g., media asset and/or additional data and/or metadata) can, in some embodiments, be secured in a local database with a globally unique identifier to ensure its integrity. The asset's security and integrity can be ensured via a Digital Signature that is made up of a SHA1 digest, the time that the asset was captured and the device of origin. This allows the mobile app or server to detect changes due to storage or transmission errors as well as any attempt to manipulate or change the content of the asset. The Digital Signature can be encrypted with a public/private key-pair that is generated uniquely for that asset by the media capture device.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Speasl’s system with modified Macieira’s system, with a motivation for all data (e.g., media asset and/or additional data and/or metadata) can, in some embodiments, be secured in a local database with a globally unique identifier to ensure its integrity. The asset's security and integrity can be ensured via a Digital Signature that is made up of a SHA1 digest, the time that the asset was captured and the device of origin. This allows the mobile app or server to detect changes due to storage or transmission errors as well as any attempt to manipulate or change the content of the asset. The Digital Signature can be encrypted with a public/private key-pair that is generated uniquely for that asset by the media capture device [Speasl, para. 86]
Regarding claim 9, modified Macieira teaches the method according to claim 8, but Macieira does not teach further comprising: transmitting, by a transmitter of the module, the produced data block to a server, wherein the server certifies the coupling of the obtained hash value of the payload and the sensor data obtained by the at least one sensor by verifying the data block signature with a verification key corresponding to the signature key used by the module.
However, Speasl does teach further comprising: transmitting, by a transmitter of the module, the produced data block to a server, wherein the server certifies the coupling of the obtained hash value of the payload and the sensor data obtained by the at least one sensor by verifying the data block signature with a verification key corresponding to the signature key used by the module. [Speasl, para. 87 discloses the sensor payload device 120 and/or UAV 110 and/or a second device that receives the media asset from the sensor payload device 120 and/or UAV 110 may then generate a public and private key pair using a public key infrastructure (PKI), where the keys may be for example RSA 1024 bit keys. The private key is used to encrypt the digital signature, and may then be deleted, erased, and/or destroyed, in some cases via overwriting for more security. The certified media asset—meaning the media asset, the encrypted digital signature, and the (optionally encrypted) metadata—are uploaded to the cloud severs 725, in some cases along with the public key, optionally securely via HTTPS or another secure network transfer protocol. The public key may be uploaded to the same cloud server(s) 725 or to a different system, such as a certificate authority (CA) server.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Speasl’s system with Macieira’s system, with a motivation for all data (e.g., media asset and/or additional data and/or metadata) can, in some embodiments, be secured in a local database with a globally unique identifier to ensure its integrity. The asset's security and integrity can be ensured via a Digital Signature that is made up of a SHA1 digest, the time that the asset was captured and the device of origin. This allows the mobile app or server to detect changes due to storage or transmission errors as well as any attempt to manipulate or change the content of the asset. The Digital Signature can be encrypted with a public/private key-pair that is generated uniquely for that asset by the media capture device [Speasl, para. 86]
Regarding claim 10, modified Macieira teaches the method according to claim 8, but Macieira does not teach wherein at least one of the following applies: the signature key is provided to the module by a trusted entity, or the signature key is provided to the module at a time of production of the module.
However, Speasl does teach wherein at least one of the following applies: the signature key is provided to the module by a trusted entity, or the signature key is provided to the module at a time of production of the module. [Speasl, para. 87 discloses the sensor payload device 120 and/or UAV 110 and/or a second device that receives the media asset from the sensor payload device 120 and/or UAV 110 may then generate a public and private key pair using a public key infrastructure (PKI), where the keys may be for example RSA 1024 bit keys. The private key is used to encrypt the digital signature, and may then be deleted, erased, and/or destroyed, in some cases via overwriting for more security. The certified media asset—meaning the media asset, the encrypted digital signature, and the (optionally encrypted) metadata—are uploaded to the cloud severs 725, in some cases along with the public key, optionally securely via HTTPS or another secure network transfer protocol. The public key may be uploaded to the same cloud server(s) 725 or to a different system, such as a certificate authority (CA) server. The media asset and its metadata are now certified. Any server 725 or client 730 can retrieve the public key from the cloud server 725 system or CA server and decrypt the encrypted digital signature to verify that it matches a new hash generated using media asset and/or metadata at a later time, thereby verifying that the media asset and metadata have not been changed since certification.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Speasl’s system with Macieira’s system, with a motivation for all data (e.g., media asset and/or additional data and/or metadata) can, in some embodiments, be secured in a local database with a globally unique identifier to ensure its integrity. The asset's security and integrity can be ensured via a Digital Signature that is made up of a SHA1 digest, the time that the asset was captured and the device of origin. This allows the mobile app or server to detect changes due to storage or transmission errors as well as any attempt to manipulate or change the content of the asset. The Digital Signature can be encrypted with a public/private key-pair that is generated uniquely for that asset by the media capture device [Speasl, para. 86]
Regarding claim 11, modified Macieira teaches the method according to claim 10, but Macieira does not teach wherein at least one of the following applies: a verification key corresponding to the signature key used by the module is provided to the server by a trusted entity, or the verification key corresponding to the signature key used by the module is provided to the server at a time of production of the module.
However, Speasl does teach wherein at least one of the following applies: a verification key corresponding to the signature key used by the module is provided to the server by a trusted entity, or the verification key corresponding to the signature key used by the module is provided to the server at a time of production of the module. [Speasl, para. 87 discloses the certified media asset—meaning the media asset, the encrypted digital signature, and the (optionally encrypted) metadata—are uploaded to the cloud severs 725, in some cases along with the public key, optionally securely via HTTPS or another secure network transfer protocol. The public key may be uploaded to the same cloud server(s) 725 or to a different system, such as a certificate authority (CA) server. The media asset and its metadata are now certified. Any server 725 or client 730 can retrieve the public key from the cloud server 725 system or CA server and decrypt the encrypted digital signature to verify that it matches a new hash generated using media asset and/or metadata at a later time, thereby verifying that the media asset and metadata have not been changed since certification.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Speasl’s system with Macieira’s system, with a motivation for all data (e.g., media asset and/or additional data and/or metadata) can, in some embodiments, be secured in a local database with a globally unique identifier to ensure its integrity. The asset's security and integrity can be ensured via a Digital Signature that is made up of a SHA1 digest, the time that the asset was captured and the device of origin. This allows the mobile app or server to detect changes due to storage or transmission errors as well as any attempt to manipulate or change the content of the asset. The Digital Signature can be encrypted with a public/private key-pair that is generated uniquely for that asset by the media capture device [Speasl, para. 86]
Regarding claim 12, modified Macieira teaches a system comprising a module according to claim 1 and a server, but Macieira does not teach wherein: the module is configured to transmit the produced data block to the server; the server is configured to receive the data block from the module; and the server is further configured to determine the coupling of the hash value of the payload obtained by the module and the sensor data obtained by the at least one sensor of the module by verifying the data block signature with a verification key corresponding to the signature key used by the module.
However, Speasl does teach wherein: the module is configured to transmit the produced data block to the server; the server is configured to receive the data block from the module; [Speasl, para. 87 discloses the sensor payload device 120 and/or UAV 110 and/or a second device that receives the media asset from the sensor payload device 120 and/or UAV 110 may then generate a public and private key pair using a public key infrastructure (PKI), where the keys may be for example RSA 1024 bit keys. The private key is used to encrypt the digital signature, and may then be deleted, erased, and/or destroyed, in some cases via overwriting for more security. The certified media asset—meaning the media asset, the encrypted digital signature, and the (optionally encrypted) metadata—are uploaded to the cloud severs 725, in some cases along with the public key, optionally securely via HTTPS or another secure network transfer protocol. The public key may be uploaded to the same cloud server(s) 725 or to a different system, such as a certificate authority (CA) server.] and the server is further configured to determine the coupling of the hash value of the payload obtained by the module and the sensor data obtained by the at least one sensor of the module by verifying the data block signature with a verification key corresponding to the signature key used by the module. [Speasl, para. 87 discloses the certified media asset—meaning the media asset, the encrypted digital signature, and the (optionally encrypted) metadata—are uploaded to the cloud severs 725, in some cases along with the public key, optionally securely via HTTPS or another secure network transfer protocol. The public key may be uploaded to the same cloud server(s) 725 or to a different system, such as a certificate authority (CA) server. The media asset and its metadata are now certified. Any server 725 or client 730 can retrieve the public key from the cloud server 725 system or CA server and decrypt the encrypted digital signature to verify that it matches a new hash generated using media asset and/or metadata at a later time, thereby verifying that the media asset and metadata have not been changed since certification.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Speasl’s system with Macieira’s system, with a motivation for all data (e.g., media asset and/or additional data and/or metadata) can, in some embodiments, be secured in a local database with a globally unique identifier to ensure its integrity. The asset's security and integrity can be ensured via a Digital Signature that is made up of a SHA1 digest, the time that the asset was captured and the device of origin. This allows the mobile app or server to detect changes due to storage or transmission errors as well as any attempt to manipulate or change the content of the asset. The Digital Signature can be encrypted with a public/private key-pair that is generated uniquely for that asset by the media capture device [Speasl, para. 86]
Regarding claim 15, modified Macieira teaches the module of claim 1, but Macieira does not teach wherein the data block does not include the payload.
However, Speasl does teach wherein the data block does not include the payload. [Speasl, para. 87 discloses the sensor payload device 120 also generates and/or extracts metadata (e.g., EXIF metadata) corresponding to this captured media asset, for example identifying the sensor payload device 120 and/or the UAV 110, a timestamp of capture, a date of capture, an author or owner of the sensor payload device 120 and/or UAV 110, and any other metadata.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Speasl’s system with Macieira’s system, with a motivation for all data (e.g., media asset and/or additional data and/or metadata) can, in some embodiments, be secured in a local database with a globally unique identifier to ensure its integrity. The asset's security and integrity can be ensured via a Digital Signature that is made up of a SHA1 digest, the time that the asset was captured and the device of origin. This allows the mobile app or server to detect changes due to storage or transmission errors as well as any attempt to manipulate or change the content of the asset. The Digital Signature can be encrypted with a public/private key-pair that is generated uniquely for that asset by the media capture device [Speasl, para. 86]
Regarding claim 16, it recites features similar to features within claim 15, therefore, it is rejected in a similar manner.
Regarding claim 17, it recites features similar to features within claim 15, therefore, it is rejected in a similar manner.
Conclusion
Pertinent prior art made of record however not relied upon:
US 20200007331 A1 to Wentz
“A method of authenticating sensor data includes receiving, by at least a temporal attester, sensor data, calculating, by the at least a temporal attester, a current time, generating, by the at least a temporal attester, a secure timestamp generated as a function of the current time, and transmitting, by the at least a temporal attester and to at least a verifier, a temporally attested sensor signal including the secure timestamp.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Phuc Pham whose telephone number is (571)272-8893. The examiner can normally be reached Monday - Thursday 7:30 AM - 4:30 PM; Friday 8:00 AM - 12:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached at (571) 270-5440. 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.
/P.P./Patent Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408