DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-18 have been examined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more. The claims recite an abstract idea. The judicial exception is not integrated into a practical application. The claims do not include additional elements sufficient to amount to significantly more than the judicial exception.
First, it is determined that the claims are directed to a statutory category of invention. See MPEP 2106.03 (II). In the instant case, claims 1-6 are directed to a method, in the statutory category of process. Claims 7-12 are directed to a computing device, in the statutory category of machine. Claims 13-18 are directed to a non-transitory computer readable memory, in the statutory category of article of manufacture. Therefore, claims 1-18 are directed to statutory subject matter under Step 1 of the Alice/Mayo test (Step 1: YES).
The claims are then analyzed to determine whether the claims are directed to a judicial exception. See MPEP 2106.04. The claims are analyzed to evaluate whether they recite a judicial exception (Step 2A, Prong One) as well as analyzed to evaluate whether the claims recite additional elements that integrate the judicial exception into a practical application of the judicial exception (Step 2A, Prong Two). See MPEP 2106.04. Proceeding with the Step 2A, Prong One analysis, independent claim 1 recites “a marketplace computing device” (emphasis added, eighth line of page 44), and then recites (emphasis added, lines 20-23 of page 44), “establishing, by the marketplace computing device, available license terms of the smart contract for the set of learning objects, establishing, by the marketplace computing device, available payment terms of the smart contract for the set of learning objects”. Setting available payment terms and other relevant terms, for a set of goods and/or services, is a fundamental economic practice, falling under the category of “Certain Methods of Organizing Human Activity”, and therefore an abstract idea. Independent claims 7 and 13 contain language parallel to that of claim 1. Therefore, claims 1-18 are directed to an abstract idea, a form of judicial exception. (Step 2A, Prong One: YES)
It is further noted that claim 5 of the instant application, which depends from claim 1, recites (emphasis added, lines 26-30 of page 46), “determining whether the proposed available payment terms are acceptable to a set of owners associated with the set of learning objects; and establishing the proposed available payment terms as the available payment terms when the proposed available payment terms are acceptable to the set of owners.” Claim 5 is thus further directed to commercial or legal interactions (including advertising, marketing, or sales activities or behaviors, and business relations), also falling within the category of “Certain Methods of Organizing Human Activity”, and therefore an abstract idea. The same applies to claims 11 and 17, which are parallel to claim 5. Claim 4 recites in regard to license terms essentially what claim 5 recites in regard to payment terms, and claims 10 and 16 are then parallel to claim 4. This further pertains to Step 2A, Prong One.
Proceeding to the Step 2A, Prong Two analysis, representative claim 1 recites the following method:
A computer-implemented of using a computing infrastructure for utilizing an object distributed ledger, the method comprising:
determining, by a marketplace computing device of the computing infrastructure, to make available for licensing a set of learning objects associated with a learning object owner computing device of the computing infrastructure to produce an object basics record of a smart contract for the set of learning objects, wherein the learning object owner computing device is distinct from the marketplace computing device, wherein the object basics record includes a learning object set identifier of the set of learning objects, a course number associated with the set of learning objects, and at least one learning object owner identifier associated with the set of learning objects;
verifying, by the marketplace computing device, with an accreditation authority computing device of the computing infrastructure, validity of the object basics record; and
when the object basics record is valid:
establishing, by the marketplace computing device, available license terms of the smart contract for the set of learning objects,
establishing, by the marketplace computing device, available payment terms of the smart contract for the set of learning objects, and
causing, by the marketplace computing device, generation of a non-fungible token associated with the smart contract in the object distributed ledger.
Analysis under Prong Two shows the use of computing devices, a non-fungible token, a smart contract, and a distributed ledger. Using computer-related elements to perform an abstract idea is not generally sufficient to make a claim significantly more than the abstract idea, as the Supreme Court ruled in Alice Corp. v. CLS Bank International. Establishing payment terms remains an abstract idea even if the payment terms are for a for a smart contract for a set of learning objects which relate to a course number. The computing devices as such are generic, and at a high level of abstraction (see paragraph 38 of the instant specification). The instant application does not recite new technology in computing devices or in smart contracts, distributed ledgers, or non-fungible tokens, and does not assert that the smart contracts, distributed ledgers, or non-fungible tokens used represent an improvement in software or hardware. Instead, the instant application appears to assume that readers will be familiar with smart contracts, distributed ledgers, and non-fungible tokens, the use of which for particular purposes is described. The smart contracts, distributed ledgers, and non-fungible tokens are therefore also deemed generic, and presented at a high level of abstraction as known tools which can be applied for desired purposes, the purposes here being classifiable as an abstract idea. (Step 2A, Prong Two: NO)
Next, under Step 2B of the Alice/Mayo test, the claims are analyzed to determine whether there are additional claim limitations that individually, or as an ordered combination, ensure that the claims amount to significantly more than the abstract idea. See MPEP 2106.05. The Step 2B analysis largely overlaps with the Step 2A, Prong Two analysis set forth above, leading to the same conclusions. There is the further consideration under Step 2B of whether the claims add a specific limitation other than what is well-known, routine, and conventional activity in the field. Considering the technological features recited in claim 1 and its dependents, and also in the largely parallel independent claims 7 and 13, and their respective dependents, Salienko (U.S. Patent Application Publication 2020/0211093) discloses (paragraph 21, emphasis added), “The computing device 20 can be any desktop, laptop, tablet, smart phone or general purpose computing device with an appropriate amount of memory for this purpose and an active connection to the Internet 500. Computing devices like this are well known in the art and are not pertinent to the invention.” Hence, the marketplace computing device and learning object owner computing device of claim 1 and other claims require only well-known, routine, and conventional technology.
Doney (U.S. Patent Application Publication 2021/0390191) discloses (paragraph 82, emphasis added), “The deployment of smart contracts to digital ledgers is a common practice that is well-known to one of skill in the art and thus is not described in detail herein.” Given that the deployment of smart contracts to digital ledgers was well-known prior to inventors’ earliest priority date, it follows that smart contracts and digital ledgers themselves were well-known, routine and conventional. Yet further, Murdoch et al. (U.S. Patent Application Publication 2020/0394206) discloses (paragraph 59, emphasis added), “The distributed ledger or blockchain 220 may operate according to any known standards for distributed ledgers. Examples of conventional distributed ledgers that may correspond to the distributed ledger or blockchain 220 include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.” Hence, distributed ledgers were well-understood, routine, and conventional prior to inventors’ earliest priority date. Neither claim 1 nor its dependents are found to add a specific limitation other than what was well-known, routine, and conventional activity in the field.
The above statements regarding claims 1-6 (which are method claims) also apply to claims 7-12 and 13-18, although claims 7 and 13 recite certain other features. Specifically, independent claim 7 recites a “marketplace computing device”, comprising an interface, a local memory, and a processor operably coupled to the interface and the local memory, wherein the processor performs functions. Avidan et al. (U.S. Patent Application Publication 2017/0193592) discloses (paragraph 25, emphasis added), “Although not illustrated, it should be appreciated that the ecommerce server 110, the merchant computer 120, and the customer computer 130 each include conventional components, such as a processor and a memory medium storing computer-readable instructions that are executable by the processor to perform various operations including those described herein.” Hence, the recited local memory and processor need involve only well-understood, routine, and conventional technology. Further, Carrott (U.S. Patent Application Publication 2020/0402047) discloses (paragraph 100, emphasis added), “Many computerized devices are discussed above. Computerized devices that include chip-based central processing units (CPU’s), input/output devices (including graphic user interfaces (GUI), memories, comparators, tangible processors, etc.) are well-known and readily available devices produced by manufacturers such as Dell Computers, Round Rock Tex., USA and Apple Computer Co., Cupertino Calif., USA. Such computerized devices commonly include input/output devices, power supplies, tangible processors, electronic storage memories, wiring, etc., the details of which are omitted herefrom to allow the reader to focus on the salient aspects of the systems and methods described herein.” Hence, the recited interface, local memory, and processor need involve only well-understood, routine, and conventional technology.
Specifically, independent claim 13 recites a non-transitory computer readable memory comprising memory elements. Avidan et al. (U.S. Patent Application Publication 2017/0193592) discloses (paragraph 25, emphasis added), “Although not illustrated, it should be appreciated that the ecommerce server 110, the merchant computer 120, and the customer computer 130 each include conventional components, such as a processor and a memory medium storing computer-readable instructions that are executable by the processor to perform various operations including those described herein. The computer-readable instructions can be stored on non-transitory computer-readable media of a conventional type, whether devices and/or materials.” Hence, the recited non-transitory computer readable memory comprising memory elements need involve only well-understood, routine, and conventional technology. (Step 2B: NO)
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, 2, 3, 4, 5, and 6 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 2, 3, 4, 5, and 6 of U.S. Patent No. 12,021,989 in view of Koch et al. (U.S. Patent Application Publication 2017/0132425). As may be seen in Table 1 below, claim 1 of the instant application is closely parallel to claim 1 of the ‘989 patent, except for reciting “determining … to make available for licensing” in place of “interpreting … a request from a learning object owner to make available for licensing”. Elements present in one claim but not the parallel claim are bolded in Table 1. Such determining might be considered inherent, but if not, Koch teaches (paragraph 87, emphasis added), “Conventionally, the creative professional manually examines each of these images to determine which images are to be made available for licensing from a content sharing service 104.” Hence, it would have been obvious to one of ordinary skill in the art of electronic commerce on the date of inventors’ earliest priority to perform such determining, for at least the obvious advantage of making available for licensing learning objects which it would be profitable or otherwise beneficial to make available.
Claim 2 of the instant application is largely parallel to claim 2 of the ‘989 patent, except with “wherein the determining . . . comprises one or more of” in place of “wherein the interpreting . . . comprises one or more of”, and the additional limitations “soliciting a request from the learning object owner computing device to make the set of learning objects available for licensing; interpreting the request from the license owner computing device to make available for licensing the set of learning objects to produce the object basics record”. The interpreting step corresponds to language of claim 1 of the ‘989 patent. The soliciting step does not narrow claim 2 of the instant application as compared with claim 2 of the ‘989 patent, since it is only an option; 2 of the instant application recites that the determining comprises “one or more” of the listed operations, not all of them. Claim 3 of the instant application is then parallel to claim 3 of the ‘989 patent. Claim 4 of the instant application is then parallel to claim 4 of the ‘989 patent. Claim 5 of the instant application is then parallel to claim 5 of the ‘989 patent. Claim 6 of the instant application is then parallel to claim 6 of the ‘989 patent. These are shown in Table 1 below.
Table 1
Instant Application
U.S. Patent 12,021,989
1. A computer-implemented method of using a computing infrastructure for utilizing an object distributed ledger, the method comprising:
determining, by a marketplace computing device of the computing infrastructure, to make available for licensing a set of learning objects associated with a learning object owner computing device of the computing infrastructure to produce an object basics record of a smart contract for the set of learning objects, wherein the learning object owner computing device is distinct from the marketplace computing device, wherein the object basics record includes a learning object set identifier of the set of learning objects, a course number associated with the set of learning objects, and at least one learning object owner identifier associated with the set of learning objects;
verifying, by the marketplace computing device, with an accreditation authority computing device of the computing infrastructure, validity of the object basics record; and
when the object basics record is valid: establishing, by the marketplace computing device, available license terms of the smart contract for the set of learning objects, establishing, by the marketplace computing device, available payment terms of the smart contract for the set of learning objects, and causing, by the marketplace computing device, generation of a non-fungible token associated with the smart contract in the object distributed ledger.
2. The method of claim 1, wherein the determining to make available for licensing the set of learning objects to produce the object basics record of the smart contract comprises one or more of: identifying a set of learning object identifiers for the set of learning objects;
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;
soliciting a request from the learning object owner computing device to make the set of learning objects available for licensing;
interpreting the request from the learning object owner computing device to make available for licensing the set of learning objects to produce the object basics record;
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.
3. The method of claim 1, wherein the verifying the validity of the object basic record comprises:
identifying the accreditation authority computing device based on a first identified corresponding accreditation authority of the object basics record for a first learning object of the set of learning objects;
obtaining accreditation information from the accreditation authority computing device for the first learning object of the set of learning objects; and
indicating that the object basics record is valid for the first learning object when the accreditation information is substantially the same as the object basics record for the first learning object.
4. The method of claim 1, wherein the establishing the available license terms of the smart contract for the set of learning objects comprises:
establishing baseline available license terms from a terms template;
modifying the baseline available license terms based on the object basics record to produce proposed available license terms;
determining whether the proposed available license terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available license terms as the available license terms for the smart contract when the proposed available license terms are acceptable to the set of owners.
5. The method of claim 1, wherein the establishing the available payment terms of the smart contract for the set of learning objects comprises:
establishing baseline available payment terms from a terms template;
modifying the baseline available payment terms based on the object basics record to produce proposed available payment terms;
determining whether the proposed available payment terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available payment terms as the available payment terms for the smart contract when the proposed available payment terms are acceptable to the set of owners.
6. The method of claim 1, wherein the causing the generation of the non-fungible token associated with the smart contract in the object distributed ledger comprises:
determining whether to indirectly or directly update the object distributed ledger;
when indirectly updating the object distributed ledger: issuing a non-fungible token generation request to an object ledger computing device of the computing infrastructure serving as a blockchain node of the object distributed ledger, wherein the non-fungible token generation request includes the smart contract; and
when directly updating the object distributed ledger: obtaining a copy of the object distributed ledger, hashing the smart contract utilizing a receiving public key of the object distributed ledger to produce a next transaction hash value, encrypting the next transaction hash value utilizing a private key of the marketplace computing device to produce a next transaction signature, generating a next block of a blockchain of the object distributed ledger to include the smart contract and the next transaction signature, and causing inclusion of the next block as the non-fungible token in the object distributed ledger.
1. A computer-implemented method of using a computing infrastructure for utilizing an object distributed ledger, the method comprising:
interpreting, by a marketplace computing device of the computing infrastructure, a request from a learning object owner computing device of the computing infrastructure to make available for licensing a set of learning objects associated with a learning object owner computing device of the computing infrastructure to produce an object basics record of a smart contract for the set of learning objects, wherein the learning object owner computing device is distinct from the marketplace computing device, wherein the object basics record includes a learning object set identifier of the set of learning objects, a course number associated with the set of learning objects, and at least one learning object owner identifier associated with the set of learning objects;
verifying, by the marketplace computing device, with an accreditation authority computing device of the computing infrastructure, validity of the object basics record; and
when the object basics record is valid: establishing, by the marketplace computing device, available license terms of the smart contract for the set of learning objects, establishing, by the marketplace computing device, available payment terms of the smart contract for the set of learning objects, and causing, by the marketplace computing device, generation of a non-fungible token associated with the smart contract in the object distributed ledger.
2. The method of claim 1, wherein the interpreting the request to make available for licensing the set of g objects to produce the object basics record of the smart contract comprises one or more of:
identifying a set of learning object identifiers for the set of learning objects;
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;
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.
3. The method of claim 1, wherein the verifying the validity of the object basic record comprises:
identifying the accreditation authority computing device based on a first identified corresponding accreditation authority of the object basics record for a first learning object of the set of learning objects;
obtaining accreditation information from the accreditation authority computing device for the first learning object of the set of learning objects; and
indicating that the object basics record is valid for the first learning object when the accreditation information is substantially the same as the object basics record for the first learning object.
4. The method of claim 1, wherein the establishing the available license terms of the smart contract for the set of learning objects comprises:
establishing baseline available license terms from a terms template;
modifying the baseline available license terms based on the object basics record to produce proposed available license terms;
determining whether the proposed available license terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available license terms as the available license terms for the smart contract when the proposed available license terms are acceptable to the set of owners.
5. The method of claim 1, wherein the establishing the available payment terms of the smart contract for the set of learning objects comprises:
establishing baseline available payment terms from a terms template;
modifying the baseline available payment terms based on the object basics record to produce proposed available payment terms;
determining whether the proposed available payment terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available payment terms as the available payment terms for the smart contract when the proposed available payment terms are acceptable to the set of owners.
6. The method of claim 1, wherein the causing the causing the generation of the non-fungible token associated with the smart contract in the object distributed ledger comprises:
determining whether to indirectly or directly update the object distributed ledger;
when indirectly updating the object distributed ledger: issuing a non-fungible token generation request to an object ledger computing device of the computing infrastructure serving as a blockchain node of the object distributed ledger, wherein the non-fungible token generation request includes the smart contract; and
when directly updating the object distributed ledger: obtaining a copy of the object distributed ledger, hashing the smart contract utilizing a receiving public key of the object distributed ledger to produce a next transaction hash value, encrypting the next transaction hash value utilizing a private key of the marketplace computing device to produce a next transaction signature, generating a next block of a blockchain of the object distributed ledger to include the smart contract and the next transaction signature, and causing inclusion of the next block as the non-fungible token in the object distributed ledger.
Claims 7, 8, 9, 10, 11, and 12 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 7, 8, 9, 10, 11, and 12 of U.S. Patent No. 12,021,989 in view of Koch et al. (U.S. Patent Application Publication 2017/0132425). As may be seen in Table 2 below, claim 7 of the instant application is closely parallel to claim 3 of the ‘989 patent, except for reciting “determine to make available for licensing” in place of “interpreting a request from a learning object owner computing device … to make available for licensing”. Elements present in one claim but not the parallel claim are bolded in Table 2. Such determining might be considered inherent, but if not, Koch teaches (paragraph 87, emphasis added), “Conventionally, the creative professional manually examines each of these images to determine which images are to be made available for licensing from a content sharing service 104.” Hence, it would have been obvious to one of ordinary skill in the art of electronic commerce on the date of inventors’ earliest priority for the processor function to determine, as recited, for at least the obvious advantage of making available for licensing learning objects which it would be profitable or otherwise beneficial to make available.
Claim 8 of the instant application is largely parallel to claim 8 of the ‘989 patent, except with “to determine to make available for licensing . . . by one or more of” in place of “to interpret the request to make available for licensing . . . by one or more of”, and the additional limitations “soliciting a request from the learning object owner computing device to make the set of learning objects available for licensing; interpreting the request from the license owner computing device to make available for licensing the set of learning objects to produce the object basics record”. The interpreting step corresponds to language of claim 7 of the ‘989 patent. The soliciting step does not narrow claim 8 of the instant application as compared with claim 8 of the ‘989 patent, since it is only an option; claim 8 of the instant application recites that the determining comprises “one or more” of the listed operations, not all of them. Claim 9 of the instant application is then parallel to claim 9 of the ‘989 patent. Claim 10 of the instant application is then parallel to claim 10 of the ‘989 patent. Claim 11 of the instant application is then parallel to claim 11 of the ‘989 patent. Claim 12 of the instant application is then parallel to claim 12 of the ‘989 patent. These are shown in Table 2 below.
Table 2
Instant Application
U.S. Patent 12,021,989
7. A marketplace computing device of a computing infrastructure, the marketplace computing device comprising:
an interface;
a local memory; and
a processor operably coupled to the interface and the local memory, wherein the processor performs functions to:
determine to make available for licensing a set of learning objects associated with a learning object owner computing device of the computing infrastructure to produce an object basics record of a smart contract for the set of learning objects, wherein the learning object owner computing device is distinct from the marketplace computing device, wherein the object basics record includes a learning object set identifier of the set of learning objects, a course number associated with the set of learning objects, and at least one learning object owner identifier associated with the set of learning objects;
verify with an accreditation authority computing device of the computing infrastructure, validity of the object basics record; and
when the object basics record is valid: establish available license terms of the smart contract for the set of learning objects,
establish available payment terms of the smart contract for the set of learning objects, and
cause generation of a non-fungible token associated with the smart contract in the object distributed ledger.
8. The marketplace computing device of claim 7, wherein the processor performs functions to determine to make available for licensing the set of learning objects to produce the object basics record of the smart contract by one or more of:
identifying a set of learning object identifiers for the set of learning objects; 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;
soliciting a request from the learning object owner computing device to make the set of learning objects available for licensing;
interpreting the request from the learning object owner computing device to make available for licensing the set of learning objects to produce the object basics record;
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.
9. The marketplace computing device of claim 7, wherein the processor performs functions to verify the validity of the object basics by:
identifying the accreditation authority computing device based on a first identified corresponding accreditation authority of the object basics record for a first learning object of the set of learning objects;
obtaining accreditation information from the accreditation authority computing device for the first learning object of the set of learning objects; and
indicating that the object basics record is valid for the first learning object when the accreditation information is substantially the same as the object basics record for the first learning object.
10. The marketplace computing device of claim 7, wherein the processor performs functions to establish the available license terms of the smart contract for the set of learning objects by:
establishing baseline available license terms from a terms template;
modifying the baseline available license terms based on the object basics record to produce proposed available license terms;
determining whether the proposed available license terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available license terms as the available license terms for the smart contract when the proposed available license terms are acceptable to the set of owners.
11. The marketplace computing device of claim 7, wherein the processor performs functions to establish the available payment terms of the smart contract for the set of learning objects by:
establishing baseline available payment terms from a terms template;
modifying the baseline available payment terms based on the object basics record to produce proposed available payment terms;
determining whether the proposed available payment terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available payment terms as the available payment terms for the smart contract when the proposed available payment terms are acceptable to the set of owners.
12. The marketplace computing device of claim 7, wherein the processor performs functions to cause the generation of the non-fungible token associated with the smart contract in the object distributed ledger by:
determining whether to indirectly or directly update the object distributed ledger;
when indirectly updating the object distributed ledger: issuing a non-fungible token generation request to an object ledger computing device of the computing infrastructure serving as a blockchain node of the object distributed ledger, wherein the non-fungible token generation request includes the smart contract; and
when directly updating the object distributed ledger: obtaining a copy of the object distributed ledger, hashing the smart contract utilizing a receiving public key of the object distributed ledger to produce a next transaction hash value, encrypting the next transaction hash value utilizing a private key of the marketplace computing device to produce a next transaction signature, generating a next block of a blockchain of the object distributed ledger to include the smart contract and the next transaction signature, and causing inclusion of the next block as the non-fungible token in the object distributed ledger.
7. A marketplace computing device of a computing infrastructure, the marketplace computing device comprising:
an interface;
a local memory; and
a processor operably coupled to the interface and the local memory, wherein the processor performs functions to:
interpret a request from a learning object owner computing device of the computing infrastructure to make available for licensing a set of learning objects to produce an object basics record of a smart contract for the set of learning objects, wherein the learning object owner computing device is distinct from the marketplace computing device, wherein the object basics record includes a learning object set identifier of the set of learning objects, a course number associated with the set of learning objects, and at least one learning object owner identifier associated with the set of learning objects;
verify with an accreditation authority computing device of the computing infrastructure, validity of the object basics record; and
when the object basics record is valid: establish available license terms of the smart contract for the set of learning objects,
establish available payment terms of the smart contract for the set of learning objects, and
cause generation of a non-fungible token associated with the smart contract in the object distributed ledger.
8. The marketplace computing device of claim 7, wherein the processor performs functions to interpret the request to make available for licensing the set of learning objects to produce the object basics record of the smart contract by one or more of:
identifying a set of learning object identifiers for the set of learning objects;
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;
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.
9. The marketplace computing device of claim 7, wherein the processor performs functions to verify the validity of the object basics by:
identifying the accreditation authority computing device based on a first identified corresponding accreditation authority of the object basics record for a first learning object of the set of learning objects;
obtaining accreditation information from the accreditation authority computing device for the first learning object of the set of learning objects; and
indicating that the object basics record is valid for the first learning object when the accreditation information is substantially the same as the object basics record for the first learning object.
10. The marketplace computing device of claim 7, wherein the processor performs functions to establish the available license terms of the smart contract for the set of learning objects by:
establishing baseline available license terms from a terms template;
modifying the baseline available license terms based on the object basics record to produce proposed available license terms;
determining whether the proposed available license terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available license terms as the available license terms for the smart contract when the proposed available license terms are acceptable to the set of owners.
11. The marketplace computing device of claim 7, wherein the processor performs functions to establish the available payment terms of the smart contract for the set of learning objects by:
establishing baseline available payment terms from a terms template;
modifying the baseline available payment terms based on the object basics record to produce proposed available payment terms;
determining whether the proposed available payment terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available payment terms as the available payment terms for the smart contract when the proposed available payment terms are acceptable to the set of owners.
11. The marketplace computing device of claim 7, wherein the processor performs functions to cause the generation of the non-fungible token associated with the smart contract in the object distributed ledger by:
determining whether to indirectly or directly update the object distributed ledger;
when indirectly updating the object distributed ledger: issuing a non-fungible token generation request to an object ledger computing device of the computing infrastructure serving as a blockchain node of the object distributed ledger, wherein the non-fungible token generation request includes the smart contract; and
when directly updating the object distributed ledger: obtaining a copy of the object distributed ledger, hashing the smart contract utilizing a receiving public key of the object distributed ledger to produce a next transaction hash value, encrypting the next transaction hash value utilizing a private key of the marketplace computing device to produce a next transaction signature, generating a next block of a blockchain of the object distributed ledger to include the smart contract and the next transaction signature, and causing inclusion of the next block as the non-fungible token in the object distributed ledger.
Claims 13, 14, 15, 16, 17, and 18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 13, 14, 15, 16, 17, and 18 of U.S. Patent No. 12,021,989 in view of Koch et al. (U.S. Patent Application Publication 2017/0132425). As may be seen in Table 3 below, claim 13 of the instant application is closely parallel to claim 13 of the ‘989 patent, except for reciting “determine to make available for licensing” in place of “interpreting a request from a learning object owner computing device … to make available for licensing”. Elements present in one claim but not the parallel claim are bolded in Table 3. Such determining might be considered inherent, but if not, Koch teaches (paragraph 87, emphasis added), “Conventionally, the creative professional manually examines each of these images to determine which images are to be made available for licensing from a content sharing service 104.” Hence, it would have been obvious to one of ordinary skill in the art of electronic commerce on the date of inventors’ earliest priority for the processor function to determine, as recited, for at least the obvious advantage of making available for licensing learning objects which it would be profitable or otherwise beneficial to make available.
Claim 14 of the instant application is largely parallel to claim 14 of the ‘989 patent, except with “to determine to make available for licensing . . . by one or more of” in place of “to interpret the request to make available for licensing . . . by one or more of”, and the additional limitations “soliciting a request from the learning object owner computing device to make the set of learning objects available for licensing; interpreting the request from the license owner computing device to make available for licensing the set of learning objects to produce the object basics record”. The interpreting step corresponds to language of claim 13 of the ‘989 patent. The soliciting step does not narrow claim 14 of the instant application as compared with claim 14 of the ‘989 patent, since it is only an option; claim 14 of the instant application recites that the determining comprises “one or more” of the listed operations, not all of them. Claim 15 of the instant application is then parallel to claim 15 of the ‘989 patent. Claim 16 of the instant application is then parallel to claim 16 of the ‘989 patent. Claim 17 of the instant application is then parallel to claim 17 of the ‘989 patent. Claim 18 of the instant application is then parallel to claim 18 of the ‘989 patent. These are shown in Table 3 below.
Table 3
Instant Application
U.S. Patent 12,021,989
1. A non-transitory computer-readable memory comprising:
a first memory element that stores operational instructions that, when executed by a processing module, cause the processing module to: determine to make available for licensing a set of learning objects associated with a learning object owner computing device of a computing infrastructure to produce an object basics record of a smart contract for the set of learning objects, wherein the learning object owner computing device is distinct from the processing module, wherein the object basics record includes a learning object set identifier of the set of learning objects, a course number associated with the set of learning objects, and at least one learning object owner identifier associated with the set of learning objects; a second memory element that stores operational instructions that, when executed by the processing module, cause the processing module to: verify with an accreditation authority computing device of the computing infrastructure, validity of the object basics record; and a third memory element that stores operational instructions that, when executed by the processing module, cause the processing module to: when the object basics record is valid: establish available license terms of the smart contract for the set of learning objects, establish available payment terms of the smart contract for the set of learning objects, and cause generation of a non-fungible token associated with the smart contract in an object distributed ledger.
14. The non-transitory medium of claim 13, wherein the processing module functions to execute the operational instructions stored by the first memory element to cause the processing module to determine to make available for licensing the set of learning objects to produce the object basics record of the smart contract by one or more of:
identifying a set of learning object identifiers for the set of learning objects; 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;
soliciting a request from the learning object owner computing device to make the set of learning objects available for licensing;
interpreting the request from the learning object owner computing device to make available for licensing the set of learning objects to produce the object basics record;
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.
15. The non-transitory medium of claim 13, wherein the processing module functions to execute the operational instructions stored by the second memory element to cause the processing module to verify the validity of the object basics record by:
identifying the accreditation authority computing device based on a first identified corresponding accreditation authority of the object basics record for a first learning object of the set of learning objects;
obtaining accreditation information from the accreditation authority computing device for the first learning object of the set of learning objects; and
indicating that the object basics record is valid for the first learning object when the accreditation information is substantially the same as the object basics record for the first learning object.
16. The non-transitory medium of claim 13, wherein the processing module functions to execute the operational instructions stored by the third memory element to cause the processing module to establish the available license terms of the smart contract for the set of learning objects by:
establishing baseline available license terms from a terms template;
modifying the baseline available license terms based on the object basics record to produce proposed available license terms;
determining whether the proposed available license terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available license terms as the available license terms for the smart contract when the proposed available license terms are acceptable to the set of owners.
17. The non-transitory medium of claim 13, wherein the processing module functions to execute the operational instructions stored by the third memory element to cause the processing module to establish the available payment terms of the smart contract for the set of learning objects by:
establishing baseline available payment terms from a terms template;
modifying the baseline available payment terms based on the object basics record to produce proposed available payment terms;
determining whether the proposed available payment terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available payment terms as the available payment terms for the smart contract when the proposed available payment terms are acceptable to the set of owners.
E18e. The non-transitory medium of claim 13, wherein the processing module functions to execute the operational instructions stored by the third memory element to cause the processing module to cause the generation of the non-fungible token associated with the smart contract in the object distributed ledger by:
determining whether to indirectly or directly update the object distributed ledger;
when indirectly updating the object distributed ledger: issuing a non-fungible token generation request to an object ledger computing device of the computing infrastructure serving as a blockchain node of the object distributed ledger, wherein the non-fungible token generation request includes the smart contract; and
when directly updating the object distributed ledger: obtaining a copy of the object distributed ledger, hashing the smart contract utilizing a receiving public key of the object distributed ledger to produce a next transaction hash value, encrypting the next transaction hash value utilizing a private key of the marketplace computing device to produce a next transaction signature, generating a next block of a blockchain of the object distributed ledger to include the smart contract and the next transaction signature, and causing inclusion of the next block as the non-fungible token in the object distributed ledger.
1. A non-transitory computer-readable medium comprising:
a first memory element that stores operational instructions that, when executed by a processing module, cause the processing module to: interpret a request from a learning object owner computing device of a computing infrastructure to make available for licensing a set of learning objects associated with a learning object owner computing device of a computing infrastructure to produce an object basics record of a smart contract for the set of learning objects, wherein the learning object owner computing device is distinct from the processing module, wherein the object basics record includes a learning object set identifier of the set of learning objects, a course number associated with the set of learning objects, and at least one learning object owner identifier associated with the set of learning objects; a second memory element that stores operational instructions that, when executed by the processing module, cause the processing module to: verify with an accreditation authority computing device of the computing infrastructure, validity of the object basics record; and a third memory element that stores operational instructions that, when executed by the processing module, cause the processing module to: when the object basics record is valid: establish available license terms of the smart contract for the set of learning objects, establish available payment terms of the smart contract for the set of learning objects, and cause generation of a non-fungible token associated with the smart contract in an object distributed ledger.
14. The non-transitory medium of claim 13, wherein the processing module functions to execute the operational instructions stored by the first memory element to cause the processing module to interpret the request to make available for licensing the set of learning objects to produce the object basics record of the smart contract by one or more of:
identifying a set of learning object identifiers for the set of learning objects;
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;
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.
15. The non-transitory medium of claim 13, wherein the processing module functions to execute the operational instructions stored by the second memory element to cause the processing module to verify the validity of the object basics record by:
identifying the accreditation authority computing device based on a first identified corresponding accreditation authority of the object basics record for a first learning object of the set of learning objects;
obtaining accreditation information from the accreditation authority computing device for the first learning object of the set of learning objects; and
indicating that the object basics record is valid for the first learning object when the accreditation information is substantially the same as the object basics record for the first learning object.
16. The non-transitory medium of claim 13, wherein the processing module functions to execute the operational instructions stored by the third memory element to cause the processing module to establish the available license terms of the smart contract for the set of learning objects by:
establishing baseline available license terms from a terms template;
modifying the baseline available license terms based on the object basics record to produce proposed available license terms;
determining whether the proposed available license terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available license terms as the available license terms for the smart contract when the proposed available license terms are acceptable to the set of owners.
17. The non-transitory medium of claim 13, wherein the processing module functions to execute the operational instructions stored by the third memory element to cause the processing module to establish the available payment terms of the smart contract for the set of learning objects by:
establishing baseline available payment terms from a terms template;
modifying the baseline available payment terms based on the object basics record to produce proposed available payment terms;
determining whether the proposed available payment terms are acceptable to a set of owners associated with the set of learning objects; and
establishing the proposed available payment terms as the available payment terms for the smart contract when the proposed available payment terms are acceptable to the set of owners
E17e. The non-transitory medium of claim 13, wherein the processing module functions to execute the operational instructions stored by the third memory element to cause the processing module to cause the generation of the non-fungible token associated with the smart contract in the object distributed ledger by:
determining whether to indirectly or directly update the object distributed ledger;
when indirectly updating the object distributed ledger: issuing a non-fungible token generation request to an object ledger computing device of the computing infrastructure serving as a blockchain node of the object distributed ledger, wherein the non-fungible token generation request includes the smart contract; and
when directly updating the object distributed ledger: obtaining a copy of the object distributed ledger, hashing the smart contract utilizing a receiving public key of the object distributed ledger to produce a next transaction hash value, encrypting the next transaction hash value utilizing a private key of the marketplace computing device to produce a next transaction signature, generating a next block of a blockchain of the object distributed ledger to include the smart contract and the next transaction signature, and causing inclusion of the next block as the non-fungible token in the object distributed ledger.
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.
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.
Claims 1, 2, 7, 8, 13, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Elmessiry et al. (U.S. Patent Application Publication 2019/0340946) in view of Raskin et al. (U.S. Patent Application Publication 2016/0117339), Castro-Leon et al. (U.S. Patent Application Publication 2014/0006815), and Turner et al. (U.S. Patent Application Publication 2022/0271915). As per claim 1, Elmessiry discloses licensing of an educational offering (paragraph 107, emphasis added), “The educational offering may be repeated, resold, licensed, or otherwise used in multiple instances. The education platform 108 may license the educator-generated educational offering. The education platform 108 may license the educator-generated educational offering to another educator user 116. Licensing the educational offering may include allowing the other educator user 116 to use or access materials from the licensed educational offering.” The use of “materials’ in the plural indicates a set of learning objects. Elmessiry further discloses a smart contract for the set of learning objects (paragraph 107, emphasis added), “The education platform 108 may generate a smart contract 106 on the blockchain 102 that may be configured to send royalty payments to the educator user 116 or another owner for use of the educator-generated educational offering.”
Elmessiry further discloses utilizing an object distributed ledger (paragraph 32, emphasis added), “The system 100 may include a blockchain 102. The blockchain 102 may include a cryptographically secured, distributed ledger that may be shared across a network of one or more computing devices called ‘nodes.’” Elmessiry does not disclose producing an object basics record of a smart contract for the set of learning objects, wherein the object basics record includes a learning object set identifier of the set of learning objects, a course number associated with the set of learning objects, and at least one learning object owner identifier associated with the set of learning objects. However, Raskin teaches a set of learning objects (lectures) including a course number and other identifiers, e.g., of an academic institution or a lecturer, either of which may be an owner (paragraph 64, emphasis added), “In some embodiments, portions of a lecture are uploaded to the education platform 400 rather than an entire lecture. The recorded lectures may include an audio file, a video file, or both. In one embodiment, a recorded lecture uploaded to the education platform 400 is associated with metadata defining properties of the lecture, such as a title, an academic domain, information about a course with which the lecture is associated (e.g., a course title, course number, academic institution, and a time lectures are delivered), a description of the lecture, and the name of the instructor providing the lecture. The recorded lecture may also be associated with access rights defining permissions for access to the lecture.” Hence, it would have been obvious to one of ordinary skill in the art of electronic commerce on the date of inventors’ earliest priority to produce an object basics record of a smart contract for the set of learning objects, wherein the object basics record includes a learning object set identifier of the set of learning objects, a course number associated with the set of learning objects, and at least one learning object owner identifier associated with the set of learning objects, for such obvious advantages as being able to readily identify which lecture, course of lectures and other instructions, or other learning object or objects were being offered.
Elmessiry does not disclose verifying, by the marketplace computing device, with an accreditation authority computing device of the computing infrastructure, validity of the object basics record, but Castro-Leon teaches verifying a record with an authentication computing device (paragraph 50, emphasis added), “According to embodiments, the method may further include generating a message authentication code with the record to the remote server, in response to the request, to enable the remote server to verify the authenticity of the record.” Hence, it would have been obvious to one of ordinary skill in the art of electronic commerce on the date of inventors’ earliest priority to verify, by the marketplace computing device, with an accreditation authority computing device of the computing infrastructure, validity of the object basics record, for such obvious advantages as being able to be confident of the validity of the object basics record, and avoid, for example, entering into a contract based on an in accurate or entirely bogus object basics record.
Elmessiry further discloses licensing relating to learning objects (paragraph 107, emphasis added), “The educational offering may be repeated, resold, licensed, or otherwise used in multiple instances. The education platform 108 may license the educator-generated educational offering. The education platform 108 may license the educator-generated educational offering to another educator user 116. Licensing the educational offering may include allowing the other educator user 116 to use or access materials from the licensed educational offering.” Given the different possible licensing terms and corresponding obligations, establishing available license terms of the smart contract for the set of learning objects would have been at least obvious to one of ordinary skill in the art of electronic commerce on the date of inventors’ earliest priority, for such obvious advantages as enabling a first educator and a potential customer to know what licensing terms were being offered or what licensing terms they were agreeing to, and, for example, enabling a smart contract to implement the licensing terms.
Elmessiry further discloses payment terms for one or more learning objects (paragraph 41, emphasis added), “A term or condition of the smart contract may include a cost of an educational offering, a length of time of an educational offering, an educator that may teach an educational offering, a size of and [sic, should presumably be “an”] educational offering (e.g., a class size), a location of an educational offering (e.g., a room of a physical facility, online), a material that may be required for an educational offering (e.g., a specified textbook), a service provider (e.g., a translator, caterer, transportation provider), a payment date for an educator, a condition in which a student receives a proof of completion upon completion of an educational offering, or other terms or conditions.” See also paragraph 107, quoted from in the previous paragraph of the present Office Action.
Elmessiry does not disclose causing, by the marketplace computing device, generation of a non-fungible token associated with the smart contract in the object distributed ledger, but Turner teaches generating at least one non-fungible token, by and therefore associated with a smart contract (paragraph 110, emphasis added), “In an embodiment, at step 704, the client device 120 and/or 125 or the smart contract that generates that first non-fungible token may store the non-fungible token on a blockchain.” Moreover, a blockchain is a distributed ledger. Hence, it would have been obvious to one of ordinary skill in the art of electronic commerce on the date of inventors’ earliest priority to cause, by the marketplace computing device, generation of a non-fungible token associated with the smart contract in the object distributed ledger, for at least the obvious advantages of providing a customer with a secure record of what learning objects he is entitled to, and on what terms.
As per claim 2, Raskin teaches learning object identifiers of a set of learning objects (paragraph 64, emphasis added), “In some embodiments, portions of a lecture are uploaded to the education platform 400 rather than an entire lecture. The recorded lectures may include an audio file, a video file, or both. In one embodiment, a recorded lecture uploaded to the education platform 400 is associated with metadata defining properties of the lecture, such as a title, an academic domain, information about a course with which the lecture is associated (e.g., a course title, course number, academic institution, and a time lectures are delivered), a description of the lecture, and the name of the instructor providing the lecture. The recorded lecture may also be associated with access rights defining permissions for access to the lecture.” Raskin further teaches identifying or determining such learning object identifiers for learning objects (paragraph 72, emphasis added), “If a recorded lecture has incomplete metadata (e.g., if the metadata does not identify a course title, course number, or institution associated with the course), one embodiment of the processing module 414 analyzes the registered users 432 accessing the recorded lecture. For example, if a majority of the registered users 432 accessing a lecture are associated with a particular educational institution, the processing module 414 determines the lectures to be associated with that institution. As another example, if a majority of the registered users 432 accessing a lecture are associated with a particular course, the processing module 414 determines the lectures to be associated with the course.” Hence, it would have been obvious to one of ordinary skill in the art of electronic commerce on the date of inventors’ earliest priority for the determining to comprise one or more of at least identifying a set of learning object identifiers for the set of learning objects, for at least the obvious advantage of being able to clearly identify the set of learning objects, and conveniently refer to particular learning objects as needed.
As per claim 7, this is a machine claim essentially parallel to method claim 1, and therefore obvious on essentially the same grounds set forth above with respect to claim 1, except that claim 7 additionally recites the marketplace computing device comprising: an interface, a local memory; and a processor operably coupled to the interface and the local memory, wherein the processor performs functions. Elmessiry further discloses a memory, which can be local, and a processor operably coupled to the memory (paragraph 12, emphasis added), “Another aspect of the disclosure may include non-transitory computer-readable storage medium. The computer-readable storage medium may include a processor and a set of instructions executable by the processor. The processor executing the set of instructions may cause the processor to implement a method.” Further in paragraph 136 (emphasis added), Elmessiry discloses, “The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.” Further in paragraph 137 (emphasis added), Elmessiry discloses, “The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (‘RAM’), a read-only memory (‘ROM’), an erasable programmable read-only memory (‘EPROM’ or Flash memory), a static random access memory (‘SRAM’), a portable compact disc read-only memory (‘CD-ROM’), a digital versatile disk (‘DVD’), a memory stick, a floppy disk, a mechanically encoded device such as punch-card or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.”
Also, Elmessiry discloses an interface (e.g., paragraph 108, emphasis added), “FIG. 8A depicts one embodiment of a user interface 800. The user interface 800 may include an educator user interface. The computing device of an educator user 116 may displace [sic, presumably an error for ‘display’] the user interface 800. The educator user 116 may interact with the user interface 800 to add an educational offering to the system 100.”
As per claim 8, claim 8 is parallel to claim 2, and obvious on the grounds set forth above with respect to claim 2.
As per claim 13, this is an article of manufacture claim essentially parallel to method claim 1, and therefore obvious on essentially the same grounds set forth above with respect to claim 1, except that claim 13 additionally recites a non-transitory computer readable memory comprising memory elements. Elmessiry discloses a non-transitory computer readable memory (paragraph 12, emphasis added), “Another aspect of the disclosure may include non-transitory computer-readable storage medium. The computer-readable storage medium may include a processor and a set of instructions executable by the processor. The processor executing the set of instructions may cause the processor to implement a method.”
As per claim 14, claim 8 is parallel to claim 2, and obvious on the grounds set forth above with respect to claim 2.
Claims 4, 5, 10, 11, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Elmessiry et al. (U.S. Patent Application Publication 2019/0340946), Raskin et al. (U.S. Patent Application Publication 2016/0117339), Castro-Leon et al. (U.S. Patent Application Publication 2014/0006815), and Turner et al. (U.S. Patent Application Publication 2022/0271915), as applied to claim 1 (for claims 4 and 5), claim 7 (for claims 10 and 11), and claim 13 (for claims 16 and 17) above, respectively, and further in view of Haynes (U.S. Patent 7,092,953). As per claims 4, 10, and 16, Elmessiry does not disclose the elements of claim 4 and the dependent claims parallel to claim 4, but Haynes teaches establishing baseline available license terms from a terms template, and modifying the baseline available license terms based on specifics to produce proposed available license terms (column 6, lines 54-63, emphasis added), “At state 228, a license agreement, also called a deal memo, template is created. The license agreement template allows the seller to create a standard format for deals involving a particular type of property. The rights owner application may populate the license agreement template with selected initial information, including, as a default, information from the request template. The license agreement template may then be provided in response to buyer or licensee requests. The seller can modify the license agreement template terms for a specific transaction or deal.” See also Haynes, column 6, lines 19-38, emphasis added, in particular: “At state 226, the owner’s or the seller’s administrator creates or customized a license request template in accordance with the owner’s needs or requirements.”
Haynes further teaches determining whether proposed available license terms are acceptable to an owner/licensor, and establishing the proposed available license terms as the available license terms when the proposed available license terms are acceptable to the owner/licensor (column 12, line 59, through column 13, line 3, emphasis added), “In this example, the licensor can accept the buyer’s request 318, reject the request 320, choose to negotiate with the buyer 322, or, at state 324, may conduct further research into the buyer’s request, including into the buyer’s background, intended use of the property and other criteria. Such actions by the licensor may be reflected in real time on the licensing application 106, so that the buyer can view the licensor’s response. If the licensor accepts the buyer’s request, including offer terms, at state 318, a deal memo, a licensing agreement, or a purchase agreement incorporating the agreed upon specified terms, is generated.” Hence, it would have been obvious to one of ordinary skill in the art of electronic commerce on the date of inventors’ earliest priority to apply these teachings to the specifics of a smart contract regarding learning objects, for at least such obvious advantages as creating a standard format, and establishing proposed available licensing terms, which, being acceptable to one side (the owners or owner/licensor), at least may provide the basis for a mutually beneficial agreement.
As per claims 5, 11, and 17, these are parallel to claims 4, 10, and 16, except specific to payment terms instead of licensing terms. They are therefore largely obvious in view of the teachings of Haynes, as set forth above with regard to claims 4, 10, and 16. Haynes further teaches that licensing terms include price, which typically involves payment (column 15, lines 2-5, emphasis added), “The terms may include such information as term availability of rights, asking price by licensor, and other information such as number of requests for that property.” Haynes further teaches (column 15, lines 47-51, emphasis added), “The rights owner application 102 may also provide other help. For example, a dynamic pricing matrix specifying base price for licensing or sale of property rights based on such factors as territory, language, term, and rights requested, may be provided.” Hence, it would have been obvious to one of ordinary skill in the art of electronic commerce on the date of inventors’ earliest priority to apply the teachings of Haynes specifically to payment terms, for at least the obvious advantage of establishing reasonable and acceptable payment terms (including, but not necessarily limited to price) that at least may provide the basis for a mutually beneficial agreement.
Non-Obvious Subject Matter
Claim 3 is rejected under 35 U.S.C. 101, rejected for double patenting, and objected to as depending from a claim that is rejected under 35 U.S.C. 103, but recites non-obvious subject matter.
Claim 9 is rejected under 35 U.S.C. 101, rejected for double patenting, and objected to as depending from a claim that is rejected under 35 U.S.C. 103, but recites non-obvious subject matter.
Claim 15 is rejected under 35 U.S.C. 101, rejected for double patenting, and objected to as depending from a claim that is rejected under 35 U.S.C. 103, but recites non-obvious subject matter.
As set forth above, Elmessiry et al. (U.S. Patent Application Publication 2019/0340946) discloses elements of claims 1, 7, and 13, with other limitations being found obvious in view of Raskin et al. (U.S. Patent Application Publication 2016/0117339), Castro-Leon et al. (U.S. Patent Application Publication 2014/0006815), and Turner et al. (U.S. Patent Application Publication 2022/0271915). Elmessiry and the other three references applied to claims 1, 7, and 13 do not disclose, teach, or reasonably suggest the specifics of claims 3, 9, and 15, in particular: identifying the accreditation authority computing device based on a first corresponding accreditation authority computing device of the object basics record for a first learning object of the set of learning objects; and obtaining accreditation information from the accreditation authority computing device for the first learning object of the set of learning objects. No other prior art of record supplies this deficiency.
Claim 6 is rejected under 35 U.S.C. 101, rejected for double patenting, and objected to as depending from a claim that is rejected under 35 U.S.C. 103, but recites non-obvious subject matter.
Claim 12 is rejected under 35 U.S.C. 101, rejected for double patenting, and objected to as depending from a claim that is rejected under 35 U.S.C. 103, but recites non-obvious subject matter.
Claim 18 is rejected under 35 U.S.C. 101, rejected for double patenting, and objected to as depending from a claim that is rejected under 35 U.S.C. 103, but recites non-obvious subject matter.
As set forth above, Elmessiry et al. (U.S. Patent Application Publication 2019/0340946) discloses elements of claims 1, 7, and 13, with other limitations being found obvious in view of Raskin et al. (U.S. Patent Application Publication 2016/0117339), Castro-Leon et al. (U.S. Patent Application Publication 2014/0006815), and Turner et al. (U.S. Patent Application Publication 2022/0271915). Elmessiry further discloses hashing (paragraph 72, emphasis added), “The information may include a hash of the educational certificate or a hash of a portion of information of the educational certificate.”
Elmessiry further discloses blocks of a blockchain (paragraph 32, emphasis added), “The system 100 may include a blockchain 102. The blockchain 102 may include a cryptographically secured, distributed ledger that may be shared across a network of one or more computing devices called ‘nodes.’ The one or more nodes may receive data describing transactions, assemble the received transactions into blocks, propose assembled blocks, and reach a conclusion as to which blocks to add to the blockchain 102. The blockchain 102 may include one or more transactions 104. The transactions of the accepted blocks may add to the transactions 104.”
Elmessiry further discloses a public key and a private key (paragraph 45, emphasis added), “The cryptocurrency wallet may include a public key and a private key.” However, Elmessiry does not expressly disclose updating a blockchain or ledger, and neither do Raskin, Castro-Leon, and Turner.
Elmessiry, alone or in combination with Raskin, Castro-Leon, and Turner, does not disclose, teach, or reasonably suggest the specifics of claim 6, or parallel claims 12 and 18. Panikkar et al. (U.S. Patent Application Publication 2022/0231846) teaches using a hash function and adding to a blockchain (paragraph 91, emphasis added), “OEM then creates a factory updated block 604 (FactoryUpdatedBlock) with the encrypted data and adds it to the blockchain using a hash function as is typically known.” Also, Panikkar teaches (paragraph 50, emphasis added), “The blocks are distributed to the partners via secure communication channels, who then update the placeholder blocks using blockchain technology and encryption logic keys as system variables.” However, neither Panikkar nor any other reference of record teaches the specific procedure of claims 6, 12, and 18, and there is insufficient motivation to combine the teachings of multiple further prior art references with the disclosures of Elmessiry and the three further references already applied in rejecting the independent claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Castro-Leon et al. (U.S. Patent 9,454,199) is the patent issued on an application whose Patent Application Publication was used in making rejections under 35 U.S.C. 103. Fuller et al. (U.S. Patent 9,460,273) discloses automatic generation of license terms. Koch et al. (U.S. Patent 10,198,590) is the patent issued on the application published as U.S. Patent Application Publication 2017/0132425, and used as a secondary reference in making double patenting rejections. Tran et al. (U.S. Patent 10,997,251) disclose a smart device. Vaish et al. (U.S. Patent 11,126,698) disclose a distributed ledger system that facilitates device management. Turner et al. (U.S. Patent 11,652,605) disclose advanced non-fungible token blockchain architecture. Panikkar et al. (U.S. Patent 11,799,641) disclose system functionality activation using a distributed ledger. Xue et al. (U.S. Patent 11,909,879) disclose systems and methods for generating customized non-fungible tokens. Bramlet et al. (U.S. Patent 11,917,065) has been considered for possible double patenting (rejections not made). Bramlet et al. (U.S. Patent 12,003,641) has been considered for possible double patenting (rejections not made). Bramlet et al. (U.S. Patent 12,101,405) has been considered for possible double patenting (rejections not made. Bramlet et al. (U.S. Patent 12,120,236) has been considered for possible double patenting (rejections not made). Bramlet et al. (U.S. Patent 12,165,540) has been considered for possible double patenting (rejections not made). Bramlet et al. (U.S. Patent 12,256,008) has been considered for possible double patenting (rejections not made). Bramlet et al. (U.S. Patent 12,375,282) has been considered for possible double patenting (rejections not made).
Fuller et al. (U.S. Patent Application Publication 2016/0125172) discloses automatic generation of license terms. Doney (U.S. Patent Application Publication 2020/0342539) discloses managing digital liquidity tokens. Xue et al. (U.S. Patent Application Publication 2022/0069996) disclose systems and methods for generating customized non-fungible tokens. Panikkar et al. (U.S. Patent Application Publication 2022/0231846) disclose system functionality activation using a distributed ledger. Turner et al. (U.S. Patent Application Publication 2022/0271915) disclose advanced non-fungible token blockchain architecture.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS D ROSEN, whose telephone number is (571)272-6762. The examiner can normally be reached 9:00 AM-5:30 PM, M-F. Non-official/draft communications may be faxed to the examiner at 571-273-6762, or emailed to Nicholas.Rosen@uspto.gov (in the body of an email, please, not as an attachment).
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, Marissa Thein, can be reached at 571-272-6764. 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.
/NICHOLAS D ROSEN/ Primary Examiner, Art Unit 3689 May 5, 2026
Prosecution Insights