DETAILED ACTION
This action is in response to the Applicant Remarks received on October 21, 2025. Claims 1-4, 7-10, and 13-16 are pending with claims 5-6, 11-12, and 17-18 canceled, and claims 1, 7, and 13 currently amended.
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 .
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 October 21, 2025 has been entered.
Claim Objections
Claims 1, 7, and 13 are objected to because of the following informalities:
In the recitation, “verifying the digital signature using a accreditation authority public key resolved from the registry”, the Applicant introduces a typographical error by stating “a accreditation authority” rather than “an accreditation authority”.
For the purposes of examination, the Examiner assumes the Applicant intended to recite “an accreditation authority”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-4, 7-10, and 13-16 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The Examiner has determined that the following claim limitations introduce new matter into the instant application. The Applicant must provide sufficient evidence to support the amendments or cancel the amendments from the claims.
Claim 1 (emphasis added):
A computer-implemented method of using a computing infrastructure to validate, accredit, and publish a lesson-package non-fungible token (NFT) with tamper-evident provenance on an object distributed ledger, the method comprising:
determining, by a marketplace computing device of the computing infrastructure, a plurality of effectiveness metrics for a plurality of learning objects associated with a common topic,
wherein each learning object includes a unique set of descriptive asset digital video frames that portray an aspect of a corresponding set of knowledge bullet-points of the common topic for the learning object;
selecting, by the marketplace computing device, a set of learning objects of the plurality of learning objects based on the plurality of effectiveness metrics to produce a lesson package;
interpreting, by the marketplace computing device, a request from a learning object owner computing device of the computing infrastructure, distinct from the marketplace computing device, to make available for licensing a set of learning objects of the lesson package, and
producing an object basics record of a smart contract for the set of learning objects, the object basics record including:
a learning object set identifier of the set of learning objects,
an identifier of the lesson package,
the effectiveness metrics for the set of learning objects, and
at least one learning object owner identifier associated with the set of learning objects;
generating, by the marketplace computing device, a canonical representation of the object basics record including a per-learning-object manifest that lists cryptographic hashes of the descriptive asset digital video frames and associated metadata for the set of learning objects;
identifying, by the marketplace computing device, an accreditation authority computing device by consulting a registry that maps a lesson-package or recipient identifier in the object basics record to an accreditation authority identifier and corresponding public key material;
obtaining, from the accreditation authority computing device, baseline validation information comprising:
a digital signature over a canonicalized digest of the object basics record including the per-learning-object manifest and
a validation timestamp;
validating, by a cryptographic engine of the marketplace computing device, the object basics record by:
recomputing the canonicalized digest,
verifying the digital signature using a accreditation authority public key resolved from the registry, and
confirming that the accreditation authority is not revoked according to a revocation status indicator, and indicating that the object basics record is accredited in response to successful validation; and
when the object basics record is accredited:
establishing, by the marketplace computing device, available license terms of the smart contract for the lesson package, and
causing, by the marketplace computing device, generation of a non-fungible token associated with the smart contract in the object distributed ledger, including:
synchronizing with the object distributed ledger to a finalized block height having at least a threshold number of confirmations,
computing, by the cryptographic engine, a transaction digest over a canonical representation of NFT content comprising the canonical object basics record, the validation timestamp, an availability status, and a reference to the accreditation authority signature, together with a nonce, a chain identifier, and a previous block hash,
encrypting, by the cryptographic engine, at least a portion of the NFT content using a receiving public key associated with the object distributed ledger and generating a transaction signature by signing the transaction digest with a private key of the marketplace computing device,
generating a next block of a blockchain of the object distributed ledger to include the NFT content, the encrypted portion, a Merkle root committing the NFT content including the per-learning-object manifest, and the transaction signature, and
causing inclusion of the next block as the non-fungible token in the object distributed ledger and recording a Merkle proof of inclusion for the NFT content,
wherein inclusion of the chain identifier, the previous block hash, and the nonce in the transaction digest prevents replay across ledgers or epochs, and
the recorded Merkle proof together with the threshold number of confirmations provides tamper-evident provenance and finalized custody of the NFT within a bounded time window.
Claim 1 is annotated above to point out the new matter determined by the Examiner; however, claims 7 and 13 contain similar limitations and must be evaluated the same. Claims 2-4, 8-10, and 14-16 are rejected by virtue of their dependencies on claims 1, 7, and 13, respectively.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-4, 7-10, and 13-16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 7 and 13 recite the limitation "per-learning-object manifest". There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
Claims 1-4, 7-10, and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Goeringer [US20170134161A1] and Singh [US20180108268A1].
Regarding claims 1-4, the claims recite similar limitations to claims 7-10 below. For citations on rejection, see the rejection of claims 7-10 below.
Regarding claim 7 (Currently amended), Goeringer discloses:
A marketplace computing device of a computing infrastructure, the marketplace computing device comprising:
an interface (Goeringer, [0027], “Also, in the embodiments described herein, additional input channels may be, but are not limited to, computer peripherals associated with an operator interface such as a mouse and a keyboard.”);
a local memory (Goeringer, [0029], “Therefore, the methods described herein may be encoded as executable instructions embodied in a tangible, non-transitory, computer readable medium, including, without limitation, a storage device and a memory device.”); and
a processor operably coupled to the interface and the local memory, wherein the processor executes operational instructions stored in the local memory to perform functions to:
interpret a request from a learning object owner computing device of the computing infrastructure, distinct from the marketplace computing device,
producing an object basics record of a smart contract for the set of learning objects (Goeringer, [0104], “The frictionless content of ecosystem 1200 is further advantageous to potential new distribution models, including, but not limited to: … “smart content contracts” involving programmatic usage rights that more efficiently may replace paper contracts.”), the object basics record including (Goeringer, Claim 4, “wherein the first and second memories are configured to store one or more of a party certificate, an envelope ID, a transaction ID, a user ID, a device ID, a media ID, a hash, a media uniform resource identifier, a timestamp, a party rating, a rating of the content to be transferred, terms of agreement between the first electronic device and the second electronic device, licenses that may encumber the transferred content, and exchange rate information related to a monetary exchange for the transfer of content.”):
a learning object set identifier of the set of learning objects (i.e., a media ID),
an identifier of the lesson package (i.e., a media uniform resource identifier (URI)),
the effectiveness metrics for the set of learning objects (i.e., a rating of the content to be transferred), and
at least one learning object owner identifier associated with the set of learning objects (i.e., licenses that may encumber the transferred content);
utilizing public key material (Goeringer, [0056], “Upon receipt of details of CAC transaction 314, first node 306 and second node 308 are configured to validate the transaction using the public key of party A.”);
obtain, via the interface, from the accreditation authority computing device, baseline validation information comprising:
a digital signature over a canonicalized digest of the object basics record (Goeringer, [0039], “Once transaction 120 is initiated, party A compiles a body of information contained within memory 112 into an envelope, and processor 114 encrypts the envelope, including a media key, with a private key of party A, and submits the encrypted envelope to blockchain processor 104.” The private key is used as the digital signature as, in this case, Party A should be the only party with Party A’s private key.) including the per-learning-object manifest and
a validation timestamp (As cited in Goeringer previously, all transactions, which would include non-finanicial/purely informational transactions, would contain a timestamp.);
validate the object basics record by:
recomputing the canonicalized digest (Goeringer, [0056], “Processors 302, 304 may then append new transactions to the determined blockchain and estimate the next hash.”),
verifying the digital signature using an accreditation authority public key resolved from the registry (See Goeringer citation above regarding accreditation authority.); and
when the object basics record is accredited:
establish available license terms of the smart contract for the lesson package (Goeringer, [0083], “In an exemplary embodiment, the contract by the content creator may be further refined by distributor 816, through allowable changes, which will be reflected in envelope 814, which will include a digital contract.”), and
cause generation of a non-fungible token (i.e., any token that isn’t replaceable, such as the media content taught by Goeringer) associated with the smart contract in the object distributed ledger (See citation above regarding use of Smart Contracts.), including:
synchronizing with, via the interface, the object distributed ledger to a finalized block height having at least a threshold number of confirmations (Goeringer, Claim 14, “The method of claim 13, further comprising the step of processing, by the blockchain node, the pending block and append relevant information to a prior blockchain.”),
computing a transaction digest over a canonical representation of NFT content (Goeringer, [0037], “In operation, system 100 utilizes blockchain 102 and blockchain processor 104 to secure a transaction 120 between first party 106 and second party 108. … In the exemplary embodiment, first memory 112 and second memory 116 each are configured to store certificates and other information, including, without limitation, at least one of an envelope ID or transaction ID, a certificate of the respective party A or B, a user ID, a device ID, a media ID or hash, a media uniform resource identifier (URI), timestamps, ratings of the particular party and/or the content to be transferred, terms of agreement between the parties, licenses that may encumber the transferred content, and exchange rate information related to a monetary exchange between parties for the transfer of content.”) comprising
the canonical object basics record (i.e., the content within the blockchain with corresponding IDs),
the validation timestamp (i.e., timestamps),
an availability status (As evidenced by providing the content.), and
a reference to the accreditation authority signature (See citations above regarding accreditation authority.), together with a nonce (Using a nonce is standard in cryptographic practices in conjunction with a private key and public key.), a chain identifier (i.e., envelope ID), and a previous block hash (i.e., hash),
encrypting at least a portion of the NFT content using a receiving public key associated with the object distributed ledger (Goeringer, [0043], “Additionally, utilization of blockchain 102 for transaction 120 also renders it significantly easier for party B (the buyer or transferee) to: (a) legally receive licensed content;” The public key of Party B would be utilized by the system to encrypt content that Party A only wants Party B to access, which is standard in DRM Compliance.) and
generating a transaction signature by signing the transaction digest with a private key of the marketplace computing device (Goeringer, [0039], “Once transaction 120 is initiated, party A compiles a body of information contained within memory 112 into an envelope, and processor 114 encrypts the envelope, including a media key, with a private key of party A, and submits the encrypted envelope to blockchain processor 104.”),
generating a next block of a blockchain of the object distributed ledger (Goeringer, [0071], “If the transaction is not the final transaction linear chain (e.g., CAC transaction 514), the receiving party is configured to append the prior transaction to a new transaction, which may then be submitted to the next party in the linear chain.”) to include
the NFT content (i.e., the content being provided for viewing),
the encrypted portion (i.e., the content is encrypted),
a Merkle root committing the NFT content including the per-learning-object manifest (Goeringer, [0092], “In step S1024, blockchain 1006 is configured to calculate the Merkle Root. In an exemplary embodiment, blockchain 1006 utilizes hashing to perform the Merkle operation on a transaction tree, thereby arriving at a single hash representing the entire transaction graph.”), and
the transaction signature (The transaction is signed via the party’s private key.), and
causing, via the interface, inclusion of the next block as the non-fungible token in the object distributed ledger and recording a Merkle proof of inclusion for the NFT content (Goeringer, [0092], “In an exemplary embodiment, blockchain 1006 utilizes hashing to perform the Merkle operation on a transaction tree, thereby arriving at a single hash representing the entire transaction graph.”),
wherein inclusion of the chain identifier, the previous block hash, and the nonce in the transaction digest prevents replay across ledgers or epochs (See citations above.), and
the recorded Merkle proof together with the threshold number of confirmations provides tamper-evident provenance and finalized custody of the NFT within a bounded time window (Goeringer, [0049], “As with system 100, the immutability of blockchain 202 renders both transaction 220 and the transferred CAC content resistant to piracy and/or other unauthorized uses, which is of particular interest to content owner 222.”).
Goeringer discloses media distribution techniques as cited above, but Goeringer does not disclose a system for providing tailored educational materials.
Singh, however, discloses:
A processor operably coupled to the interface and the local memory, wherein the processor executes operational instructions stored in the local memory to perform functions to:
determine a plurality of effectiveness metrics for a plurality of learning objects associated with a common topic (Singh, Claim 8, “A method of creating a course package for presentation to a user, the method comprising: receiving data relating to a user's performance in one or more lessons; determining the student's level of proficiency; selecting a plurality of content items from a content pool based on the student's level of proficiency.”),
wherein each learning object includes a unique set of descriptive asset digital video frames that portray an aspect of a corresponding set of knowledge bullet-points of the common topic for the learning object (Singh, [0178], “Video RNN 2020 aims to develop the overall context of a video. Course videos may have limited motion, making it redundant to sample continuously. Therefore, in some embodiments one frame is sampled every second to create a series of images. The image frames can then be fed into a RNN (using, for example, a long short-term memory (LSTM) architecture) in order to determine contexts. Audio RNN 2030 uses an RNN as well, but may sample continuously or at a higher frequency than Video RNN 2020.”);
select a set of learning objects of the plurality of learning objects based on the plurality of effectiveness metrics to produce a lesson package (Singh, See Claim 8 citation above.);
interpret a request from a learning object owner computing device of the computing infrastructure, distinct from the marketplace computing device,
to make available for licensing a set of learning objects of the lesson package (Singh, [0077], “In some embodiments, content can be purchased or licensed on a node by node basis. That is, nodes which form part of a course may be purchased or licensed without having to purchase or license all of the nodes within the course.”);
identify an accreditation authority computing device by consulting a registry that maps a lesson-package or recipient identifier in the object basics record (Singh, [0148], “To facilitate peer to peer support, a student seeking support should feel confident that they are receiving support from a qualified student. Students generally trust instructors because it is assumed that instructors have a certain degree of proficiency or mastery of a subject, thus earning the trust of the student. The system 100 can allow students to demonstrate their mastery of a subject through the use of points, badges, flair, trophies, and the like.”);
validate the object basics record by:
confirming that the accreditation authority is not revoked according to a revocation status indicator (See Singh citation above regarding accreditation authority.), and
indicating that the object basics record is accredited in response to successful validation (See Singh citation above regarding accreditation authority.).
One of ordinary skill in the art of educational media distribution and blockchain development would have found it obvious before the effective filing date of the claimed invention to distribute customized lesson packages of Singh using commonly understood methods of distribution media via blockchain technology, as found in Goeringer, in order to gain the commonly understood benefits of such adaptation, such as decentralized content distribution and transaction history verification. All this would be accomplished with no unpredictable results.
Regarding claim 8 (Original), Goeringer/Singh discloses:
The marketplace computing device of claim 7, wherein the processor performs functions to determine the plurality of effectiveness metrics for the plurality of learning objects associated with the common topic by one or more of:
identifying a retention test score associated with a first learning object of the plurality of learning objects to produce a retention metric for the first learning object (Singh, [0146], “The credibility score of a student or other content creator may be enhanced depending on how much other users make use of the created content. The credibility score of the student or other content creator may also be enhanced depending upon how much the created content is deemed to help improve understanding of a concept. The efficacy of created content may be determined, for example, by relating assessment outcomes (e.g. exam scores) of one or more students to the content consumed by the one or more students.”);
identifying a first learning entity rating of the first learning object to produce a first user rating metric for the first learning object;
generating a group rating metric for the first learning object based on the first learning entity rating of the first learning object and a second learning entity rating of the first learning object; and
comparing a learning objective of a third learning object of the plurality of learning objects to a learning objective of the lesson package to produce a fit metric for the third learning object.
Regarding claim 9 (Original), Goeringer/Singh discloses:
The marketplace computing device of claim 8, wherein the processor performs functions to select the set of learning objects of the plurality of learning objects based on the plurality of effectiveness metrics to produce the lesson package by at least one of:
selecting the first learning object when the retention metric for the first learning object is greater than a retention metric minimum threshold level (Singh, Claim 8, “A method of creating a course package for presentation to a user, the method comprising: receiving data relating to a user's performance in one or more lessons; determining the student's level of proficiency; selecting a plurality of content items from a content pool based on the student's level of proficiency.”);
selecting the first learning object when the first user rating metric for the first learning object is greater than a user rating metric minimum threshold level;
selecting the first learning object when the group rating metric for the first learning object is greater than a group rating metric minimum threshold level; and
selecting the third learning object when the fit metric for the third learning object is greater than a fit metric minimum threshold level.
Regarding claim 10 (Original), Goeringer/Singh discloses:
The marketplace computing device of claim 7, wherein the processor performs functions to interpret the request from the learning object owner computing device to make available for licensing the set of learning objects of the lesson package to produce the object basics record of the smart contract for the set of learning objects by one or more of:
identifying a set of learning object identifiers for the set of learning objects (Singh, [0078], “An example license includes at least an identifier for the content to be licensed, a corresponding price 1210 for the license, and the length of time for which the license is valid.”);
generating the learning object set identifier of the set of learning objects based on the set of learning object identifiers;
identifying a set of learning object owner identifiers associated with the set of learning objects,
wherein the set of learning object owner identifiers includes the at least one learning object owner identifier;
determining a set of training areas for the set of learning objects,
wherein each training area is associated with one or more learning objects of the set of learning objects;
identifying, for each learning object of the set of learning objects, a corresponding accreditation authority computing device; and
identifying, for each learning object of the set of learning objects, a valid timeframe of the learning object.
Regarding claims 5-6, 11-12, and 17-18, the Applicant has canceled the claims.
Regarding 13-16, the claims recite similar limitations to claims 7-10 above. For citations on rejection, see the rejection of claims 7-10 above.
Response to Arguments
Applicant’s arguments with respect to claims 1-4, 7-10, and 13-16 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.
Given the extensive amendments to the claims, the search introduced prior art more relevant to the instant application relative to the previously applied references. See the rejection above for citations on rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZACHARY JOSEPH POLLOCK whose telephone number is (703)756-5952. The examiner can normally be reached Monday-Friday 10:00am-8:00pm ET.
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, XUAN THAI can be reached at (571) 272-7147. 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.
/Z.J.P./Examiner, Art Unit 3715
/XUAN M THAI/Supervisory Patent Examiner, Art Unit 3715