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-25 are presented for the examination.
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.
Claims 1, 8, 14, 21 are rejected under 35 U.S.C. 103 as being unpatentable over Miloushev( US 20060143350 A1) view of McKee(US 20030115476 A1) in view of Chalmer( US 6728962 B1) in view of Tuan( US 20060136640 A1) and further in view of KOUZNETSOV( CA 2517534 C).
As to claim 1, Miloushev teaches in response to call, a first application programming interface (API) from a first software library to access a timeline semaphore created by a second from another API from a second different software library( the processes 251 and 252[second library ] are called member processes of the aggregated process 254[second library ]. The processes 250 and 251[API] interact with the operating system 230 through the API 270; the processes 252 and 253 interact with the operating systems 231 and 232, respectively, through the API 271 and 272, respectively, para[0185], ln 5-11/ in response to a request to create a semaphore coming from a thread in the member process 251, the operating system 230 has assigned a handle value 2243 to the semaphore represented by the entry 643. Similarly, in response to a request to create a semaphore coming from a thread in the member process 252, the operating system 231 has assigned the same handle value, 2243, to the semaphore represented by the entry 646. However, these are two different semaphores, allocated independently by threads running on the servers 200 and 201, respectively, para[0286]/ The agents 240, 241 and 242[first library] preferably intercept the operating system API 270, 271 and 272, respectively, in order to track resource requests made by processes that run on the servers 200, 201 and 202, respectively. The agents further communicate with the grid switch 210 using messages 260-263 through the connections 220, 221 and 222, para[0188], ln 1-8/ The agent[API] may call the original function before, after, in addition to or instead of its agent-provided functionality; or it may not call it at all, para[0249], ln 7-10/ the agent 240[first API]sends an access request to the grid switch. By the handle value 22, the grid switch locates the routing entry 644 which indicates that the semaphore is on the server 200 and therefore can be accessed[access]directly by that thread, and contains the locally assigned handle for that semaphore, 2243, para[0288], ln 1-8/ The synchronization object routing table 642 contains at least the following entries: entry 644 representing the semaphore with handle 22 and the entry 645 representing the semaphore with handle 23, para[0279], ln 6-10).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the above teaching to incorporate above feature because this creates processes and resources, and for accessing resources transparently across multiple servers and increase the number of processors that work concurrently in the same system are needed in order to meet the needs for high-performance computing systems.
Mckee teaches destroy the timeline semaphore for a timeline semaphore indicated and created by first and second API from a first and second different software library and ( If a process calls routines[first software library] to access two different semaphores close in time, para[0038], ln 17-21/access to the semaphore itself is guarded by a mutex lock, spin lock, or other such device for guaranteeing that only one process or thread may access semaphore routines[first software library] at any particular instant in time, para[0003] , ln 23-28/ The class "semaphore" includes the following public function members[first software library]: (1) "init," declared above on line 14, that initializes the value and Memory_Address data members of the semaphore; …. (8) "lock," declared above on line 20, a basic semaphore routine that is called by a process or thread to acquire a grant for memory access from an instance of the class "semaphore, para[0058]/ the class "kernel" includes the following public member functions[second software library]: (1) "createSemaphore," declared above on line 26, that creates an instance of the class semaphore according to a specified semaphore value, a specified number of pages in the memory region that the semaphore is created to protect, and access rights to be associated with both the semaphore and the protected memory region; (2) "destroySemaphore," declared above on line 28, that deallocates memory associated with the semaphore and then deallocates the semaphore itself, para[0046], ln 1-10/ the operating system may call kernel routines that execute at privilege level 0 in order to access resources protected from access by both application programs and operating systems, para[0023], ln 10-15/ calling semaphore routines, as well as into an internal data structure associated with the process or thread, and to remove the protection key from the protection-key register via a kernel-routine call, para[0033], ln 15-19/ The class "kernel" includes the following private member functions[first software library]: (1) "allocateProtectionKey" and "deallocateProtectionKey ……. "allocateSemaphore" and "deallocateSemaphore," declared above on lines 15 and 16, that allocate and deallocate instances of the class "semaphore," where the access rights to be associated with the memory including the semaphore are supplied as arguments for allocation and a pointer to an existing semaphore supplied as an argument for deallocation, para[0044], ln 1-21/ Finally, the class "kernel" includes the following public member functions[second software library]: (1) "createSemaphore," declared above on line 26, that creates an instance of the class semaphore according to a specified semaphore value, a specified number of pages in the memory region that the semaphore is created to protect, and access rights to be associated with both the semaphore and the protected memory region, para[0046], ln 1-10/ On line 9, destroySemaphore attempts to gain access to semaphore routines via the semaphore function member "getSpinLock." If access to the semaphore is not obtained, then an error condition has occurred. Access has been denied because another process or thread is currently accessing the semaphore routines. However, the routine "destroySemaphore" should be called only after processes and threads no longer attempt to access the semaphore. Similarly, on line 13, destroySemaphore determines whether there are any processes or threads waiting in the wait queue associated with the semaphore. Again, if there are waiting processes or threads, then an error condition has occurred. In both cases, the error condition can be handled in many different ways. Generally, the semaphore can be destroyed after awakening any waiting processes, and subsequent errors caught through protection key faults, para[0063], ln 8-22).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the above teaching to incorporate above feature because this employs hardware-based memory-protection facilities to enforce semaphore-based memory access control and detect programming errors involving failure to follow the semaphore protocol for obtaining and releasing access rights.
Chalmer teaches synchronize a first workload associated with the first API with a second workload associated with the second API; and destroy the timeline semaphore(the processor 22 may be any one of a number of conventional, commercially available, processor devices (with corresponding support and interface circuitry), col 4, ln 54-62/A semaphore may be an integer value which represents a queue of processes. The semaphore may be created by the use of a semcreate( ) function[second API]. Semaphore synchronization may allow one or more processes to pend on a particular semaphore value. That is, a process will block and wait for another process to post to that same semaphore. Each process which pends on a particular semaphore is placed into a FIFO queue of processes associated with the semaphore. Each time another process posts to the semaphore, the process at the head of the FIFO queue is unblocked. The unblocked process will run as soon as the scheduler allows it. (Note that any process may create a semaphore to which any process may pend, post, or which any process may delete using the semdelete(S) call[first API]), col 17, ln 43-56/ process pends on a semaphore through the use of the sempend(S) call[first API], where S is a valid semaphore value returned from a previously invoked semcreate( ) call[second API], col 17, ln 55-60).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the above teaching to incorporate above feature this allows the scheduling algorithm to determine which process will in fact run next.
Tuan teaches use an increasing counter value of the timeline semaphore to synchronize a first workload associated with the first API with a second workload associated with the second API( The semaphores are used by an operating system or application software to manage one or more shared resources. There are four interface functions to the semaphores by the software, including create semaphore, wait semaphore, release semaphore, and free semaphore. By calling the interface function of create semaphore with an initial value indicating the number of the resource units for sharing, the operating system or application software is able to manage the shared resources …Before a process starts to use the shared resources, the process calls the wait semaphore interface function of that corresponding semaphore. If the return value of the corresponding semaphore is zero, it implies that all the shared resources are currently in use, and the process enters the waiting state. …… When the process finishes the use of shared resource, the process calls the release semaphore interface function, and the semaphore is incremented by 1. If there are other processes in the waiting state, they can start to use the shared resource., para[0002] to para[0003]/ When a plurality of processes use a shared resource, a semaphore is required for the coordination and synchronization, para[0007], ln 1-5).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the above teaching to incorporate above feature this allows the operating system or the application software no longer requires managing the shared resources, the free semaphore interface function can be called to eliminate the semaphore or free it for managing other shared resources.
Kouznetso teaches semaphore is synchronization use an increasing counter value of the timeline semaphore to synchronize a first workload associated with the first API with a second workload associated with the second API( synchronization object (semaphore)/ Synchronization Object, Sec: APPENDIX A The present application program interface (API) includes the following, ln 5-8/ Resource synchronization and control is done using a semaphore. Included in The abstraction library is a set of functions to create, open, close and modify a Semaphore object. Below is an exemplary semaphore API. Description Function AL_SEM_HANDLE AlSemCreate ( create a named semaphore and return its handle char consst* pszName) AL_SEM_HANDLE AlSemOpen ( return a handle to an existing semaphore char const* pszName)
void AlSemClose ( close semaphore handle; reference count is decremented
AL_SEM_HANDLE hHandle) by one, and the semaphore referenced is released if the count reaches zero. int AlSemGet ( acquire a semaphore AL SEM HANDLE hHandle). int AlSemRelease ( release a semaphore AL SEM HANDLE hHandle)
AlSemCreate Description Creates a named-semaphore, sets internal counter to zero, and returns its handle. AL SEM HANTDLE AlSemCreate( char count* pszName ); Parameters pszName [in] Semaphore name string. Return Value
Semaphore handle if successful, INVALID AL SEM HANDLE otherwise.
See Also AlSemOpen(),AlSemClose(),A1SemGet(),AlSemRelease()
AlSemOpen Description Returns a handle to an existing semaphore.
Prototype AL SEM HANDLE AlSemOpen( char const* pszName );
Parameters pszName [in] Semaphore name. Return Value
Semaphore handle if successful, INVALID AL SEM HANDLE otherwise.
See Also AlSemCreate(),AlSemClose(),AlSemGet(),AlSemRelease()
AlSemClose Description Closes and releases system resource associated specified semaphore handle. Semaphore usage/reference count is also decremented, and the referenced semaphore object is destroyed if the count reaches zero. Prototype void AlSemClose( AL SEM HANDLE hSem ); Parameters
hSem [in] Semaphore handle obtained using AlSemCreate () or AlSemOpen () .
Return Value none See Also AlSemCreate () , AlSemOpen () , AlSemGet () , AlSemRelease ( ) AlSerGet Description Acquires specified semaphore. If the internal counter is greater than zero on entry, it is decremented by one and returned immediately. If the internal counter is zero on entry, the call is blocked until other tasks/threads call AlSemRe1ease () to make it greater than zero. Prototype
int AlSemGet( AL SEM HANDLE hSem); Parameters hSem [in] Semaphore handle. Return Value 0 if successful, -1 otherwise. See Also
AlSemCreate () , AlSemOpen () , AlSemClose () , AlSemRelease ( )
AlSemRelease Description Releases the semaphore, incrementing the internal counter by one. Prototype int AlSemRelease( AL SEM HANDLE hSem );
Parameters, Sec: Synchronization Object. ln 1-56).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the above teaching to incorporate above feature this supports system initialization, library initialization, error functions, memory allocation, input/output (I/0), data authentication, synchronization, hypertext transfer protocol, shared memory, system time, device.
As to claims 8, 14, 21, they are rejected for the same reason as to claim 1 above.
Claims 2-6, 9, 10, 11, 12,13, 15, 16, 17, 18, 19, 22, 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Miloushev( US 20060143350 A1) in view of McKee(US 20030115476 A1) in view of Chalmer( US 6728962 B1) in view of Tuan( US 20060136640 A1) in view of KOUZNETSOV( CA 2517534 C) and further in view of Kouznetsov(US 7254811 B2).
As to claim 2, Miloushev teaches the first API is a first API and corresponds to a first context using the first software library, second API and corresponds to a second context using the second software library( para[0185], ln 5-11/ para[0288], ln 1-8) for the same reason as to claim 1 above and Kouznetsov teaches the API is a first API and corresponds to a first context, wherein the other API is a second API and corresponds to a second context, and wherein to invalidate is to release references of the timeline semaphore in the first context( FIG. 12 illustrates one exemplary configuration API call sequence 1200, in accordance with one embodiment. As shown, MDoConfigOpen( ) 830 returns a handle to be passed to the configuration retrieval and specification functions. MDoConfigClose( ) 814 is used to release and close the configuration handle returned by MDoConfigOpen( ) 812. MDoConfigSet( ) 818 sets a specified configuration variable with a specified value, and MDoConfigGet( ) 816 returns a configuration value for a specified variable, col 14, ln 53-65/ Return Value Semaphore handle if successful, INVALID_AL_SEM_HANDLE otherwise. See Also AlSemCreate( ), AlsemClose( ), AlSemGet( ), AlSemRelease( ) AlSemClose Description Closes and releases system resource associated specified semaphore handle. Semaphore usage/reference count is also decremented, and the referenced semaphore object is destroyed if the count reaches zero. Prototype void AlSemClose(AL_SEM_HANDLE hSem), col 34, ln 5-32).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the above teaching to incorporate the feature of the API is a first API and corresponds to a first context, wherein the other API is a second API and corresponds to a second context, and wherein to invalidate is to release references of the timeline semaphore in the first context Kouznetsov because this provides Resource synchronization and control is done using a semaphore.
As to claim 3, Kouznetsov teaches to invalidate the timeline semaphore further comprises to release references to the timeline semaphore corresponding to the second API in the second context using the second software library( col 33, ln 45-60/ col 34, ln 5-32) for the same reason as to claim 2 above.
As to claim 4, Kouznetsov teaches destroying the timeline semaphore from the second API is to delete a handle of the timeline semaphore, wherein the handle is to reference an exported handle from the second API, and wherein the second API created the handle( col 34, ln 1-30) for the same reason as to claim 2 above.
As to claim 5, Miloushev teaches the second API created the timeline semaphore( para[0286]).
As to claim 6, Mckee teaches to destroy the timeline semaphore, and wherein to destroy is to occur after all operations waiting on or signaling the timeline semaphore are completed( para[0033], ln 15-1 ) and Kouznetsov teaches to destroy the timeline semaphore is to remove any references to the timeline semaphore ( col 34, ln 25-32) for the same reason as to claims 1 and 2 above.
As to claims 9, 11, 12, 13, 15, 17, 18, 19, they are rejected for the same reasons as to claims 2, 4, 5, 6 above.
As to claim 10, Kouznetsov teaches invalidate the timeline semaphore further comprises to release references of the timeline semaphore in the second context ( col 33, ln 45-60/ col 34, ln 5-32) for the same reason as to claim 2 above.
As to claim 16, 23, 24, they are rejected for the same reasons as to claims 10, 3, 4, 11 above.
As to claim 22, Kouznetsov teaches the API corresponds to a first context, wherein the other API corresponds to a second context, and wherein the method further comprises: releasing references of the timeline semaphore in the first context( col 14, ln 53-65/ col 34, ln 5-32) for the same reason as to claim 2 above.
Claims 7, 20 are rejected under 35 U.S.C. 103 as being unpatentable over
Miloushev( US 20060143350 A1) in view of McKee(US 20030115476 A1) in view of Chalmer( US 6728962 B1) in view of Tuan( US 20060136640 A1) in view of KOUZNETSOV( CA 2517534 C) and further in view of Hipp(US 20050010924 A1) .
As to claim 7, Tuan teaches destroy the timeline semaphore is to occur after a context has completed all operations that reference the timeline semaphore( para[0002], ln 5-9 to para[0003] , para[004]/ Para[0005]) for the same reason as to claim 1 abvoe.
Hipp teaches operations( operating system API interfaces 210, and process management subsystem 216. If the state has changed since the last snapshot (step 270), the new state is recorded. Control then loops to step 264 and executes through the above sequence of steps until all states of all processes are checked. Once completed, control proceeds to step 278, the registered global state, such as semaphores, is removed, para[0031], ln 9-18).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the above teaching to incorporate the feature of operations because this provides need for a system and method for effecting a transfer of applications across computer networks without incurring costly processing overhead.
As to claim 20, it is rejected for the same reason as to claim 7 above.
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over
Miloushev( US 20060143350 A1) in view of McKee(US 20030115476 A1) in view of Chalmer( US 6728962 B1) in view of Tuan( US 20060136640 A1) in view of KOUZNETSOV( CA 2517534 C) and further in view of Yamamoto(US 20060287820 Al).
As to claim 25, Yamamoto teaches removing all references to the timeline semaphore( The OS_Semaphore_Delete( ) function uses an operating system service to delete a Semaphore object. The function is called by the GPS engine at the stopping procedure to delete all used semaphores. TABLE-US-00096 TABLE 96 File gps_rtos.c Syntax tGPS_UINT32 OS_Semaphore_Delete( tGPS_SEMAPHORE sem_handle ) Parameter Data range Units Description sem_handle Semaphore object handlepara[0138], ln 1-6).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the above teaching to incorporate the above feature because this exists for implementations of SPS solutions that overcome the problems noted above and others previously experienced.
Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over
Miloushev( US 20060143350 A1) in view of McKee(US 20030115476 A1) in view of Chalmer( US 6728962 B1) in view of Tuan( US 20060136640 A1) in view of KOUZNETSOV( CA 2517534 C) and further in view of Sinor(US 5583506 A).
As to claim 26, Sinor teaches at least one of the first API or the second API are to signal the timeline semaphore to increase the counter value of the timeline semaphore(Semaphores, which have a one to one relationship are implemented using a counter which is incremented by a call to Signal and decremented by each call to Wait/Waits. A process may signal a semaphore many times before any process waits on it, so that when a processor later waits on it, the wait is immediately satisfied and the semaphore decremented. Local semaphores may only be signalled and waited on within a CPU, while global semaphores may be signalled from any CPU but only may be waited on by processes within the family associated with the semaphore where it was defined. The maximum value a semaphore may be incremented is a value determined during definition. Events, which have a one to many relationship, when signalled can cause more than one process to have its Wait(s) satisfied. Additionally there must be a process currently waiting on an event in order for the signalling of that event to produce any effect. If an event is signalled and there is no process currently waiting on the event, nothing will happen, col 17, ln 50-67 to col 18, ln 1-20).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the above teaching to incorporate the above feature because this permits process definition, process allocation, process scheduling, process execution, and process synchronization using semaphores and events.
Response to the argument:
6. Applicant amendment filed on 06/25/2026 has been considered but they are not persuasive:
Applicant argued in substance that :
(1) “ However, the cited portions of Winkeler at least fail to teach or suggest an API, a first and second API, and sharing between a first and second API, let alone "execute a first application programming interface (API) from a first software library to access a timeline semaphore that is created and shared with the first API by a second API from a second different software library to synchronize a first workload associated with the first API with a second workload associated with the second API," as claimed..”.
7. Examiner respectfully disagreed with Applicant's remarks:
As to the point (1), Mckee teaches If a process calls routines[first software library] to access two different semaphores close in time, para[0038], ln 17-21/access to the semaphore itself is guarded by a mutex lock, spin lock, or other such device for guaranteeing that only one process or thread may access semaphore routines[first software library] at any particular instant in time, para[0003] , ln 23-28/ The class "semaphore" includes the following public function members[first software library]: (1) "init," declared above on line 14, that initializes the value and Memory_Address data members of the semaphore; …. (8) "lock," declared above on line 20, a basic semaphore routine that is called by a process or thread to acquire a grant for memory access from an instance of the class "semaphore, para[0058]/ the class "kernel" includes the following public member functions[second software library]: (1) "create Semaphore," declared above on line 26, that creates an instance of the class semaphore according to a specified semaphore value, a specified number of pages in the memory region that the semaphore is created to protect, and access rights to be associated with both the semaphore and the protected memory region; (2) "destroySemaphore," declared above on line 28, that deallocates memory associated with the semaphore and then deallocates the semaphore itself, para[0046], ln 1-10/ the operating system may call kernel routines that execute at privilege level 0 in order to access resources protected from access by both application programs and operating systems, para[0023], ln 10-15/ calling semaphore routines, as well as into an internal data structure associated with the process or thread, and to remove the protection key from the protection-key register via a kernel-routine call, para[0033], ln 15-19/ The class "kernel" includes the following private member functions[first software library]: (1) "allocateProtectionKey" and "deallocateProtectionKey ……. "allocateSemaphore" and "deallocateSemaphore," declared above on lines 15 and 16, that allocate and deallocate instances of the class "semaphore," where the access rights to be associated with the memory including the semaphore are supplied as arguments for allocation and a pointer to an existing semaphore supplied as an argument for deallocation, para[0044], ln 1-21/ Finally, the class "kernel" includes the following public member functions[second software library]: (1) "createSemaphore," declared above on line 26, that creates an instance of the class semaphore according to a specified semaphore value, a specified number of pages in the memory region that the semaphore is created to protect, and access rights to be associated with both the semaphore and the protected memory region, para[0046], ln 1-10/ On line 9, destroySemaphore attempts to gain access to semaphore routines via the semaphore function member "getSpinLock." If access to the semaphore is not obtained, then an error condition has occurred. Access has been denied because another process or thread is currently accessing the semaphore routines. However, the routine "destroySemaphore" should be called only after processes and threads no longer attempt to access the semaphore. Similarly, on line 13, destroySemaphore determines whether there are any processes or threads waiting in the wait queue associated with the semaphore. Again, if there are waiting processes or threads, then an error condition has occurred. In both cases, the error condition can be handled in many different ways. Generally, the semaphore can be destroyed after awakening any waiting processes, and subsequent errors caught through protection key faults, para[0063], ln 8-22)and,
Winkeler teaches data socket client calls or invokes[first/second API] the file adapter's Connect method The data socket client may also take other forms for different development environments, such as a LabVIEW Virtual Instrument (VI), a DLL (dynamic linked library), or an instrument driver/DLL among others. In The first computer system 82 and/or second computer system 86 may each include or store a first software component[first/second API], preferably a data socket client[first/second API] (or data socket component), according to one embodiment of the present invention. Applications executing in the first computer system 82 and the second computer system 86 are each operable to use their respective data socket client[first API] according to the present invention to access data located in the semaphore. The first software component[first/second API] may be any of various types of software components[first library] that are operable to connect, access[access], and/or convert data located in a semaphore, para[0031], ln 1-14/ the semaphore may be read from and/or written to by the first computer system and/or the second computer system (i.e., by applications executing on the first computer system and/or the second computer system) for use by a desired application, or to maintain desired communication, synchronization, or control. When a data socket client accesses (reads or writes) a semaphore, the data socket client performs various operations which greatly simplify this data access. For example, the data comprised in the semaphore may be of a first data type of a plurality of different possible data types. An application program may invoke the data socket client when the semaphore is desired to be accessed, and the data socket client may access the semaphore using location information of the semaphore (e.g., a uniform resource locator (URL) specifying a location of the semaphore). The data socket client may access the data comprised in the semaphore, para[0069],ln 1- 18/ The first computer system 82 and/or second computer system 86 may each include or store a first software component[second API], preferably a data socket client (or data socket component), according to one embodiment of the present invention. Applications executing in the first computer system 82 and the second computer system 86 are each operable to use their respective data socket client according to the present invention to access data located in the semaphore. The first software component[first/second API] may be any of various types of software components[first/second API] that are operable to connect, access[access], and/or convert[create] data located in a semaphore, para[0031], ln 1-14/ two difference devices may use a semaphore to communicate, synchronize operations or share data between them, wherein applications (e.g., embedded applications) executing on each device may use a data socket client[first/second API] for accessing the semaphore., para[0055], ln 12-20/ involve a plurality of applications in a corresponding plurality of computer systems, where each of the applications share or use a semaphore for communication and/or data exchange. Each of the applications may include a software component, such as a data socket client[first/second API]. In this typical embodiment, one or more requests to perform a locked read-modify-write operation on the data comprised in the semaphore may be received from one or more of the multiple software components. When multiple requests are received, the plurality of requests may be stored in a queue, and processed sequentially. The corresponding multiple of applications may use the semaphore to synchronize operation of the applications or otherwise provide communication between the applications. The multiple of computer systems and the computer memory may be connected through a network (e.g., the Internet). Accessing data from a semaphore in a computer system may include publishing or writing data to the semaphore as well as reading data from the semaphore, para[0009]/ The first computer system 82 and the second computer system 86 may each store an application program (or a plurality of application programs), wherein the application program(s) on each computer may use a semaphore to communicate with each other, synchronize operations, or otherwise share data. One or more of the first computer system 82 or the second computer system 86, or another computer (not shown) may store the semaphore that is used by the respective application programs, para[0030] ).
Chalmer teaches A semaphore may be an integer value which represents a queue of processes. The semaphore may be created by the use of a semcreate( ) function[second API]. Semaphore synchronization may allow one or more processes to pend on a particular semaphore value. That is, a process will block and wait for another process to post to that same semaphore. Each process which pends on a particular semaphore is placed into a FIFO queue of processes associated with the semaphore. Each time another process posts to the semaphore, the process at the head of the FIFO queue is unblocked. The unblocked process will run as soon as the scheduler allows it. (Note that any process may create a semaphore to which any process may pend, post, or which any process may delete using the semdelete(S) call[first API]), col 17, ln 43-56/ process pends on a semaphore through the use of the sempend(S) call[first API], where S is a valid semaphore value returned from a previously invoked semcreate( ) call[second API], col 17, ln 55-60).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Conclusion
US 7296271 B1 teaches A semaphore may be an integer value which represents a queue of processes. The semaphore may be created by the use of a semcreate( ) function. Semaphore synchronization may allow one or more processes to pend on a particular semaphore value. That is, a process will block and wait for another process to post to that same semaphore.
US 20060085679 A1 teaches System V semaphores are a synchronization primitive that can be shared across multiple processes. The kernel maintains these semaphores, and provides system calls to create, open, or modify a set of semaphores. These system calls are semget( ), semctl( ), and semop( ). See the Linux manual for further information.
US 20230138635 A1 teaches These command lists reside in single source file, and provide execution of workloads that are implicitly synchronized by semaphores (e.g., signals). For example, semaphore wait and semaphore signal can be achieved by hardware commands MI_SEMAPHORE_WAIT and MI_SEMAPHORE_SIGNAL or MI_STORE_DATA_IMM (which stores value in memory).
US 7254811 B2 teaches Resource synchronization and control is done using a semaphore. Included in the abstraction library is a set of functions to create, open, close and modify a semaphore object. Below is an exemplary semaphore API.
US 7545380 B1 teaches Before allowing GPU 1 to proceed with such processing, flip( ) attempts to acquire the semaphore for image 1, using the function Semaphore.Acquire( ). Here, the semaphore for image 1 has not yet been released with respect to the processing of GPU 0, and the function Semaphore.Acquire( ) simply does not return until the semaphore is acquired. Thus, flip( ) hangs until the semaphore for image 1 is acquired. Only then is the function GPU(i).Display(NewBuffer) called.
JP H052468 A teaches the reading of the data written in the buffer memory 4 is performed with a reading processing function part 5 by a reading processing task part 6. Accompanying the reading of the data, the counting semaphore part 9 is subtracted, and until the value of the
US 20200026582 A1 teaches Illustrative embodiments provide techniques that implement a synchronization object that controls when destaging threads perform a destaging process on a cache.
US 6279124 B1 teaches Event semaphores are simply a layer above the OS/2 event semaphore API. The difference between the event semaphores and the sync-point service is that the event semaphores can artificially dictate the poster and receiver of the events.
US 20140310438 A1 teaches the general release operation may include atomically incrementing the variable representing the semaphore's count. Thus, for the general release operation, if the result of the incrementing is greater than 0, then the release successfully occurred as the semaphore count indicates that the semaphore may readily accept at least one more operation on the calling thread. If the result of the incrementing is less than or equal to zero, a "release”
US 20140344831 A1 teaches The value of the IC count at the time the semaphore is acquired is 2000110 and the delta count 2000000 in the counts attributed to semaphores. F1 continues executing until it is ready to call another function, say F2, say 1000 additional instructions. In this scenario when the profiler reads the new count at entry to F2, the value returned by the API is 1100. Where the value of 2001110 is not seen by the profiler.
0xff
US 20210294948 A1 teaches A semaphore is a POSIX standard, which allows processes and threads to synchronize their actions. It has an integer value, which must remain non-negative. To increment the value by one, the sem_post function is used, and to decrement the value by one, sem_wait function is called. If the value is already zero, the sem_wait function will block the process, until another process increase the semaphore value with sem_post.
US 20160154678 A1 teaches The semaphore is incremented by the consumer thread 330 when the message queue is no longer full, for example when the consumer thread processes a message from the message queue. Incrementing the semaphore is a system call by the consumer thread to the operating system.
US 20060136640 A1 teaches When the process finishes the use of shared resource, the process calls the release semaphore interface function, and the semaphore is incremented by 1. If there are other processes in the waiting state, they can start to use the shared resource.
US 5583506 A teaches These are accessible by all processor modulus within a group, and global to the system. Semaphores, which have a one to one relationship are implemented using a counter which is incremented by a call to Signal and decremented by each call to Wait/Waits.
US 7512950 B1 teaches FIG. 3, N-1 threads have arrived at barrier 201, while THREAD 3, which is the last to arrive, continues to execute. At this stage, all threads other than THREAD 3 are in a wait or sleep state.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LECHI TRUONG whose telephone number is (571)272-3767. The examiner can normally be reached 10-8 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Young Kevin can be reached on (571)270-3180. 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.
/LECHI TRUONG/ Primary Examiner, Art Unit 2194
Prosecution Insights