Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 – 4, 6 – 17 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1- 15, 17 – 21, 23 – 27 of U.S. Patent No. 12141286. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application claims 1 – 4, 6 – 17 are anticipated by said patent claims.
Instant App. 18941717
Patent #: 12141286
1. A device, comprising: memory including an embedded hardware security module; and one or more components configured to: determine first ownership metadata based on first ownership data associated with the device; split the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; store, in the memory of the device, the first portion of first ownership metadata; and transmit, to a server, the second portion of first ownership metadata for storage in a blockchain ledger of a blockchain node.
2. The device of claim 1, wherein the first ownership data identifies the device or identifies a first owner of the device.
3. The device of claim 1, wherein a chain of ownership, indicating owners of the device during a lifespan of the device, is established based on a combination of: the first portion of first ownership metadata stored in the memory of the device, and the second portion of first ownership metadata stored in the blockchain ledger.
4. The device of claim 1, wherein the first portion of first ownership metadata is stored separately from the blockchain ledger.
6. The device of claim 1, wherein the one or more components are further configured to: encrypt, using symmetric or asymmetric key based encryption, the first portion of first ownership metadata prior to storage in the memory of the device; and encrypt, using symmetric or asymmetric key based encryption, the second portion of first ownership metadata prior to storage in the blockchain ledger.
7. The device of claim 1, wherein the one or more components are further configured to: generate an alert based on being unable to combine the first portion of first ownership metadata and the second portion of first ownership metadata, wherein the alert is associated with a modification to the first portion of first ownership metadata or to the second portion of first ownership metadata.
8. The device of claim 1, wherein the first ownership data includes an intrinsic property of the embedded hardware security module.
9. A server, comprising: one or more components configured to: receive, from a device that includes memory with an embedded hardware security module, first ownership metadata associated with the device; split the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; transmit, to the device, the first portion of first ownership metadata for storage in the memory of the device; and transmit the second portion of first ownership metadata for storage in a blockchain ledger of a blockchain node.
10. The server of claim 9, wherein a chain of ownership, indicating owners of the device during a lifespan of the device, is established based on a combination of: the first portion of first ownership metadata stored in the memory of the device, and the second portion of first ownership metadata stored in the blockchain ledger.
11. The server of claim 9, wherein the first ownership data identifies the device or identifies a first owner of the device.
12. A method, comprising: generating, by a device that includes memory with an embedded hardware security module, first ownership metadata based on first ownership data received during a registration process; splitting, by the device, the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; storing, in the memory of the device, the first portion of first ownership metadata; and transmitting, by the device to a server, the second portion of first ownership metadata for storage in a blockchain ledger of a blockchain node.
13. The method of claim 12, further comprising: receiving, by the device from the server, a secure key for decrypting the first portion of first ownership metadata and the second portion of first ownership metadata.
14. The method of claim 13, further comprising: decrypting, using the secure key, the first portion of first ownership metadata upon retrieval from the memory and the second portion of first ownership metadata upon retrieval from the blockchain ledger.
15. The method of claim 12, further comprising: registering, by the device, a first owner of the device during an initial ownership establishment, wherein the first ownership data comprises a unique identity of the first owner.
16. The method of claim 12, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership metadata such that the first portion of first ownership metadata and the second portion of first ownership metadata are only combinable with each other.
17. The method of claim 12, wherein storing the first portion of first ownership metadata in the memory further comprises: writing, by the device, the first portion of first ownership metadata to a section of the memory that is non-erasable and cryptographically protected.
1. A device, comprising: memory including an embedded hardware security module; and one or more components configured to: determine first ownership metadata based on first ownership data associated with the device, wherein the first ownership data is associated with a first owner of the device; split the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; store, in the memory of the device, the first portion of first ownership metadata; transmit, to a server, the second portion of first ownership metadata for storage in a blockchain ledger of a blockchain node, wherein a chain of ownership associated with the device is established based on a combination of the first portion of first ownership metadata stored in the memory of the device and the second portion of first ownership metadata stored in the blockchain ledger; transmit, to the server, a request to verify the chain of ownership associated with the device; receive, from the server and based on the request, the second portion of first ownership metadata; combine the first portion of first ownership metadata with the second portion of first ownership metadata to form the first ownership metadata, based on a determination that the first portion of first ownership metadata is able to be combined with the second portion of first ownership metadata; and derive the first ownership data based on the first ownership metadata.
2. The device of claim 1, wherein the one or more components are further configured to: output, via a user interface, an indication of the first ownership data, wherein the indication indicates a verifiable identity of the first owner of the device.
3. The device of claim 1, wherein the one or more components are further configured to: determine that the first portion of first ownership metadata is able to be combined with the second portion of first ownership metadata based on a determination that the first portion of first ownership metadata has not been modified, while stored in the memory of the device, and based on a determination that the second portion of first ownership metadata has not been modified, while stored in the blockchain ledger.
4. The device of claim 1, wherein the one or more components are further configured to: determine second ownership metadata based on second ownership data associated with the device, wherein the second ownership data is associated with a second owner of the device; split the second ownership metadata into a first portion of second ownership metadata and a second portion of second ownership metadata, wherein the first portion of second ownership metadata is correlated with the second portion of second ownership data; store, in the memory of the device, the first portion of second ownership metadata; and transmit, to the server, the second portion of second ownership metadata for storage in the blockchain ledger.
5. The device of claim 4, wherein the one or more components are further configured to: receive, from the server and based on the request, the second portion of first ownership metadata and the second portion of second ownership metadata; combine the first portion of first ownership metadata and the first portion of second ownership metadata, stored in the memory of the device, with the second portion of first ownership metadata and the second portion of second ownership metadata, respectively, to form the first ownership metadata and the second ownership metadata; derive the first ownership data and the second ownership data based on the first ownership metadata and the second ownership metadata, respectively; and output, via a user interface, an indication of the first ownership data and the second ownership data, wherein the indication indicates verifiable identities of the first owner and the second owner of the device.
6. The device of claim 1, wherein the first ownership data includes one or more of: an intrinsic device property identifier, a device identifier, a manufacturer code, or a unique owner identity, and wherein the first ownership metadata is a hash of the first ownership data.
7. The device of claim 1, wherein the one or more components are further configured to: encrypt, by the device, the first portion of first ownership metadata and the second portion of first ownership metadata, prior to storage in the memory of the device and in the blockchain ledger, respectively.
8. The device of claim 7, wherein the one or more components are further configured to: decrypt, by the device, the first portion of first ownership metadata and the second portion of first ownership metadata, prior to combining the first portion of first ownership metadata with the second portion of first ownership metadata to form the first ownership metadata.
9. The device of claim 1, wherein the server and the blockchain ledger are associated with one or more of: a manufacturer of the memory with the embedded hardware security module, or a manufacturer of the device that comprises the memory with the embedded hardware security module.
10. A server, comprising: one or more hardware processors and one or more memories configured to: receive, from a device that includes memory with an embedded hardware security module, first ownership metadata, wherein the first ownership metadata is based on first ownership data associated with the device, and wherein the first ownership data is associated with a first owner of the device; split the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; transmit, to the device, the first portion of first ownership metadata for storage in the memory of the device, wherein the first portion of first ownership metadata is encrypted by the server prior to storage in the memory of the device; and transmit the second portion of first ownership metadata for storage in a blockchain ledger of a blockchain node, wherein a chain of ownership associated with the device is verifiable based on the first portion of first ownership metadata stored in the memory of the device and the second portion of first ownership metadata stored in the blockchain ledger, and wherein the second portion of first ownership metadata is encrypted by the server prior to storage in the blockchain ledger.
11. The server of claim 10, wherein the one or moreare further configured to: receive, from the device, a request to verify the chain of ownership associated with the device, wherein the request indicates the first portion of first ownership metadata; receive, from the blockchain ledger and based on the request, the second portion of first ownership metadata; combine the first portion of first ownership metadata with the second portion of first ownership metadata to form the first ownership metadata, based on a determination that the first portion of first ownership metadata is able to be combined with the second portion of first ownership metadata; derive the first ownership data based on the first ownership metadata; and transmit, to the device, for display via a user interface of the device, an indication of the first ownership data, wherein the indication indicates a verifiable identity of the first owner of the device.
12. The server of claim 11, wherein the one or morefirst portion of first ownership metadata is able to be combined with the second portion of first ownership metadata based on a determination that the first portion of first ownership metadata has not been modified, while stored in the memory of the device, and based on a determination that the second portion of first ownership metadata has not been modified, while stored in the blockchain ledger.
13. The server of claim 10, wherein the one or moresecond ownership metadata, wherein the first portion of second ownership metadata is correlated with the second portion of second ownership data; transmit, to the device, the first portion of second ownership metadata for storage in the memory of the device; and transmit the second portion of second ownership metadata for storage in the blockchain ledger. 14. The server of claim 13, wherein the one or moreof first ownership metadata and the second portion of second ownership metadata, respectively, to form the first ownership metadata and the second ownership metadata; derive the first ownership data and the second ownership data based on the first ownership metadata and the second ownership metadata, respectively; and transmit, to the device for display via a user interface of the device, an indication of the first ownership data and the second ownership data, wherein the indication indicates verifiable identities of the first owner and the second owner of the device.
15. The server of claim 10, wherein the first ownership data includes one or more of: an intrinsic device property identifier, a device identifier, a manufacturer code, or a unique owner identity, and wherein the first ownership metadata is derived from the first ownership data.
16. (Canceled Herein).
17. The server of claim 10, wherein the one or moreprocessors and the one or more memories are further configured to: decrypt, by the server, the first portion of first ownership metadata and the second portion of first ownership metadata, prior to combining the first portion of first ownership metadata with the second portion of first ownership metadata to form the first ownership metadata.
18. The server of claim 10, wherein a block of the blockchain ledger is configured to store initial metadata associated with the memory, manufacturer metadata, the second portion of first ownership metadata associated with the first owner, and additional portions of additional ownership metadata associated with additional owners of the device.
19. A method, comprising: receiving, by a device that includes memory with an embedded hardware security module and during a registration process, first ownership data associated with a first owner of the device, wherein the first ownership data includes an intrinsic property of the memory; transmitting, to a server, the first ownership data; receiving, from the server, an indication that the first ownership data has been verified; generating, by the device, first ownership metadata based on the first ownership data and based on the indication that the first ownership data has been verified; splitting, by the device, the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is cross referenced with the second portion of first ownership data; storing, in the memory of the device, the first portion of first ownership metadata; transmitting, by the device to the server, the second portion of first ownership metadata for storage in a blockchain ledger of a blockchain node; and receiving, via a user interface of the device, a request to verify a chain of ownership associated with the device, wherein the chain of ownership associated with the device is verifiable based on the first portion of first ownership metadata stored in the memory of the device and the second portion of first ownership metadata stored in the blockchain ledger.
20. The method of claim 19, further comprising: receiving, from the server and based on the request, the second portion of first ownership metadata; determining that the first portion of first ownership metadata, stored in the memory of the device, is able to be combined with the second portion of first ownership metadata; combining the first portion of first ownership metadata with the second portion of first ownership metadata to form the first ownership metadata; deriving the first ownership data based on the first ownership metadata; and providing, via the user interface, an indication of the first ownership data, wherein the indication indicates a verifiable identity of the first owner of the device.
21. The method of claim 19, further comprising: receiving, from the server and based on the request, the second portion of first ownership metadata; determining that the first portion of first ownership metadata, stored in the memory of the device, is not able to be combined with the second portion of first ownership metadata based on a determination that a modification has been made to the first portion of first ownership metadata, while stored in the memory of the device, or based on a determination that a modification has been made to the second portion of first ownership metadata, while stored in the blockchain ledger; and providing, via the user interface, an alert indicating that an unauthorized modification has been made to the first ownership metadata.
22. (Canceled Herein).
23. The method of claim 19, further comprising: receiving, by the device, second ownership data associated with a second owner of the device, wherein the second ownership data is received based on a transfer of ownership of the device from the first owner to the second owner; generating, by the device, second ownership metadata based on the second ownership data; splitting the second ownership metadata into a first portion of second ownership metadata and a second portion of second ownership metadata, wherein the first portion of second ownership metadata is correlated with the second portion of second ownership data; storing, in the memory of the device, the first portion of second ownership metadata; and transmitting, to the server, the second portion of second ownership metadata for storage in the blockchain ledger, wherein the chain of ownership associated with the device is verifiable based on the first portion of second ownership metadata stored in the memory of the device and the second portion of second ownership metadata stored in the blockchain ledger.
24. The method of claim 19, wherein the server and the blockchain ledger are associated with one or more of: a manufacturer of the memory with the embedded hardware security module, or a manufacturer of the device that includes the memory with the embedded hardware security module.
25. The method of claim 19, wherein communications between the device and the server are based on cryptographically protected authenticated and signed request response exchanges.
26. The server of claim 10, wherein the server and the blockchain ledger are associated with one or more of: a manufacturer of the memory, or a manufacturer of the device that includes the memory.
27. The method of claim 19, wherein the first ownership data includes one or more of: an intrinsic device property identifier, a device identifier, a manufacturer code, or a unique owner identity.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “A server, comprising: one or more components configured to: receive …” in claim 9. Each of one or more component(s) shall be considered to perform respective or all of the functions such as receiving, splitting, transmitting and/or storing as claimed.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
This application includes one or more claim limitations that use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are: “A device, comprising: memory including an embedded hardware security module; and one or more components configured to: determine … split … store … transmit …” in claim 1.
Because this/these claim limitation(s) is/are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are not being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof. If applicant intends to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to remove the structure, materials, or acts that performs the claimed function; or (2) present a sufficient showing that the claim limitation(s) does/do not recite sufficient structure, materials, or acts to perform the claimed function.
Claim Rejections - 35 USC § 112
Claim 1 recites the limitation "… split the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; store, in the memory of the device, the first portion of first ownership metadata; and transmit, to a server, the second portion of first ownership metadata for storage in a blockchain ledger of a blockchain node.". It is not clear in the claim whether every usage of “first ownership metadata” is a new term or a prior used term and therefore lacks sufficient antecedent basis. There is insufficient antecedent basis for this limitation in the claim.
The same issue occurs with other independent claims 9 and 12. Therefore, all the corresponding dependent claims of above said independent claims are also rejected for the same rationale.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 2, 4, 6 – 14, 16, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over McKervey et al (US 11062042), hereafter Mc and Danilov et al (US 20200348844), hereafter Dan.
Claim 1: Mc teaches a device, comprising: memory including an embedded hardware security module; and one or more components configured to (Figs. 1 – 3): determine first ownership metadata based on first ownership data associated with the device; (C6L10-12: set of events to which an extraction rule applies is identified by metadata associated with the set of events… (C19L45-48) metadata extracted from the corresponding machine data, or supplied or defined by an entity, such as a user or computer system (C11L17-18) a user installs a software application on server computers owned by the user. C69L51-58: the header portions can include information similar to an inverted index, except that the header portions 2002a, 2004a, 2006a, 2008a can group or identify block entries with similar characteristics or metadata (instead of events). For example, the header information can include field-value pairs for the index, customer, tenant, or other information about the block entries, etc.).
and transmit, to a server, the second portion of first ownership metadata for storage in a blockchain ledger of a blockchain node. (C18L21-25: a forwarder may contain the essential components needed to forward data. A forwarder can gather data from a variety of inputs and forward the data to an indexer for indexing and searching. A forwarder can also tag metadata (source, source type, host, etc.). C59L44-52: the storage of buckets or chunks of data (transmitted) to remote data storage systems… The generated content identifier(s) stored in a variety of locations, an indexer or other component of data intake and query system, a separate database, index, or metadata file, a remote data storage system, and/or with the data used to generate it (with the chunk of data, bucket, or file); (C68L25-30) a blockchain ledger distributed across ledger nodes and used to track information received from the data intake and query system, etc. The blockchain ledger may have entries linked to one another using cryptographic records, and entries in the blockchain may be ordered, time stamped, and/or associated with metadata).
Mc is not explicit about split the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; store, in the memory of the device, the first portion of first ownership metadata;
But analogous art Dan teaches split the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; store, in the memory of the device, the first portion of first ownership metadata; ([016] data is stored in chunks, metadata is embodied in directory tables (DTs) that is stored in storage partitions implemented as tree-like or tree data structures that is stored in “tree chunks”, [018, 20] the data of the first data chunk and the second data chunk are convolved, such as by an XOR function, each tree is correlated to a journal of tree updates, known as journals … [018] These journals can be stored in journal chunks. Chunks of a type can be shared to store the corresponding type of data from different sources, for example, one repository chunk can contain portions of different user-generated data objects, one tree chunk can contain elements of different trees, etc. ECS can, for example, implement bulk tree update techniques to reduce a total cost of updates ... effective state is stored in a volatile memory etc. A memory table is ‘dumped’ to a non-volatile memory as a new version of a tree, ECS replicates repository chunks comprising user-generated data and replicates journal chunks comprising system, user, etc., metadata).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Mc to include the idea of splitting metadata and storing a portion of it in device memory as taught by Dan so that a safe and resource efficient method to scale geographically diverse data storage systems in a manner than protects data, more especially metadata stored in Directory Tables (DTs), although other types of data, chunks, etc., also benefit ([017]).
Claim 2: the combination of Mc and Dan teaches the device of claim 1, wherein the first ownership data identifies the device or identifies a first owner of the device. (Mc: C62L14-20, 51-55: the block entry includes additional information, such as, but not limited to, ... customer identifier, source, source type, or other metadata, etc. (i.e., owner)).
Claim 4: the combination of Mc and Dan teaches the device of claim 1, wherein the first portion of first ownership metadata is stored separately from the blockchain ledger. (Mc: C5L10-12: machine data comprises various data items of different data types that is stored at different locations … (C6L1-6, C73L11-20) a search having criteria that specifies a field name "UserID" with a corresponding field value "12345" causes the system to ... identify events having that field-value pair (field name "UserID" with a corresponding field value of "12345")).
Claim 6: the combination of Mc and Dan teaches the device of claim 1, wherein the one or more components are further configured to: encrypt, using symmetric or asymmetric key based encryption, the first portion of first ownership metadata prior to storage in the memory of the device; and encrypt, using symmetric or asymmetric key based encryption, the second portion of first ownership metadata prior to storage in the blockchain ledger. (Mc: C19L23-50: the machine data can be stored with or be associated with data that describes the encryption scheme with which the machine data is stored … and associated with a corresponding portion of machine data when storing the event data in a data store. C62L65-67: the data intake and query system encrypts the block entries (C71L12-14, C73L41-45) using a public key of a key pair associated with the data intake and query system prior communication to the distributed ledger system; the distributed ledger system encrypts the content of blocks or block entries. Entries of a block can be encrypted individually or together).
Claim 7: the combination of Mc and Dan teaches the device of claim 1, wherein the one or more components are further configured to: generate an alert based on being unable to combine the first portion of first ownership metadata and the second portion of first ownership metadata, wherein the alert is associated with a modification to the first portion of first ownership metadata or to the second portion of first ownership metadata. (Mc: C64L17-25, C66L1-17: If there are more block entries than chunks of data, more unmatched block entries than unmatched chunks of data, or if a block entry cannot be matched with a chunk of data (chunk of data identifier in the block entry does not match any chunk of data identifiers in the system, content identifier from distributed ledger system does not match any content identifiers from the system etc.), the system determines that a chunk of data has been deleted (or at least modified); (C53L38-40) alerts are generated to notify system operators when important notable events are discovered).
Claim 8: the combination of Mc and Dan teaches the device of claim 1, wherein the first ownership data includes an intrinsic property of the embedded hardware security module. (Mc: C62L14-20, 51-55: the block entry include additional information, such as, but not limited to,... a system identifier, ... or other metadata, etc. C26L18-22: the indexer identifies a field-value pair entry... that includes a field value corresponding to the identity of the particular host, source, or source-type identified (i.e., embedded hardware security module)).
Claim 9: Mc teaches a server, comprising: one or more components configured to (Figs. 1 – 3): receive, from a device that includes memory with an embedded hardware security module, first ownership metadata associated with the device; and transmit the second portion of first ownership metadata for storage in a blockchain ledger of a blockchain node. (C6L10-12: set of events to which an extraction rule applies is identified by metadata associated with the set of events… (C19L45-48) metadata extracted from the corresponding machine data, or supplied or defined by an entity, such as a user or computer system (C11L17-18) a user installs a software application on server computers owned by the user; C18L21-25: a forwarder may contain the essential components needed to forward data. A forwarder can gather data from a variety of inputs and forward the data to an indexer for indexing and searching. A forwarder can also tag metadata (source, source type, host, etc.). C59L44-52: the storage of buckets or chunks of data to remote data storage systems… The generated content identifier(s) stored in a variety of locations, an indexer or other component of data intake and query system, a separate database, index, or metadata file, a remote data storage system, and/or with the data used to generate it (with the chunk of data, bucket, or file); (C68L25-30) a blockchain ledger distributed across ledger nodes and used to track information received from the data intake and query system, etc. The blockchain ledger may have entries linked to one another using cryptographic records, and entries in the blockchain may be ordered, time stamped, and/or associated with metadata).
While Mc is not explicit about split the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; transmit, to the device, the first portion of first ownership metadata for storage in the memory of the device;
The analogous art Dan teaches split the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; transmit, to the device, the first portion of first ownership metadata for storage in the memory of the device; ([016] data is stored in chunks, metadata is embodied in directory tables (DTs) that is stored in storage partitions implemented as tree-like or tree data structures that is stored in “tree chunks”, [018, 20] the data of the first data chunk and the second data chunk are convolved, such as by an XOR function, each tree is correlated to a journal of tree updates, known as journals … [018] These journals can be stored in journal chunks. Chunks of a type can be shared to store (i.e., transmitted) the corresponding type of data from different sources, for example, one repository chunk can contain portions of different user-generated data objects, one tree chunk can contain elements of different trees, etc. ECS can, for example, implement bulk tree update techniques to reduce a total cost of updates ... effective state is stored in a volatile memory etc. A memory table is ‘dumped’ to a non-volatile memory as a new version of a tree, ECS replicates repository chunks comprising user-generated data and replicates journal chunks comprising system, user, etc., metadata).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Mc to include the idea of splitting metadata and storing a portion of it as taught by Dan so that a safe and resource efficient method to scale geographically diverse data storage systems in a manner than protects data, more especially metadata stored in Directory Tables (DTs), although other types of data, chunks, etc., also benefit ([017]).
Claim 10: the combination of Mc and Dan teaches the server of claim 9, wherein a chain of ownership, indicating owners of the device during a lifespan of the device, is established based on a combination of: the first portion of first ownership metadata stored in the memory of the device, and the second portion of first ownership metadata stored in the blockchain ledger. (Mc: C21L1-15, Fig. 5B-C, 17B: the indexer stores the events with an associated timestamp in a data store. The timestamps enable a user to search for events based on a time range... C62L10-25, Fig. 7A: the data intake and query system stores the generated (or received) content identifiers and/or communicate them to the distributed ledger system as part of a block entry. The block entry includes additional information, such as, but not limited to, ... a system identifier, ... time range, tenant identifier, customer identifier, ... other metadata, etc. the block entry includes or be a content identifier generated from a combination of the additional information and the content identifier generated for the chunk of data).
Claim 11: the combination of Mc and Dan teaches the server of claim 9, wherein the first ownership data identifies the device or identifies a first owner of the device. (Mc: C34L38-55: The administrator can query the search head for customer ID field value matches across the log data from the three systems that are stored at the one or more indexers 206. The customer ID field value exists in the data gathered from the three systems, but the customer ID field value may be located in different areas of the data given differences in the architecture of the systems. There is a semantic relationship between the customer ID field values generated by the three systems. The search head requests events from the one or more indexers 206 to gather relevant events from the three systems. The search head then applies extraction rules to the events in order to extract field values that it can correlate. The search head may apply a different extraction rule to each set of events from each system when the event format differs among systems. C62L14-20, 51-55: the block entry includes additional information, such as, but not limited to, ... customer identifier, source, source type, or other metadata, etc. (i.e., owner)).
Claim 12: Mc teaches a method, comprising: generating, by a device that includes memory with an embedded hardware security module, first ownership metadata based on first ownership data received during a registration process; and transmitting, by the device to a server, the second portion of first ownership metadata for storage in a blockchain ledger of a blockchain node. (C5L18-27: generate machine data from which events can be derived include, but are not limited to, web servers, application servers, databases, fire-walls, routers, operating systems, and software applications that execute on computer systems, mobile devices, sensors, IoT devices, etc. The machine data generated by such data sources can include, for example and without limitation, server log files, activity log files, configuration files, messages, network packet data, performance measurements, sensor measurements, etc. C6L10-12: set of events to which an extraction rule applies is identified by metadata associated with the set of events… (C19L45-48) metadata extracted from the corresponding machine data, or supplied or defined by an entity, such as a user or computer system (C11L17-18) a user installs a software application on server computers owned by the user; C18L21-25: a forwarder may contain the essential components needed to forward data. A forwarder can gather data from a variety of inputs and forward the data to an indexer for indexing and searching. A forwarder can also tag metadata (source, source type, host, etc.). C59L44-52: the storage of buckets or chunks of data to remote data storage systems… The generated content identifier(s) stored in a variety of locations, an indexer or other component of data intake and query system, a separate database, index, or metadata file, a remote data storage system, and/or with the data used to generate it (with the chunk of data, bucket, or file); (C68L25-30) a blockchain ledger distributed across ledger nodes and used to track information received from the data intake and query system, etc. The blockchain ledger may have entries linked to one another using cryptographic records, and entries in the blockchain may be ordered, time stamped, and/or associated with metadata. C69L51-58: the header portions can include information similar to an inverted index, except that the header portions 2002a, 2004a, 2006a, 2008a can group or identify block entries with similar characteristics or metadata (instead of events). For example, the header information can include field-value pairs for the index, customer, tenant, or other information about the block entries, etc.).
While Mc is not explicit about splitting, by the device, the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; storing, in the memory of the device, the first portion of first ownership metadata;
The analogous art Dan teaches splitting, by the device, the first ownership metadata into a first portion of first ownership metadata and a second portion of first ownership metadata, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership data; storing, in the memory of the device, the first portion of first ownership metadata; ([016] data is stored in chunks, metadata is embodied in directory tables (DTs) that is stored in storage partitions implemented as tree-like or tree data structures that is stored in “tree chunks”, [018, 20] the data of the first data chunk and the second data chunk are convolved, such as by an XOR function, each tree is correlated to a journal of tree updates, known as journals … [018] These journals can be stored in journal chunks. Chunks of a type can be shared to store (i.e., transmitted) the corresponding type of data from different sources, for example, one repository chunk can contain portions of different user-generated data objects, one tree chunk can contain elements of different trees, etc. ECS can, for example, implement bulk tree update techniques to reduce a total cost of updates ... effective state is stored in a volatile memory etc. A memory table is ‘dumped’ to a non-volatile memory as a new version of a tree, ECS replicates repository chunks comprising user-generated data and replicates journal chunks comprising system, user, etc., metadata).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Mc to include the idea of splitting metadata and storing a portion of it as taught by Dan so that a safe and resource efficient method to scale geographically diverse data storage systems in a manner than protects data, more especially metadata stored in Directory Tables (DTs), although other types of data, chunks, etc., also benefit ([017]).
Claim 13: the combination of Mc and Dan teaches the method of claim 12, further comprising: receiving, by the device from the server, a secure key for decrypting the first portion of first ownership metadata and the second portion of first ownership metadata. (Mc: C19L37-40: information about the compression or encryption scheme can be used to decompress or decrypt the machine data, and any metadata with which it is stored. C62L55-60: the distributed ledger system generates a hash of the block entry received from the data intake and query system (minus the encrypted hash)…).
Claim 14: the combination of Mc and Dan teaches the method of claim 13, further comprising: decrypting, using the secure key, the first portion of first ownership metadata upon retrieval from the memory and the second portion of first ownership metadata upon retrieval from the blockchain ledger. (Mc: C62L55-60: the distributed ledger system generates a hash of the block entry received from the data intake and query system, decrypt the encrypted hash using a public key of the same key pair. C66L1-15: if the system determines that the retrieved Tl blockchain hash and T2 blockchain hash do not match the Tl authentication hash and a T2 authentication hash (or other Tl/T2 hash stored by the system), the system requests the blockchain hashes of the individual buckets within the specific time range or within Tl and T2. The system then compares the blockchain hashes of each bucket with authentication hashes of the buckets to identify which buckets have been modified ... Moreover, once a modified bucket is identified, the system compares the blockchain hashes of the portions of the bucket with the authentication hashes of the portions of the bucket to identify the portion of the bucket that was modifiedC70L56-60: the distributed ledger system returns all of the blocks of the identified blockchain. In certain cases, the distributed ledger system 1800 can further identify potentially relevant blocks based on a time range in the block header).
Claim 16: the combination of Mc and Dan teaches the method of claim 12, wherein the first portion of first ownership metadata is correlated with the second portion of first ownership metadata such that the first portion of first ownership metadata and the second portion of first ownership metadata are only combinable with each other. (Dan [048]: system can perform a second hashing of replicated data to distribute key data among tree data portions resulting from a first hashing of the replicated data, e.g., where the first hashing function can be regarded as distributing tree data portions by splitting tree data of a deleted zone into different portions that can be combined with other tree portions of other zones, horizontal hashing such as in system, the second hashing function can distribute the key data among the tree data portions in a manner that results in more even distribution of key data, which can be termed ‘vertical’ hashing. Horizontal and vertical hashing of the replicated tree data from a deleted zone can result in merging, according to the horizontal hashing, TA1 into TB1 of second ZSC, and attaching, according to the vertical hashing, the some of the corresponding key data to TB1, e.g., KA1 can be adopted by TB1).
Claim 17: the combination of Mc and Dan teaches the method of claim 12, wherein storing the first portion of first ownership metadata in the memory further comprises: writing, by the device, the first portion of first ownership metadata to a section of the memory that is [non-erasable] and cryptographically protected. (Mc: C6L10-12: set of events to which an extraction rule applies is identified by metadata associated with the set of events… (C19L45-48) metadata extracted from the corresponding machine data, or supplied or defined by an entity, such as a user or computer system. C5L10-15: some machine data can comprise various data items of different data types that may be stored at different locations within the data. For example, when the data source is an operating system log, an event can include one or more lines from the operating system log containing machine data that includes different types of performance and diagnostic information associated with a specific point in time (e.g., a timestamp). C11L17-18) a user installs a software application on server computers owned by the user. C19L33-37: machine data can be stored in a compressed or encrypted formatted. The machine data can be stored with or be associated with data that describes the compression or encryption scheme with which the machine data is stored).
Dan teaches that the data is stored in non-erasable medium. (Dan: [016] data is stored in chunks, metadata is embodied in directory tables (DTs) that is stored in storage partitions implemented as tree-like or tree data structures that is stored in “tree chunks”, [018, 20] the data of the first data chunk and the second data chunk are convolved ... [029] the zone can be placed in a read-only (RO) state. From the RO state, the tree/journal, in corresponding chunk-types, can be replicated to other zones while the RO zone remains readable).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Mc to include the idea of read-only (non-erasable) media as taught by Dan so that a safe and resource efficient method to scale geographically diverse data storage systems in a manner than protects data, more especially metadata stored in Directory Tables (DTs), although other types of data, chunks, etc., also benefit ([017]).
Claim Rejections - 35 USC § 103
Claim(s) 15, 18 – 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mc and Dan as applied to claims above, and further in view of Kim et al (US 20190075102), Kim.
Claim 15: the combination of Mc and Dan teaches the method of claim 12, but is silent on further comprising: registering, by the device, a first owner of the device during an initial ownership establishment, wherein the first ownership data comprises a unique identity of the first owner.
But analogous art Kim teaches registering, by the device, a first owner of the device during an initial ownership establishment, wherein the first ownership data comprises a unique identity of the first owner. ([06-8, Figs. 1-2] a FIDO authentication device used exclusively by the owner thereof is registered in a server, and the owner is authenticated when authentication using the registered FIDO authentication device succeeds ... A user may authenticate locally to a terminal device, which is a FIDO authentication device, in order to verify that the user is registered therein).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Mc and Dan to include the idea of registering owner of device as taught by Kim so that the reliability of transaction records may be secured without any trusted third party ([014]).
Claim 18: the combination of Mc and Dan teaches the method of claim 12, but Kim teaches further comprising: determining to perform a decommission process based on an end of life of the device. ([Figs. 3, 8, 14: 074 - , 568-580] The FIDO blockchain may record data related to FIDO, including metadata information of the user terminal apparatus and FIDO authentication information of a user, in a transaction ledger of each node of a blockchain network, thereby providing a program (smart contract) that is capable of processing various functions, such as registering, authenticating, and deregistering data related to FIDO, connecting the data with the identifier of the user, retrieving data, and the like).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Mc and Dan to include the idea of deregistering owner information or device thereof as taught by Kim so that the reliability of transaction records may be secured without any trusted third party ([014]).
Claim 19: the combination of Mc and Dan teaches the method of claim 18, further comprising: transmitting, by the device, metadata to the server to initiate removal of all ownership metadata from the blockchain ledger based on determining to perform the decommission process. ([036] the blockchain database may store a string for requesting retrieval of a unique identifier of the terminal apparatus and a list of unique identifiers matching the string, which are set as a key and a value, respectively, as a first type of metadata information. Also, the blockchain database may store a unique identifier of the terminal apparatus and an inherent public key of the terminal apparatus corresponding to the unique identifier, which are set as a key and a value, respectively, as a second type of metadata information. [Figs. 3, 8, 14, 084] The identification information of the user may include at least one of the identifiers of the user in the service, the device identifier of the user terminal apparatus, and the unique identifier of the user terminal apparatus. [0190-194] when the electronic signature of the FIDO authentication response message is successfully verified, the blockchain program may determine that the FIDO authentication response message is successfully verified. The blockchain database may … delete the metadata information and the FIDO authentication information of the user).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Mc and Dan to include the idea of deregistering owner information or device thereof as taught by Kim so that the reliability of transaction records may be secured without any trusted third party ([014]).
Allowable Subject Matter
Claims 3, 5, 20 is/are 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See form PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Badri Champakesan whose telephone number is (571)270-3867. The examiner can normally be reached M-F: 8.30am-4.30pm (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, Jung Kim can be reached on (571) 272-3804. 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.
/BADRINARAYANAN /Primary Examiner, Art Unit 2494.