DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending in this application.
Information Disclosure Statement
The IDS filed on 3/20/2025 has been considered.
Claim Objections
Claims 18-20 are objected to because of the following informalities: The claims all recite "The non-transitory computer-readable medium of claim 10..." Examiner believes the claims should recite "The non-transitory computer-readable medium of claim 11..." Appropriate correction is required.
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 3-5, 7-8, 13-15, and 17-18 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 3-8 and 13-18 recite the limitation "the step of." There is insufficient antecedent basis for this limitation in the claim. Examiner suggests simply deleting the phrase “the step of” from the claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bernabeu-Auban et al. (US Pub. No. 2006/0259489 A1 hereinafter Bernabeu-Auban) in view of Fontaine et al. (US Pub. No. 2022/0334900 A1 hereinafter Fontaine).
As per claim 1, Bernabeu-Auban teaches a method for managing an object (See Abstract), comprising: creating the object through an application programming interface (API) (¶ [0038], “Although not required, the invention can be implemented via an application programming interface (API), for use by a developer, and/or included within the network browsing software which will be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers, such as client workstations, servers, or other devices.” ¶ [0060]-[0062], “An object reference in some embodiments identifies the object to which the reference refers and is not able to be forged. A reference confers to the holder the authority to invoke any of the methods of the interface for which the reference to the object was created…In accordance with some embodiments of the invention, when a service, agent or process (e.g., a first process) wants to make an object available to another process (e.g., a second service, agent or process), instead of invoking a trusted entity to register the object reference for export from the first process, the trusted entity recognizes that a new object reference is being exported by the first process by monitoring communications between processes and inspecting the reference name. The trusted entity automatically creates an entry for the object reference in a table maintained for the first process when a reference to the object is exported.” ¶ [0065], “Thus, in an exemplary IPC system according to some embodiments of the invention, when a first process (process B), wants to export an object reference (i.e., make the referenced object owned by the first process available to a second process (process A)), the first process identifies the object reference as exported. In some embodiments of the invention, the reference is identified as exported by assigning the reference a name which is an unused even integer.”); and separately managing a user reference count (¶ [0036], “Thus in some embodiments of the invention, the first time a process or service exports a reference to one of its objects, the object has no reference name. The service assigns a new name to the object, assured to not have been used before in the life of the service, and uses that name as the reference being exported. The name assigned by the service is an even number. The service keeps a Local Export Count (LEC) to keep track of the number of times the name has been exported.” ¶ [0072], “The service may also keeps a Local Export Count (LEC) to keep track of the number of times the name has been exported. Process A 602 may pass a reference to an object that has been exported to it (such as, for example, a reference to one or more of objects: object 1 620, object2 622 . . . object n 624) exported to it by other processes (such as, for example, by process B 604). Similarly, process B may receive a reference to an object (such as, for example, a reference to object x 626) exported to it by other processes (such as, for example, by process A 602).”) and a system reference count of the object to manage a life cycle of the object (¶ [0036], “The first time the kernel sees a reference being exported from a service, it builds a data structure with two counters, a Global Reference Count (GRC), and a Global Export Count (GEC).” ¶ [0068], “Thus, in some embodiments of the invention, the global reference counting mechanism maintains two different counts, one count for the total number of live references that are known and another for the total number of references exported by the sharing process. The total number of references exported by the sharing process is referred to herein as the global export count. The sharing process also keeps track of how many times it has decided to export a reference to the resource. This count is identified herein as the local export count. (It will be apparent that the global export count therefore will never be greater than the local export count).”).
Although Bernabeu-Auban teaches a general usage of an API when managing objects and reference counts, Bernabeu-Auban fails to explicit teach object creation through an API function call.
However, Fontaine teaches the well-known technique of creating the object by calling a first function through an application programming interface (API) (¶ [0067], “In at least one embodiment, said User Object Create API is denoted as cudaUserObjectCreate, UserObjectCreate, and/or any suitable notation, which can be in reference to a programming model (e.g., CUDA, HIP, oneAPI, and/or variations thereof). In at least one embodiment, said User Object Create API causes one or more systems of one or more programming models (e.g., CUDA, HIP, oneAPI, and/or variations thereof) to create a user object, which refers to a data structure that indicates a destructor and a reference count.”).
Bernabeu-Auban and Fontaine are considered to be analogous to the claimed invention because they are in the same field of object lifecycle management through reference counting. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method for managing an object of Bernabeu-Auban with the well-known technique of object creation by calling an API function as taught in Fontaine to arrive at the claimed invention. This modification would have yielded predictable results and been reasonable under MPEP § 2143 as both reference teach managing objects using reference counts.
As per claim 2, Bernabeu-Auban and Fontaine teach the method of claim 1. Bernabeu-Auban teaches wherein when creating the object by calling the first function through the application programming interface, initially setting the user reference count and the system reference count as a predetermined value (¶ [0036], “The service keeps a Local Export Count (LEC) to keep track of the number of times the name has been exported. The initial value of the LEC is 1. The first time the kernel sees a reference being exported from a service, it builds a data structure with two counters, a Global Reference Count (GRC), and a Global Export Count (GEC). The initial value both GRC and GEC receive is 1.”). Fontaine also teaches initially setting the reference count as a predetermined value (¶ [0068], “In at least one embodiment, parameters for said User Object Create API call include “object_out,” “ptr,” “destroy,” “initialRefcount,” “flags,” and can include other parameters that further define aspects of said user object. In at least one embodiment, parameter “object_out” indicates a location to return a handle to said user object. In at least one embodiment, parameter “ptr” indicates a pointer to pass to a destroy function (e.g., destructor). In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use. In at least one embodiment, parameter “initialRefcount” indicates a value of an initial reference count to create said object with, in which initial references are owned by a calling thread.”).
As per claim 3, Bernabeu-Auban and Fontaine teach the method of claim 1. Bernabeu-Auban teaches wherein the step of separately managing the user reference count and the system reference count comprises: increasing the user reference count (¶ [0076]-[0077], “If the message is an export message (706), processing may continue at 714. The first time the kernel sees a reference being exported from a service, it builds a data structure with two counters, a Global Reference Count (GRC), and a Global Export Count (GEC)…At 716 a global export counter may be incremented in a table maintained by the trusted entity. At 718 a global reference counter may be incremented in a table maintained by the trusted entity…The counters may be incremented as follows: the trusted entity 606 may increment a global export counter, 662 (e.g., from zero to one) because process B 604 has indicated that object 1 620 is to be exported to process A 602. The trusted entity may increment a global reference counter 660 (e.g., from zero to one) because a new reference to object 1 620 is being created.”). Fontaine also teaches in response to the object being retained by calling a second function through the API, increasing the reference count (¶ [0070]-[0071], “In at least one embodiment, said User Object Retain API is denoted as cudaUserObjectRetain, UserObjectRetain, and/or any suitable notation, which can be in reference to a programming model (e.g., CUDA, HIP, oneAPI, and/or variations thereof). In at least one embodiment, said User Object Retain API causes one or more systems of one or more programming models (e.g., CUDA, HIP, oneAPI, and/or variations thereof) to retain a reference to said user object by at least incrementing said reference count of said user object by a specified value…In at least one embodiment, parameters for said User Object Retain API call include “object,” “count,” and can include other parameters that further define aspects of said user object. In at least one embodiment, parameter “object” indicates said user object. In at least one embodiment, parameter “count” indicates a number of references to retain. In at least one embodiment, one or more systems perform said User Object Retain API by at least increasing or otherwise incrementing (e.g., by said indicated number of references to retain) a count of references associated with said user object.”).
As per claim 4, Bernabeu-Auban and Fontaine teach the method of claim 1. Bernabeu-Auban teaches wherein the step of separately managing the user reference count and the system reference count comprises: in response to the object being retained according to a dependency between the object and another object, increasing the system reference count (¶ [0066], “A local reference count maintained by a sharing process keeps track of how many references have been exported by the sharing process. When the process receiving the reference is done with a particular resource, the process so informs the independent process, which decrements the global reference counter. Similarly, when the process passes the reference for the resource to another process, the independent process is informed thereof and increments the global reference counter.” ¶ [0077], “Alternatively, a communication may be sent to the trusted entity 606 from process B 604 informing the trusted entity 606 that process B 604 wants to export object 1 620 to process A 602. In response to the communication, in some embodiments of the invention, trusted entity 606 may create an entry for object 1 in table B 612 for object 1 620, as described above. In addition or alternatively, trusted entity 606 may generate three counters for object 1 620 in entry 1 612a in table B 612. The counters may be incremented as follows: the trusted entity 606 may increment a global export counter, 662 (e.g., from zero to one) because process B 604 has indicated that object 1 620 is to be exported to process A 602. The trusted entity may increment a global reference counter 660 (e.g., from zero to one) because a new reference to object 1 620 is being created.”).
As per claim 5, Bernabeu-Auban and Fontaine teach the method of claim 1. Bernabeu-Auban teaches wherein the step of separately managing the user reference count and the system reference count comprises: in response to the object being released, decreasing the user reference count (¶ [0080]-[0081], “When a service closes a reference, the trusted entity takes the corresponding entry out of the table it maintains. Additionally, it decreases the GRC by 1…For example, suppose the message indicates that a service has closed a reference (710). Processing may continue at 726. At 726, the trusted entity may delete the entry in the table for the process sending the message for the object being unreferenced. At 728 the global reference count for the object in the table for the exporting object may be decremented. If the global reference count equals zero (730), an unref message may be send at 732 to the sharing process. If the global reference count does not equal zero, processing may continue at step 702. For example, suppose now that process C 670 is finished with object 1 620. Process C 670 may send a notification thereof to the trusted entity 606. In response to the notification, the trusted entity 606 may decrement the global reference count 660 (e.g., from two to one) in table B 612 and may delete the entry in table C 614 that process C 670 has for that object. Suppose now that process A 602 no longer needs the reference to object 1 620 and so informs the trusted entity 606 by sending an unref message. The trusted entity 606 may receive the message, determine that the message is an unref message (710) may remove the entry for (i.e., entry 1 612a) for object 1 620 in table A 610 (726), and may decrement (728) the global reference count 660 (e.g., from one to zero).”). Fontaine also teaches in response to the object being released by calling a second function through the API, decreasing the reference count (¶ [0073]-[0074], “In at least one embodiment, said User Object Release API is denoted as cudaUserObjectRelease, UserObjectRelease, and/or any suitable notation, which can be in reference to a programming model (e.g., CUDA, HIP, oneAPI, and/or variations thereof). In at least one embodiment, said User Object Release API causes one or more systems of one or more programming models (e.g., CUDA, HIP, oneAPI, and/or variations thereof) to release a reference to said user object by at least decrementing said reference count of said user object by a specified value…In at least one embodiment, parameters for said User Object Release API call include “object,” “count,” and can include other parameters that further define aspects of said user object. In at least one embodiment, parameter “object” indicates said user object. In at least one embodiment, parameter “count” indicates a number of references to release. In at least one embodiment, one or more systems perform said User Object Release API by at least decreasing or otherwise decrementing (e.g., by said indicated number of references to release) a count of references associated with said user object.”).
As per claim 6, Bernabeu-Auban and Fontaine teach the method of claim 5. Bernabeu-Auban teaches further comprising: in response to the user reference count being decreased to a predetermined value, subtracting an adjustment value from the system reference count (¶ [0069], “In some embodiments of the invention, because the global reference counting mechanism has already eliminated the information stored for the resource (e.g., in a table maintained by a trusted entity), the sharing process must subtract the global export count received from its local count, hence the local export count refers to the total number of exported references which may still be in use.” ¶ [0082], “When process B 604 receives the unref message, process B may subtract the global export count (1) from the global reference count 630. If the result of this subtraction is zero, process B has exported that reference and there are no more references to object 1 620 in the system. If, however, the result of the subtraction is not zero (i.e., is greater than zero) then process B ignores the unref message because other references to object 1 620 may exist in the system.”).
As per claim 7, Bernabeu-Auban and Fontaine teach the method of claim 1. Bernabeu-Auban teaches wherein the object is dependent on another object, and the step of separately managing the user reference count and the system reference count comprises: in response to another object being destroyed, decreasing the system reference count (¶ [0080]-[0081], “When a service closes a reference, the trusted entity takes the corresponding entry out of the table it maintains. Additionally, it decreases the GRC by 1…For example, suppose the message indicates that a service has closed a reference (710). Processing may continue at 726. At 726, the trusted entity may delete the entry in the table for the process sending the message for the object being unreferenced. At 728 the global reference count for the object in the table for the exporting object may be decremented. If the global reference count equals zero (730), an unref message may be send at 732 to the sharing process. If the global reference count does not equal zero, processing may continue at step 702. For example, suppose now that process C 670 is finished with object 1 620. Process C 670 may send a notification thereof to the trusted entity 606. In response to the notification, the trusted entity 606 may decrement the global reference count 660 (e.g., from two to one) in table B 612 and may delete the entry in table C 614 that process C 670 has for that object. Suppose now that process A 602 no longer needs the reference to object 1 620 and so informs the trusted entity 606 by sending an unref message. The trusted entity 606 may receive the message, determine that the message is an unref message (710) may remove the entry for (i.e., entry 1 612a) for object 1 620 in table A 610 (726), and may decrement (728) the global reference count 660 (e.g., from one to zero).”).
As per claim 8, Bernabeu-Auban and Fontaine teach the method of claim 1. Bernabeu-Auban teaches wherein the step of separately managing the user reference count and the system reference count of the object comprises: in response to the system reference count being decreased to a predetermined value, destroying the object (¶ [0080], “The service detects that no more references exist when the resulting LEC is 0. When a service receives an invocation for a non-existing object name, it returns an exception indicating so. The trusted entity, upon seeing the exception, marks the object as revoked, blocking any further invocation attempts on the reference, as well as any reference passing.”). Fontaine also teaches in response to the reference count being decreased to a predetermined value, destroying the object (¶ [0067]-[0068], “In at least one embodiment, said user object indicates a specified destructor callback and initial reference count. In at least one embodiment, said user object corresponds to a computing resource, such as said object, region of memory, data object, data structure, and/or any suitable computing resource utilized in operations of a computer program. In at least one embodiment, said user object is utilized to track references to said computing resource in which once said reference count reaches zero, said destructor is invoked to destroy or otherwise delete said computing resource… In at least one embodiment, parameter “destroy” indicates a callback to free one or more computing resources when said one or more computing resources are no longer in use. In at least one embodiment, parameter “initialRefcount” indicates a value of an initial reference count to create said object with, in which initial references are owned by a calling thread.”).
As per claim 9, Bernabeu-Auban and Fontaine teach the method of claim 1. Bernabeu-Auban teaches wherein the user reference count and the system reference count are two independent counts (¶ [0068], “Thus, in some embodiments of the invention, the global reference counting mechanism maintains two different counts, one count for the total number of live references that are known and another for the total number of references exported by the sharing process. The total number of references exported by the sharing process is referred to herein as the global export count. The sharing process also keeps track of how many times it has decided to export a reference to the resource. This count is identified herein as the local export count. (It will be apparent that the global export count therefore will never be greater than the local export count). Both counts do not have to be the same at all times.”).
As per claim 10, Bernabeu-Auban and Fontaine teach the method of claim 1. Bernabeu-Auban teaches wherein the user reference count and the system reference count are two sub-parts of a total reference count (¶ [0068], “Thus, in some embodiments of the invention, the global reference counting mechanism maintains two different counts, one count for the total number of live references that are known and another for the total number of references exported by the sharing process. The total number of references exported by the sharing process is referred to herein as the global export count. The sharing process also keeps track of how many times it has decided to export a reference to the resource. This count is identified herein as the local export count. (It will be apparent that the global export count therefore will never be greater than the local export count). Both counts do not have to be the same at all times.”).
As per claim 11, it is a non-transitory machine-readable medium claim comprising similar limitations to claim 1, so it is rejected for similar reasons. Bernabeu-Auban also teaches a non-transitory machine-readable medium for storing a program code, wherein when loaded and executed by a heterogeneous computing system, the program code instructs the heterogeneous computing system to (¶ [0086], “Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.”).
As per claim 12, it is a non-transitory machine-readable medium claim comprising similar limitations to claim 2, so it is rejected for similar reasons.
As per claim 13, it is a non-transitory machine-readable medium claim comprising similar limitations to claim 3, so it is rejected for similar reasons.
As per claim 14, it is a non-transitory machine-readable medium claim comprising similar limitations to claim 4, so it is rejected for similar reasons.
As per claim 15, it is a non-transitory machine-readable medium claim comprising similar limitations to claim 5, so it is rejected for similar reasons.
As per claim 16, it is a non-transitory machine-readable medium claim comprising similar limitations to claim 6, so it is rejected for similar reasons.
As per claim 17, it is a non-transitory machine-readable medium claim comprising similar limitations to claim 7, so it is rejected for similar reasons.
As per claim 18, it is a non-transitory machine-readable medium claim comprising similar limitations to claim 8, so it is rejected for similar reasons.
As per claim 19, it is a non-transitory machine-readable medium claim comprising similar limitations to claim 9, so it is rejected for similar reasons.
As per claim 20, it is a non-transitory machine-readable medium claim comprising similar limitations to claim 10, so it is rejected for similar reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Jung et al. (US Patent No. 7,865,914 B2) teaches keeping internal and external reference counts for an object. Similarly, Wang et al. (US Pub. No. 2018/0232304 A1) teaches keeping global and local reference counts for an object.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 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, Lewis Bullock can be reached at (571)272-3759. 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.
/J.D.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights